17:12:18 <stickster> #startmeeting
17:12:19 <zodbot> Meeting started Thu Mar  4 17:12:18 2010 UTC.  The chair is stickster. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:12:20 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:12:23 <stickster> #meetingname Fedora Board
17:12:24 <zodbot> The meeting name has been set to 'fedora_board'
17:12:27 <mmcgrath> I'm going to go watch tv.
17:12:31 <stickster> #topic Roll call!
17:12:33 * stickster 
17:12:36 * dgilmore is here
17:12:38 * caillon 
17:12:38 * mmcgrath 
17:12:40 * poelcat 
17:12:42 * walters is present
17:12:46 * ctyler is here
17:12:51 * jwb 
17:12:57 <mdomsch> 
17:13:00 * mdomsch 
17:13:14 <stickster> I know spot is around too.
17:13:19 * caillon notes that mdomsch is on both sides of the line today
17:13:24 <spot> yeah, i'm here
17:13:30 <stickster> #topic Audio meeting FAIL
17:13:54 <mdomsch> welcome to the edge
17:13:55 <mmcgrath> I'm half tempted to put a stop to FAD's that work on infrastructure because this happens.
17:14:04 <mmcgrath> When people do work and walk away, the result is bad.
17:14:04 <stickster> OK, sorry for the bumble there everyone. Please know that we tested this out on both Thursday and Friday with good results. Today the Asterisk server for some reason was not letting all the callers in, or was diverting them to dead air.
17:14:26 <jwb> the silence was peaceful
17:14:31 <stickster> mmcgrath: Actually, I got help on what I was working on on Friday, I think you may be jumping to conclusions
17:14:39 <stickster> jsmith helped me out
17:14:44 <mmcgrath> stickster: I think asterisk is still busted.
17:14:54 <mmcgrath> results speak.
17:15:14 <stickster> Well... we can take that up as an infrastructure topic certainly. It remains to be seen whether I broke it, although I can tell you I tested it before and after the change without anything seeming wrong.
17:15:47 <stickster> Let's see what we can do to size up and fix the problem later.
17:16:20 <stickster> Shall we move on?
17:16:28 * poelcat still wants to praise thank all the people that got it working
17:16:39 <poelcat> it has made a number of my meetings 100x easier!
17:16:52 <stickster> Yeah, thanks to the Board folks for helping with the testing last week, and to jsmith for some help on Friday too
17:16:54 <poelcat> this is a temporary setback
17:17:10 * stickster uses Fedora Talk quite a bit as well, it's really helpful
17:17:18 <mmcgrath> poelcat: except this isn't the first time we've had problems with the system.
17:17:19 <stickster> As have many FADs and other events..
17:17:31 <mmcgrath> we over tested it just because we were worried about something going wrong and even with that, it did go wrong.
17:18:00 * caillon me sent out a quick note to FAB just now redirecting people here
17:18:26 <stickster> Thanks caillon
17:18:45 <stickster> Let's move on.
17:18:49 <stickster> #topic Community Q&A
17:18:49 <mdomsch> mmcgrath, you see this as an instance of a larger problem - lack of maintenance/sustainers involved in infrastructure ?
17:19:04 <stickster> Or not :-)
17:19:05 <stickster> #undo
17:19:06 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x2b6f96019550>
17:19:12 <mmcgrath> mdomsch: yes, which is why I've been pushing so hard against susmit.  we're headed to be as big of a cluster@%#! as the os.
17:19:35 <walters> what's susmit?
17:19:53 <jwb> a person doing some kind of web app work for the cd media thing
17:19:55 <mdomsch> susmit is an ambassador in India, and champions the FreeMedia project
17:20:02 <mmcgrath> walters: he built a webapp without getting permission, did it on one of our servers and now wants us to host it for a project that, IIRC, actually ships very few CDs.
17:20:06 <stickster> Susmit is a contributor who has been working on a web app for use by FreeMedia but there hasn't been as close coordination with infrastructure as might be good
17:20:08 <walters> ah...
17:20:26 * poelcat thinks it is inappropriate to be discussing this here and in this way
17:20:42 <mmcgrath> poelcat: we had no agenda today
17:20:57 <stickster> mmcgrath: Not really correct, we are here to do a community Q&A.
17:21:03 <mmcgrath> bring it.
17:21:05 <poelcat> mmcgrath: with all due respect, trashing people that are trying to help us do stuff wasn't on it either :)
17:21:29 * stickster moves that we go to Q&A now.
17:21:33 <mmcgrath> I'm not trashing anyone.  I'm stating what happened.  If it puts him in a bad light he should follow our fairly well documented procedures next time.
17:21:49 <spot> mmcgrath: referring to the OS as a cluster**** is trashing people and effort.
17:22:03 <mmcgrath> fine, our OS is not a cluster$#@^
17:22:08 <mmcgrath> everyone's happy now.
17:22:18 <stickster> #topic Community Q&A
17:22:43 <stickster> OK, let's see what we've got in the -questions channel
17:23:40 <mmcgrath> yeah.
17:24:44 <stickster> Go ahead wwoods
17:24:45 <wwoods> stickster: I seem to remember one of your FUDCon keynotes involving a review of the good/need improvement items from the previous release
17:24:58 <wwoods> And that the #1 item that needed improvement was... QA
17:25:24 <wwoods> a) do you remember this, or did I dream it? Do you have those slides anywhere?
17:25:59 <wwoods> b) if this isn't just a product of my poor feverish brain, has this general "more QA" suggestion gestated into any specific recommendations?
17:26:45 <stickster> I'm sure that at some point I talked about the need for more contributors in QA
17:26:58 <stickster> It may have been at e.g. LinuxTag/FUDCon EMEA among other places
17:27:06 <stickster> 2008 probably?
17:27:55 <stickster> I think there's a broad base of our constituency that wants to solve some of the extant problems we've had for a while -- there are several kinds of problems
17:28:05 <stickster> Some are easier to solve with automation
17:28:18 <stickster> Some are easier to solve by having people agree on processes
17:28:38 <stickster> For instance, un-subtle things like broken dependencies are clearly in the first category
17:29:14 <stickster> More subtle problems are harder to fit there.
17:29:30 <wwoods> (2008 sounds about right - that would have been the F10 FUDCon in Boston, roughly 20 months ago now)
17:30:07 <mdomsch> there are some technical steps we could take that are imminently feasible, but we need to look for budget for
17:30:09 <stickster> Since that time, we've had the emergence of community Test days, and of course an expansion of the resources that Red Hat puts into QA
17:30:11 <poelcat> wwoods hasn't Red Hat recently added more people to your group?
17:30:17 <mdomsch> e.g. doing repoclosure before pushing out any updates
17:30:38 <dgilmore> -------------------------------------------------------------------------------------------------------------
17:30:42 <dgilmore> opps
17:30:45 <wwoods> poelcat: yes - we have some new fulltime employees and interns working exclusively on Fedora QA
17:31:01 <dgilmore> mdomsch: having dell donate a second equallogix would help
17:31:02 <stickster> wwoods: I hesitate to say "AutoQA" as an answer, because it gets overloaded with a lot of expectations, and not all of them may be correct
17:31:05 <poelcat> wwoods: i would see that as a greater committment from Fedora to QA (via Red Hat) :)
17:31:09 <mdomsch> repoclosure is disk-intensive - throwing SSDs at it might help
17:31:20 <mdomsch> dgilmore,  would that I could...
17:31:32 <stickster> But certainly as a *framework* AutoQA is going to help -- as a platform to which Fedora people can contribute
17:32:09 <wwoods> mdomsch: don't get too deep into implementation details - repoclosure is almost certainly not going to be the solution
17:32:54 <mdomsch> wwoods, I'm not trying to solve it - I'm just suggesting that there are things we (collectively) know how to do, but don't because of the time impact of doing it often
17:33:13 <mdomsch> which we can mitigate if it's that important
17:33:16 <walters> obviously would help there if we slowed down updates ;)
17:33:27 <wwoods> mdomsch: right, I agree, and we're actively working on feasible implementations for the problems we've identified.
17:33:40 <stickster> wwoods: Is there something you have in mind that you want the Board to answer here?
17:35:23 <wwoods> Well. The question I really want an answer to is this:
17:35:47 <wwoods> if stability and quality are a stated goal, and we have an always-available place for new changes and unstable development
17:35:58 <wwoods> why do we allow anything but bugfixes in stable releases?
17:36:13 <mmcgrath> wwoods: I don't think stability and quality are a stated goal.
17:36:26 <mmcgrath> at least not yet
17:36:33 <wwoods> (which probably resolves to the meta-questions: "are these really our goals" and "whose responsibility is it to decide this")
17:37:32 <mdomsch> wwoods, that's the flamewar on devel@ this week in a nutshell
17:37:43 <mdomsch> There are several proposals for FESCo to consider
17:37:56 <stickster> https://fedoraproject.org/wiki/Release_Lifecycle_Proposals
17:38:11 <mmcgrath> can anyone on FESCo say this is an agenda item?  I was surprised to see it was not discussed at the last FESCo meeting.
17:38:24 <mdomsch> should FESCo wish to consult with or punt to the Board, we'll take it on
17:38:28 <stickster> The question is, who is responsible for picking between them? And on what basis do they decide?
17:39:12 <dgilmore> mmcgrath: updates is an agenda item
17:39:12 <mmcgrath> at the moment, I think they can only go off what they, FESCo, would like to see.
17:39:20 <stickster> The Board's historically delegated to FESCo the matters dealing with building the distribution
17:39:48 <walters> but it's not just building the distribution, the updates directly impact the user experience
17:40:09 <poelcat> wwoods: i think the best definition about our purpose right now is https://fedoraproject.org/wiki/Objectives
17:40:29 <mdomsch> #link https://fedoraproject.org/wiki/Release_Lifecycle_Proposals
17:40:29 <stickster> But I think the Board+FPL are supposed to set out some broad vision about where we want to be as a Project and how Fedora as a Linux system will help get us there
17:41:17 <stickster> Right now the very broad guideline on Objectives concerning updates is "Provide timely updates"
17:41:28 <stickster> But that has different meanings to different groups
17:41:31 <poelcat> wwoods: in the context of stability and quality as stated goals
17:42:45 <jwb> there's a line in those objectives that i think we want to look at:
17:42:55 <jwb> Do as much of the development work as possible staying close to upstream projects. In general, we prefer to move to a newer version for updates rather than backport fixes.
17:43:15 <jwb> really?  we prefer to do that?
17:44:04 <poelcat> jwb: i think that could be fixed with a few more specifics
17:44:07 <stickster> jwb: Remember that the wiki is collaborative, so what you find on those pages isn't necessarily something that e.g. the Board has proactively declared.
17:44:18 <stickster> And maybe it's time to think about changing that.
17:44:26 <jwb> yes, i think it is
17:44:59 <jwb> our community has nothing to go off of other than our wiki pages for items like this
17:45:53 <mdomsch> that's a pretty sweeping statement
17:46:14 <jwb> which?  the line in the wiki page, or mine?
17:46:19 <mdomsch> in the proposal I added (url above), we would slow down updates to the older releases
17:46:27 <mdomsch> jwb, sorry, the wiki page
17:46:29 <spot> making sweeping statements seems to be the latest trend. :/
17:46:33 <jwb> ah, ok
17:46:44 <stickster> The Board has to carefully walk a line between handing down dictatorial edicts, and giving clarity to the community where needed.
17:46:45 <walters> i would really like to at least get rough consensus on pushing non-security no more than once a month
17:46:55 <walters> i thought there was that consesus at the last fudcon
17:46:56 <stickster> I like the fact that a couple Board members stepped in with proposals on the release lifecycle page.
17:46:59 <walters> *consensus
17:47:19 <jwb> walters, perhaps among the people at FUDCon.  that isn't enough to make it happen
17:47:37 <spot> walters: fwiw, i don't think i agree with that.
17:47:43 <walters> =(
17:47:51 <jwb> nor i
17:48:06 <walters> three weeks?
17:48:14 <walters> 2?
17:48:16 <mmcgrath> notting mentioned he's worried about FESCo overstepping their bounds wrt updates.
17:48:19 <mdomsch> jwb, think of all the time you'd get back... :-)
17:48:27 <mmcgrath> can we give them full power to decide that and then ask them to decide?
17:48:43 <jwb> mdomsch, i am.  and i'm thinking of all the time i'm going to have to spend fixing up a MASSIVE UPDATE PUSH
17:48:45 <spot> walters: would you like to wait two weeks for the update that fixes the bug you have today?
17:48:59 <spot> what is the magic number of acceptability?
17:49:19 <walters> spot: anyone who seriously needs a specific bugfix can do a direct koji pull
17:49:29 <stickster> Before we get into rehashing all the various branches of the discussion that already happened on devel@...
17:49:35 <wwoods> false dichotomy - if you need the fix today, it's in updates-testing
17:49:46 <spot> walters: i think that is beyond the average user.
17:49:54 <walters> spot: it doesn't have to be
17:50:01 <jwb> i think it's also a crappy user experience
17:50:03 <walters> anyways, yes i agree stickster
17:50:32 <stickster> Do we agree as a Board that the current *combination* of rate+type of updates is not meeting the needs of the broad range of users we described in October?
17:50:33 <ctyler> I think the board needs to give some clarity of vision/direction here, and let FESCo do the implementation. Punting both vision and implementation on such a large issue to FESCo is not really fair to them, it feels a bit like we're abdicating our role to a certain extent.
17:50:45 <stickster> ctyler: I agree.
17:50:56 <ctyler> SWF Monday?
17:51:00 <ctyler> SWG*
17:51:12 <poelcat> who is writing the proposal?
17:51:20 <mmcgrath> stickster: I think it is not
17:51:31 <jwb> ctyler, i'd like to be a part of that discussion and i can't make the SWG meetings
17:51:43 <ctyler> poelcat: how about we start with a scope?
17:51:43 <jwb> stickster, i don't think it is either
17:51:58 <mdomsch> we could have another SWG at a different time to accommodate
17:52:14 <walters> stickster: i definitely agree
17:52:15 <ctyler> jwb: SWG considers then brings to the board, it's an accelerator
17:52:15 <poelcat> mdomsch: with different members
17:52:22 <stickster> In other words, maybe we need a rate change, and maybe we need some bounding around what type of updates we offer.  Maybe some combination. But having no guidelines around this right now means we have several different ways that people are approaching the problem, which means at *best* an uneven user experience
17:52:33 <mdomsch> poelcat, sure; just another subset, maybe overlapping
17:52:45 <jwb> ctyler, i understand that.  i'm telling you it's important enough for me to want to be involved in creating the thing to bring to the Board
17:52:56 <jwb> i just can't do the current SWG timeslot
17:52:58 <walters> spot: what if we just tried it?  like poelstra's blog
17:53:03 <poelcat> the SWG idea is just a smaller group of people to do the initial heavy lifting and idea sorting
17:53:14 * spot is entirely unconvinced that a rate change does anything but cluster the problem so that it is felt slightly less often (but more violently when it happens)
17:53:32 <stickster> spot: Maybe. We don't need to fix that detail here, nor does the Board need to describe a timeline.
17:53:45 <poelcat> walters: like a controlled trial?  two weeks and the re-evaluate?
17:53:50 <spot> it will annoy the casual user, do nothing to help the expert user
17:53:56 <walters> spot: i agree type of update is important too, but if  we don't control the rate QA is impossible
17:53:57 <mdomsch> I'm less worried about the rate, more worried about the impact.  deltarpms has lessened the impact of the rate to a large extent
17:54:09 <mmcgrath> spot: it allows packages I currently have installed to be more of a moving target then they would be otherwise.
17:54:20 <stickster> We need to also keep in mind that one of Fedora's precepts (the 5th and 6th Fs)
17:54:24 <stickster> are FAIL FASTER.
17:54:24 <mdomsch> rate is a byproduct of policy
17:54:30 <stickster> We should not be afraid to TRY something.
17:54:32 <ctyler> spot: rate change is not very useful in preventing surprises unless update clustering improves testing, which it could
17:54:54 <walters> poelcat: well i think we'd have to evaluate a policy of pushing once a month for longer than two weeks ;)
17:54:56 <poelcat> stickster: yes, within specific bounds and for a trial period if applicable
17:55:01 <stickster> poelcat: Exactly.
17:55:16 * spot would rather see us improve testing, and when that is shown to actually exist, revisit the issue
17:55:17 <stickster> And I think this meeting is not the right place to dicker over timeframes like "2 weeks" vs. "1 week".
17:55:20 <mmcgrath> So wait, are we deciding the updates issue is a board issue or FESCo one?
17:55:28 <poelcat> IOW run experiments and see what we learn vs. speculating on what the results of the experiement would be
17:55:34 <walters> i pretty strongly think the big picture is a board issue
17:55:46 <mmcgrath> spot: I'd like to see what goal we're trying to accomplish with updates.  That seems silly but people have different opinions on what updates are actually for
17:55:49 <walters> whether there are multiple repos etc. is fesco
17:56:03 <poelcat> walters: can you resummarize what the big picture is we would need to give guidance on is?
17:57:04 <caillon> poelcat, something similar to the proposal from mccann and I back in December.
17:57:21 <walters> poelcat: 1) are we meeting our target audience now as stickster asked  and 2) if not, what are some specific things we can do to address that for them, while simultaneously looking at improving cases outside of that (such as helping close the cycle of report bug -> fix in koji -> test fix locally without getting updates-testing hose)
17:57:33 <jwb> caillon, that proposal was large, and very implementation specific.  it is not a vision statement
17:57:39 <stickster> mmcgrath: I think that the Board's place here is to say, "We need more granular and predictable guidelines for updates. 'Every maintainer decides independently' is not helping us meet the needs of the broad range of people we described in October, to which the Board previously agreed."
17:58:20 <mmcgrath> stickster: can we add to that "And we think it is FESCo's place to decide the details how to do that" ?
17:58:51 <mmcgrath> stickster: I mean can we actually come out and say that in our notes and follow up with FESCo next week?
17:59:11 <jwb> i'd be for that
17:59:37 * spot is not opposed to that
17:59:53 <ctyler> sounds like a good start
17:59:53 <walters> that sounds fine to me
17:59:59 * mmcgrath is fine with that thing I just said :)
18:00:01 <caillon> jwb, many points were refuted as "that's not possible with the way we do things today" so i don't see how that is true
18:00:14 <caillon> but whatever
18:00:27 <stickster> Yes, absolutely. I think we should also ask for FESCo at the same time to set up some way for us to judge whether the changes have been effective, so we can look again at this issue in, say, 3 months after any changes are implemented
18:00:54 <jwb> caillon, i replied with detailed questions and comments to that specific proposal and didn't get a single reply.  so yes, whatever.  now is not the time to rehash that
18:00:54 * poelcat wonders about adding a few more sepcifics to what we want FESCo to include so it doesn't turn into a back and forth between the board and FESCo
18:00:55 <stickster> I'm not sure off the top of my head what that would be, but certainly we shouldn't just make a change without being able to tell later whether it's helped.
18:00:57 * spot needs to go, have a hard stop at 1.
18:01:09 <stickster> spot: OK, thanks for being here
18:01:21 * caillon too, movers are coming in a few minutes
18:01:25 <mdomsch> so the board isn't dictating an update policy, just that a policy needs to exist that matches our projectt audience statement?
18:01:35 <mmcgrath> mdomsch: yeah
18:01:37 <walters> mdomsch: that seems like a good summary to me yes
18:01:53 <stickster> mdomsch: I think that's the right place for us to be in this conversation, don't you?
18:01:56 <mmcgrath> mdomsch: well, we're kind of dictating that the policy needs to be more granular and predictable.
18:02:02 <mmcgrath> that's it though
18:02:03 * poelcat is is in favor of sending a request to FESCo, but would like something we can craft and consider on the wiki before sending it... IOW i'd like a little more time to carefully consider what we should say/request
18:02:15 <stickster> mmcgrath: Right, something better than "We don't know, do what you feel is right Luke."
18:02:43 <jwb> i have to leave for another meeting.  i'll try and review minutes later
18:02:45 * jwb &
18:02:47 <poelcat> so that our request to FESCo is not ambiguous
18:02:48 <mdomsch> for now I'm ok with that...  I'm just wondering if FESCo is really the right place to make the policy decisions, as well as implementation thereof.
18:03:23 <poelcat> where are we leaving things for today?
18:03:25 <stickster> mdomsch: We can probably explore how much detail we're comfortable laying out to help FESCo
18:03:47 <mdomsch> I'm just trying to respect expected boundaries is all
18:04:01 <mdomsch> I don't know exactly where that line is here; luckily we've got representation on both sides of it
18:04:09 <mdomsch> so shouldn't be too painful in practice
18:04:26 <mmcgrath> mdomsch: if nothing else we can say we've delegated it to them.
18:04:33 * stickster thinks there are a set of clear implications from the 4 aspects of the broad audience we set out earlier.
18:04:39 <dgilmore> mdomsch: I honestly think its ok for the board to say this is what we would like to see
18:04:43 <dgilmore> and FESCo make it happen
18:04:55 <stickster> So hopefully we can draw a line from that as a rationale, which I think would be helpful for FESCo.
18:04:55 <walters> yep
18:05:05 <stickster> If it's not, I'm sure they'll have no problem telling us so. ;-)
18:05:12 <mdomsch> ok
18:05:16 <stickster> wwoods: So was that an answer to your question? ;-)
18:05:17 <poelcat> dgilmore: and I guess FESCo can push back if they think we're going about it the wrong way
18:05:22 * walters has to run too, but thinks are on a roughly good track here and is hopeful =)
18:05:24 <dgilmore> poelcat: right
18:06:04 <stickster> OK, there are enough people that have to fly the coop that we should probably end this meeting.
18:06:17 * poelcat still not clear on what the next steps are
18:06:37 <poelcat> i don't want to let our progress slip away :)
18:06:44 <stickster> poelcat: The next steps are for the Board to set up the specific guidance we want to issue to FESCo.
18:07:03 <poelcat> who on the board is going to write the proposal?
18:07:05 <wwoods> stickster: it's a good start, to b sure
18:07:17 <stickster> We'll do that on board-private -- not to hide it but because there's no sense in inviting a thread on advisory-board that looks just like the one on devel.
18:07:38 <poelcat> stickster: or on a wiki page
18:08:00 <stickster> poelcat: Yes, good point -- we can draft there.
18:08:07 <ctyler> or both :-)
18:08:30 <stickster> Once we've got Board agreement, which we may not have to wait until next meeting to do, I'll send a note to Kevin Fenzi so he knows it's ready.
18:08:42 <poelcat> okay, next action is clearer to me :)
18:08:44 <poelcat> thanks
18:09:33 <stickster> If it's not ready for the next FESCo meeting, I wouldn't disagree with FESCo waiting. I don't want to dictate that to Kevin &co., but it seems like it might be counterproductive if they don't have our statement to go by.
18:10:07 <ctyler> Ok, so we should officially ping 'em on this, just to dot i's and cross t's.
18:10:31 <stickster> ctyler: Yes. I'll do that unless someone's already beat me to the punch. :-)
18:10:50 <stickster> #action stickster to direct FESCo to today's meeting logs
18:11:57 <stickster> jwb said he wanted to be in on writing the wiki page
18:12:00 <stickster> So...
18:12:29 <mmcgrath> stickster: are we actually in a meeting?
18:12:31 <mmcgrath> #meetinginfo
18:12:31 <stickster> #action jwb Start wiki page for the Board's guidance/vision on updates, and send URL to Board to discuss/draft
18:12:39 <mmcgrath> #meeting info
18:12:51 * jwb sees channel go blue
18:13:00 <stickster> We should be....
18:13:05 <jwb> oh.  cute
18:13:09 <jwb> yeah, that's fine.
18:13:15 * jwb goes back to other meeting
18:13:36 <mmcgrath> <nod> it's working
18:14:59 <mmcgrath> stickster: so meeting over?
18:15:05 * stickster pondering any other action item
18:15:40 <stickster> #info Board to notify FESCo once we have agreement so they can go forward with an implementation that makes sense, and some plan for assessing effectiveness
18:15:44 <stickster> OK, that's probably it
18:15:57 <stickster> poelcat: mmcgrath: *: Any other steps we need to capture?
18:16:34 <stickster> Ending meeting in 15
18:16:46 <stickster> Ending meeting in 5
18:16:54 <stickster> #endmeeting