17:12:18 #startmeeting 17:12:19 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:12:23 #meetingname Fedora Board 17:12:24 The meeting name has been set to 'fedora_board' 17:12:27 I'm going to go watch tv. 17:12:31 #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 17:13:00 * mdomsch 17:13:14 I know spot is around too. 17:13:19 * caillon notes that mdomsch is on both sides of the line today 17:13:24 yeah, i'm here 17:13:30 #topic Audio meeting FAIL 17:13:54 welcome to the edge 17:13:55 I'm half tempted to put a stop to FAD's that work on infrastructure because this happens. 17:14:04 When people do work and walk away, the result is bad. 17:14:04 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 the silence was peaceful 17:14:31 mmcgrath: Actually, I got help on what I was working on on Friday, I think you may be jumping to conclusions 17:14:39 jsmith helped me out 17:14:44 stickster: I think asterisk is still busted. 17:14:54 results speak. 17:15:14 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 Let's see what we can do to size up and fix the problem later. 17:16:20 Shall we move on? 17:16:28 * poelcat still wants to praise thank all the people that got it working 17:16:39 it has made a number of my meetings 100x easier! 17:16:52 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 this is a temporary setback 17:17:10 * stickster uses Fedora Talk quite a bit as well, it's really helpful 17:17:18 poelcat: except this isn't the first time we've had problems with the system. 17:17:19 As have many FADs and other events.. 17:17:31 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 Thanks caillon 17:18:45 Let's move on. 17:18:49 #topic Community Q&A 17:18:49 mmcgrath, you see this as an instance of a larger problem - lack of maintenance/sustainers involved in infrastructure ? 17:19:04 Or not :-) 17:19:05 #undo 17:19:06 Removing item from minutes: 17:19:12 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 what's susmit? 17:19:53 a person doing some kind of web app work for the cd media thing 17:19:55 susmit is an ambassador in India, and champions the FreeMedia project 17:20:02 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 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 ah... 17:20:26 * poelcat thinks it is inappropriate to be discussing this here and in this way 17:20:42 poelcat: we had no agenda today 17:20:57 mmcgrath: Not really correct, we are here to do a community Q&A. 17:21:03 bring it. 17:21:05 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 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 mmcgrath: referring to the OS as a cluster**** is trashing people and effort. 17:22:03 fine, our OS is not a cluster$#@^ 17:22:08 everyone's happy now. 17:22:18 #topic Community Q&A 17:22:43 OK, let's see what we've got in the -questions channel 17:23:40 yeah. 17:24:44 Go ahead wwoods 17:24:45 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 And that the #1 item that needed improvement was... QA 17:25:24 a) do you remember this, or did I dream it? Do you have those slides anywhere? 17:25:59 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 I'm sure that at some point I talked about the need for more contributors in QA 17:26:58 It may have been at e.g. LinuxTag/FUDCon EMEA among other places 17:27:06 2008 probably? 17:27:55 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 Some are easier to solve with automation 17:28:18 Some are easier to solve by having people agree on processes 17:28:38 For instance, un-subtle things like broken dependencies are clearly in the first category 17:29:14 More subtle problems are harder to fit there. 17:29:30 (2008 sounds about right - that would have been the F10 FUDCon in Boston, roughly 20 months ago now) 17:30:07 there are some technical steps we could take that are imminently feasible, but we need to look for budget for 17:30:09 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 wwoods hasn't Red Hat recently added more people to your group? 17:30:17 e.g. doing repoclosure before pushing out any updates 17:30:38 ------------------------------------------------------------------------------------------------------------- 17:30:42 opps 17:30:45 poelcat: yes - we have some new fulltime employees and interns working exclusively on Fedora QA 17:31:01 mdomsch: having dell donate a second equallogix would help 17:31:02 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 wwoods: i would see that as a greater committment from Fedora to QA (via Red Hat) :) 17:31:09 repoclosure is disk-intensive - throwing SSDs at it might help 17:31:20 dgilmore, would that I could... 17:31:32 But certainly as a *framework* AutoQA is going to help -- as a platform to which Fedora people can contribute 17:32:09 mdomsch: don't get too deep into implementation details - repoclosure is almost certainly not going to be the solution 17:32:54 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 which we can mitigate if it's that important 17:33:16 obviously would help there if we slowed down updates ;) 17:33:27 mdomsch: right, I agree, and we're actively working on feasible implementations for the problems we've identified. 17:33:40 wwoods: Is there something you have in mind that you want the Board to answer here? 17:35:23 Well. The question I really want an answer to is this: 17:35:47 if stability and quality are a stated goal, and we have an always-available place for new changes and unstable development 17:35:58 why do we allow anything but bugfixes in stable releases? 17:36:13 wwoods: I don't think stability and quality are a stated goal. 17:36:26 at least not yet 17:36:33 (which probably resolves to the meta-questions: "are these really our goals" and "whose responsibility is it to decide this") 17:37:32 wwoods, that's the flamewar on devel@ this week in a nutshell 17:37:43 There are several proposals for FESCo to consider 17:37:56 https://fedoraproject.org/wiki/Release_Lifecycle_Proposals 17:38:11 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 should FESCo wish to consult with or punt to the Board, we'll take it on 17:38:28 The question is, who is responsible for picking between them? And on what basis do they decide? 17:39:12 mmcgrath: updates is an agenda item 17:39:12 at the moment, I think they can only go off what they, FESCo, would like to see. 17:39:20 The Board's historically delegated to FESCo the matters dealing with building the distribution 17:39:48 but it's not just building the distribution, the updates directly impact the user experience 17:40:09 wwoods: i think the best definition about our purpose right now is https://fedoraproject.org/wiki/Objectives 17:40:29 #link https://fedoraproject.org/wiki/Release_Lifecycle_Proposals 17:40:29 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 Right now the very broad guideline on Objectives concerning updates is "Provide timely updates" 17:41:28 But that has different meanings to different groups 17:41:31 wwoods: in the context of stability and quality as stated goals 17:42:45 there's a line in those objectives that i think we want to look at: 17:42:55 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 really? we prefer to do that? 17:44:04 jwb: i think that could be fixed with a few more specifics 17:44:07 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 And maybe it's time to think about changing that. 17:44:26 yes, i think it is 17:44:59 our community has nothing to go off of other than our wiki pages for items like this 17:45:53 that's a pretty sweeping statement 17:46:14 which? the line in the wiki page, or mine? 17:46:19 in the proposal I added (url above), we would slow down updates to the older releases 17:46:27 jwb, sorry, the wiki page 17:46:29 making sweeping statements seems to be the latest trend. :/ 17:46:33 ah, ok 17:46:44 The Board has to carefully walk a line between handing down dictatorial edicts, and giving clarity to the community where needed. 17:46:45 i would really like to at least get rough consensus on pushing non-security no more than once a month 17:46:55 i thought there was that consesus at the last fudcon 17:46:56 I like the fact that a couple Board members stepped in with proposals on the release lifecycle page. 17:46:59 *consensus 17:47:19 walters, perhaps among the people at FUDCon. that isn't enough to make it happen 17:47:37 walters: fwiw, i don't think i agree with that. 17:47:43 =( 17:47:51 nor i 17:48:06 three weeks? 17:48:14 2? 17:48:16 notting mentioned he's worried about FESCo overstepping their bounds wrt updates. 17:48:19 jwb, think of all the time you'd get back... :-) 17:48:27 can we give them full power to decide that and then ask them to decide? 17:48:43 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 walters: would you like to wait two weeks for the update that fixes the bug you have today? 17:48:59 what is the magic number of acceptability? 17:49:19 spot: anyone who seriously needs a specific bugfix can do a direct koji pull 17:49:29 Before we get into rehashing all the various branches of the discussion that already happened on devel@... 17:49:35 false dichotomy - if you need the fix today, it's in updates-testing 17:49:46 walters: i think that is beyond the average user. 17:49:54 spot: it doesn't have to be 17:50:01 i think it's also a crappy user experience 17:50:03 anyways, yes i agree stickster 17:50:32 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 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 ctyler: I agree. 17:50:56 SWF Monday? 17:51:00 SWG* 17:51:12 who is writing the proposal? 17:51:20 stickster: I think it is not 17:51:31 ctyler, i'd like to be a part of that discussion and i can't make the SWG meetings 17:51:43 poelcat: how about we start with a scope? 17:51:43 stickster, i don't think it is either 17:51:58 we could have another SWG at a different time to accommodate 17:52:14 stickster: i definitely agree 17:52:15 jwb: SWG considers then brings to the board, it's an accelerator 17:52:15 mdomsch: with different members 17:52:22 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 poelcat, sure; just another subset, maybe overlapping 17:52:45 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 i just can't do the current SWG timeslot 17:52:58 spot: what if we just tried it? like poelstra's blog 17:53:03 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 spot: Maybe. We don't need to fix that detail here, nor does the Board need to describe a timeline. 17:53:45 walters: like a controlled trial? two weeks and the re-evaluate? 17:53:50 it will annoy the casual user, do nothing to help the expert user 17:53:56 spot: i agree type of update is important too, but if we don't control the rate QA is impossible 17:53:57 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 spot: it allows packages I currently have installed to be more of a moving target then they would be otherwise. 17:54:20 We need to also keep in mind that one of Fedora's precepts (the 5th and 6th Fs) 17:54:24 are FAIL FASTER. 17:54:24 rate is a byproduct of policy 17:54:30 We should not be afraid to TRY something. 17:54:32 spot: rate change is not very useful in preventing surprises unless update clustering improves testing, which it could 17:54:54 poelcat: well i think we'd have to evaluate a policy of pushing once a month for longer than two weeks ;) 17:54:56 stickster: yes, within specific bounds and for a trial period if applicable 17:55:01 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 And I think this meeting is not the right place to dicker over timeframes like "2 weeks" vs. "1 week". 17:55:20 So wait, are we deciding the updates issue is a board issue or FESCo one? 17:55:28 IOW run experiments and see what we learn vs. speculating on what the results of the experiement would be 17:55:34 i pretty strongly think the big picture is a board issue 17:55:46 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 whether there are multiple repos etc. is fesco 17:56:03 walters: can you resummarize what the big picture is we would need to give guidance on is? 17:57:04 poelcat, something similar to the proposal from mccann and I back in December. 17:57:21 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 caillon, that proposal was large, and very implementation specific. it is not a vision statement 17:57:39 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 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 stickster: I mean can we actually come out and say that in our notes and follow up with FESCo next week? 17:59:11 i'd be for that 17:59:37 * spot is not opposed to that 17:59:53 sounds like a good start 17:59:53 that sounds fine to me 17:59:59 * mmcgrath is fine with that thing I just said :) 18:00:01 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 but whatever 18:00:27 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 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 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 spot: OK, thanks for being here 18:01:21 * caillon too, movers are coming in a few minutes 18:01:25 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 mdomsch: yeah 18:01:37 mdomsch: that seems like a good summary to me yes 18:01:53 mdomsch: I think that's the right place for us to be in this conversation, don't you? 18:01:56 mdomsch: well, we're kind of dictating that the policy needs to be more granular and predictable. 18:02:02 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 mmcgrath: Right, something better than "We don't know, do what you feel is right Luke." 18:02:43 i have to leave for another meeting. i'll try and review minutes later 18:02:45 * jwb & 18:02:47 so that our request to FESCo is not ambiguous 18:02:48 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 where are we leaving things for today? 18:03:25 mdomsch: We can probably explore how much detail we're comfortable laying out to help FESCo 18:03:47 I'm just trying to respect expected boundaries is all 18:04:01 I don't know exactly where that line is here; luckily we've got representation on both sides of it 18:04:09 so shouldn't be too painful in practice 18:04:26 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 mdomsch: I honestly think its ok for the board to say this is what we would like to see 18:04:43 and FESCo make it happen 18:04:55 So hopefully we can draw a line from that as a rationale, which I think would be helpful for FESCo. 18:04:55 yep 18:05:05 If it's not, I'm sure they'll have no problem telling us so. ;-) 18:05:12 ok 18:05:16 wwoods: So was that an answer to your question? ;-) 18:05:17 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 poelcat: right 18:06:04 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 i don't want to let our progress slip away :) 18:06:44 poelcat: The next steps are for the Board to set up the specific guidance we want to issue to FESCo. 18:07:03 who on the board is going to write the proposal? 18:07:05 stickster: it's a good start, to b sure 18:07:17 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 stickster: or on a wiki page 18:08:00 poelcat: Yes, good point -- we can draft there. 18:08:07 or both :-) 18:08:30 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 okay, next action is clearer to me :) 18:08:44 thanks 18:09:33 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 Ok, so we should officially ping 'em on this, just to dot i's and cross t's. 18:10:31 ctyler: Yes. I'll do that unless someone's already beat me to the punch. :-) 18:10:50 #action stickster to direct FESCo to today's meeting logs 18:11:57 jwb said he wanted to be in on writing the wiki page 18:12:00 So... 18:12:29 stickster: are we actually in a meeting? 18:12:31 #meetinginfo 18:12:31 #action jwb Start wiki page for the Board's guidance/vision on updates, and send URL to Board to discuss/draft 18:12:39 #meeting info 18:12:51 * jwb sees channel go blue 18:13:00 We should be.... 18:13:05 oh. cute 18:13:09 yeah, that's fine. 18:13:15 * jwb goes back to other meeting 18:13:36 it's working 18:14:59 stickster: so meeting over? 18:15:05 * stickster pondering any other action item 18:15:40 #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 OK, that's probably it 18:15:57 poelcat: mmcgrath: *: Any other steps we need to capture? 18:16:34 Ending meeting in 15 18:16:46 Ending meeting in 5 18:16:54 #endmeeting