19:00:02 <nirik> #startmeeting FESCO (2010-04-20)
19:00:02 <nirik> #meetingname fesco
19:00:02 <nirik> #chair dgilmore notting nirik skvidal Kevin_Kofler ajax pjones cwickert mjg59
19:00:02 <nirik> #topic init process
19:00:03 <zodbot> Meeting started Tue Apr 20 19:00:02 2010 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:04 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:06 <zodbot> The meeting name has been set to 'fesco'
19:00:07 <zodbot> Current chairs: Kevin_Kofler ajax cwickert dgilmore mjg59 nirik notting pjones skvidal
19:00:22 * dgilmore is here
19:00:25 * pjones is too
19:01:02 * nirik thinks he's here.
19:01:09 * notting is here
19:01:51 <Kevin_Kofler> Present.
19:02:24 * cwickert is here
19:03:08 <ajax> howdy
19:03:21 <nirik> ok, lets go ahead then...
19:03:29 <nirik> #topic #351 Create a policy for updates
19:03:44 <nirik> I left this on the agenda for any status updates on implementation.
19:03:52 <Kevin_Kofler> I have some evidence that the critical path process, on which this new process is being based on, just plain does not work.
19:03:54 <nirik> I'm afraid I didn't have much time to work on it last week.
19:04:26 <Kevin_Kofler> This HAL freeze override: https://admin.fedoraproject.org/updates/hal-0.5.14-3.fc13 causes a big regression in KDE (which should be obvious even from the description).
19:04:28 <nirik> next steps would be: propose comp group changes for other de's and applications.
19:04:48 <mjg59> Kevin_Kofler: And the KDE maintainer was notified ahead of time
19:04:57 <Kevin_Kofler> It got fixed by a kdebase-runtime freeze override, pushed directly to stable (which is thankfully still possible).
19:04:59 <Kevin_Kofler> mjg59: No.
19:05:04 <Kevin_Kofler> You only talked about Rawhide.
19:05:16 <Kevin_Kofler> At no point did you ever tell us that you were pushing this to F13.
19:05:43 <Kevin_Kofler> And it should have been obvious to you that this was only possible in a coordinated grouped push, not the way you did it.
19:05:44 * nirik doesn't think this has anything to do with the updates infrastructure... more communication needed/helpful.
19:05:46 <pjones> so, now that we've instantly delved as far as "he said, she said", ...
19:05:57 <cwickert> I agree there was a communication breakdown, but for me this doesn't have to do anything with the update policy
19:06:00 <Kevin_Kofler> pjones: Except I have evidence.
19:06:01 <mjg59> #fedora-kde.29.log:29-03-2010 19:23:15 > mjg59: rdieter_work: Ok, I just committed that to F13
19:06:16 <mjg59> #fedora-kde.29.log:29-03-2010 19:26:03 > mjg59: Hal's critpath, though
19:06:16 <mjg59> #fedora-kde.29.log:29-03-2010 19:26:18 > mjg59: So it'll take a little while to get through
19:06:22 * EvilBob gets more popcorn out
19:06:52 <Kevin_Kofler> Oh, so you told us on IRC, fun. I wasn't even online when you posted that.
19:07:00 <mjg59> rdieter said he would deal with it
19:07:00 <cwickert> mjg59: 2009-03-29 is 6 days after beta freeze
19:07:21 <mjg59> cwickert: Yes. That's why I didn't attempt to move it through the process any faster.
19:07:29 <Kevin_Kofler> Your e-mail announcement was only about Rawhide, as a look to the archives will confirm.
19:08:01 <mjg59> So, yes, there are questions here
19:08:06 <cwickert> mjg59: changes like this are not supposed to happen after beta freeze. Xfce and LXDE are affected to and you never notified us, did you?
19:08:07 <nirik> so, from this I think we learn that we need more communication and announcements about such changes.
19:08:08 <pjones> ... which presumably explains why he felt the need to tell somebody about F13 as well.
19:08:13 <Kevin_Kofler> Anyway, the thing is that this should never have been pushed as a non-grouped update, and the critpath process failed to catch the regression.
19:08:36 <Kevin_Kofler> I also wonder how it is possible that nirik +1ed that update if it breaks XFCE.
19:08:36 <pjones> Kevin_Kofler: why didn't you comment on https://admin.fedoraproject.org/updates/hal-0.5.14-3.fc13 instead of just raising a fuss here?
19:08:41 <nirik> Kevin_Kofler: the current 'crtipath' doesn't include kde/lxde/xfce. The new not yet implemented thing should.
19:08:52 <nirik> Kevin_Kofler: I added it to the xfce spin at that time.
19:08:54 <Kevin_Kofler> pjones: Because the fuss I'm raising is about critpath not having worked.
19:08:57 <nirik> as cwickert did for lxde
19:09:06 <Kevin_Kofler> And the update was already stable when we noticed.
19:09:18 <Kevin_Kofler> So commenting in Bodhi would not have helped anyway.
19:09:21 <nirik> It worked fine for the current setup. This shows the need to add other DE's in.
19:09:22 <pjones> Kevin_Kofler: it looks to me like you're trying to make the current process fail.  And this has nothing to do with critpath at all.
19:09:26 <Kevin_Kofler> Pushing a fix did, which we did.
19:09:31 <cwickert> nirik: but only after the spins were broken. Thunar still lacks a dep on the storage addon
19:09:46 <Kevin_Kofler> And this is now fixed, THANKS TO DIRECT STABLE PUSHES which you want to ban!
19:09:50 <cwickert> Kevin_Kofler: but your initial process was something different: that critical path process prevented you from fixing the problem
19:09:55 <Kevin_Kofler> Otherwise the bug would still be there.
19:10:05 <pjones> A push to F13 is not direct to stable.
19:10:07 <nirik> cwickert: good point. We should add that for sure.
19:10:11 <Kevin_Kofler> pjones: It is.
19:10:18 <pjones> how do you figure?
19:10:20 <notting> anyway
19:10:26 <Kevin_Kofler> https://bugzilla.redhat.com/show_bug.cgi?id=579256#c7
19:10:29 <nirik> anyhow, is this anything to do with this meeting anymore?
19:10:34 <nirik> Shall we move on?
19:10:40 <Kevin_Kofler> It'll show up in the next branched report.
19:10:40 <notting> i don't see the leap from "this one case it didn't work very well" to "kill it kill it with fire" like kkofler appears to be proposing. so, move on?
19:10:57 <Kevin_Kofler> notting: Not only did the process fail to prevent the issue.
19:11:14 <Kevin_Kofler> Your proposed additional process would also ban us from fixing it as promptly as we did!
19:11:19 <cwickert> Kevin_Kofler: why is a direct stable push the only fix? not permitting direct stable pushes doesn't mean you have to wait a week. I suggest you read the policy again
19:11:21 <nirik> Kevin_Kofler: the current process didn't prevent it. Please help us implement the new one that would have?
19:11:21 <dgilmore> notting: any excuse to destroy it
19:11:37 <ajax> i want an oompa loompa now, daddy.
19:11:43 <Kevin_Kofler> How does a single added Requires which has even been tested in Rawhide for a few weeks need ANY testing?
19:11:58 <Kevin_Kofler> nirik: How would the new process have prevented it?
19:12:05 <Kevin_Kofler> This update had ALL the required criteria!
19:12:24 <Kevin_Kofler> +1 from you as cvsadmin, +1 from another tester, over a week in testing.
19:12:44 <Kevin_Kofler> And the over a week in testing wouldn't even be required under the new process given the rest.
19:12:50 <cwickert> Kevin_Kofler: if it was in testing for a week, why did none of the KDE maintainers note it?
19:12:57 <nirik> well, the current critpath doesn't include kde, but the new one does? agreed that it could have been caught anyhow.
19:13:02 <Kevin_Kofler> Because testing does not work.
19:13:06 <cwickert> especially after rdieter knew about it
19:13:16 <Kevin_Kofler> Testing will NEVER catch ALL issues.
19:13:17 <nirik> goto 10
19:13:26 <Kevin_Kofler> There will ALWAYS be regressions needing quick fixing => direct stable pushes.
19:13:39 <mjg59> I think we had this conversation over a month ago
19:13:43 <nirik> ok, I'm going to move on now.
19:13:45 <notting> Kevin_Kofler: we've heard this before from you. you shouting again is unlikely to do anything more than irritate people into ignoring you.
19:13:52 <nirik> #topic #365 fesco list management questions
19:13:59 <nirik> .fesco 365
19:14:01 <zodbot> nirik: #365 (fesco list management questions) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/365
19:14:07 <nirik> So, we have a nice history lesson from abadger1999
19:14:33 <Kevin_Kofler> mjg59: But there's new evidence! And thank you for providing it with your completely inconsiderate freeze break which was just completely inappropriate for F13.
19:14:38 <dgilmore> We have in the past removed people from the list
19:14:48 <Kevin_Kofler> mjg59: It was too late for this kind of changes!
19:14:55 <dgilmore> I know i was removed when not in fesco at one point
19:15:07 <nirik> dgilmore: have we? I don't think we have... but not sure if we have a way to tell.
19:15:08 <dgilmore> but we have not at all been consistent in doing that
19:15:10 <Kevin_Kofler> But to the new topic: IMHO only people actually on the current FESCo should be on that ML.
19:15:10 <abadger1999> dgilmore: According to bpepple we did not.
19:15:24 <Kevin_Kofler> I don't see why I should continue getting FESCo e-mails for life. ;-)
19:15:24 <dgilmore> abadger1999: pre bpepple time we did
19:15:42 <dgilmore> abadger1999: it was many many moons ago
19:15:49 <abadger1999> dgilmore: We didn't consistently.
19:15:57 <dgilmore> abadger1999: right
19:15:59 <abadger1999> dgilmore: I was on fesco many moons ago :-)
19:16:12 <bpepple> dgilmore: we added poelcat since he was the feature wrangler and paul since he was project leader.
19:16:16 <abadger1999> s/consitently/either we didn't or we didn't consistently/
19:16:28 <bpepple> I believe they were the only ones that were not on FESCo to be on the list.
19:16:45 * notting would propose 'current fesco members' + 'feature wrangler' + 'project leader'. but we should definitely codify adding/dropping people upon fesco changes
19:16:49 <notting> althogh
19:16:56 <notting> with trac now, do we need the feature wrangler on list?
19:16:58 <notting> poelcat?
19:17:49 <notting> i could be wrong, but i think having poelcat on the list predates using trac for agenda items
19:17:52 <nirik> yeah, I would think current members + project leader. Changed whenever those change.
19:18:04 <poelcat> notting: i follow the feature discussion
19:18:12 <tibbs> I'm perfectly happy to not be on the FESCo list, FWIW.
19:18:35 <abadger1999> bpepple: Did we have a rationale for leaving people on the list?
19:18:50 <dgilmore> abadger1999: probably overlooked
19:18:56 <abadger1999> dgilmore: It wasn't
19:19:05 <nirik> I think the rationale was that emertius members might have valuable input.
19:19:12 <abadger1999> dgilmore: jds2001 was specifically told that that was what we do.
19:19:34 <bpepple> abadger1999: specifically, I don't think so, other than doing time/experience being on FESCo for dealing with things with legacy questions that might come up.
19:19:35 <abadger1999> I want to know if there was a reason or if the rason was just "tradition!"
19:19:38 <nirik> I'd like to see the fesco list just used for spewing trac tickets to members and thats it personally.
19:19:55 <cwickert> +1
19:19:56 <abadger1999> nirik: +1
19:20:15 <dgilmore> I think FESCo can always ask for input from old members as needed
19:20:25 <nirik> but I'm ok with FPC as well in case they wish to send a sensitive issue to us
19:20:47 * notting is trying to figure out what a 'sensitive FPC issue' would be
19:20:49 <abadger1999> nirik: The FPC wouldn't need to be subscribed to fesco-list for that.
19:20:57 <nirik> sorry, FPL
19:21:06 <nirik> too many acronyms.
19:21:38 <nirik> I'm not sure what issues the project leader would need to send us in private either really... .
19:21:47 <abadger1999> nirik: Just in case you want the FPL to be able to follow what tickets (discussions that are happening in private) to be able to read the list.
19:22:12 <abadger1999> Anyone should be able to send to fesco-list... that's what was decided as its purpose.
19:22:20 <nirik> yeah.
19:22:34 * cwickert would like to see the fesco list open to public, but this is not possible atm
19:23:03 <abadger1999> I'm somewhat in agreement with cwickert.
19:23:34 <abadger1999> Take the old archives and leave them somewhere private (unless reviewed and brought into the open).
19:23:35 <nirik> thats mostly due to archives I fear.
19:23:48 <cwickert> abadger1999: +1
19:23:51 <abadger1999> Re create the fesco list with public access.
19:24:05 <Kevin_Kofler> Why can't public stuff be in Trac?
19:24:57 <nirik> yeah, it should be.
19:25:00 <abadger1999> Kevin_Kofler: It should be... but people keep using fesco-list for discussing items.
19:25:18 <pjones> almost as if it's a more natural medium for discussion.
19:25:40 <abadger1999> I've come to believe it must be something deeply embedded in the hacker psyche :-)
19:26:18 <Kevin_Kofler> I've never understood all this love for mailing lists, IMHO they're highly impractical (and I'm glad Gmane offers NNTP gateways I can use with KNode).
19:26:43 <nirik> How about:  current fesco + FPL on the list, fesco chair to berate people who post to the list when they should be posting publicly?
19:26:58 <ajax> nirik: a fine idea.  +1.
19:26:59 <Kevin_Kofler> nirik: +1
19:27:02 * notting is fine with that. +1
19:27:19 <mjg59> +1
19:27:52 <cwickert> +1
19:28:19 <nirik> going once...
19:28:31 <Kevin_Kofler> Next topic please?
19:28:43 <pjones> +1
19:28:50 <nirik> #agreed The fesco list will only have the current fesco + FPL on it. Members will be urged to post publicly if at all possible.
19:29:03 <nirik> #action nirik will update the fesco web page on this.
19:29:15 <nirik> #topic FES Tickets
19:29:18 <nirik> https://fedorahosted.org/fedora-engineering-services/report/6
19:29:28 <nirik> mmcgrath: anything special to report this week?
19:29:37 <nirik> broken deps are way down.
19:29:55 <mmcgrath> Nothing major, bruno broke up his ticket (FTBFS) into a few smaller tickets, we'll be working through those.
19:30:09 <nirik> oh, on https://fedorahosted.org/fedora-engineering-services/ticket/10
19:30:10 <mmcgrath> I've been tracking the F13 broken deps pretty closely
19:30:29 <nirik> the voting thing. Did we ever determine how we wanted to tweak voting in our bugzilla instance?
19:30:31 <mmcgrath> Yeah that's the other thing, I can run that script regularly but I'm not sure what good it'd do.
19:30:44 <mmcgrath> nope, only that I think we can if we know.
19:30:48 <nirik> well, we need to adjust it so it's more useful I think.
19:31:19 <nirik> Any thoughts from fesco folks? What should we request of our bugzilla?
19:32:03 <notting> i'd be happy with only a few votes per bug max. of course, if no one votes at all, it's still open to skewing
19:32:13 <ajax> to remind, bugzilla upstream works like this:
19:32:27 <Kevin_Kofler> I'm for disabling votes entirely.
19:32:49 <Kevin_Kofler> (in Bugzilla)
19:32:54 <ajax> you have two numbers, per product.  one is "maximum votes per person", and one is "maximum votes for one person on one bug"
19:33:13 <pjones> I don't actually believe voting on bugs is in any way a good idea.
19:33:15 <nirik> ok, and currently we have what? 100 and 100?
19:33:27 <ajax> pretty sure that's not modified in rhbz, which means we'd be at 100 and 100, yes.
19:33:38 <nirik> ok, so thats 2 votes for 'disable it entirely' ?
19:34:00 <ajax> i'm all for disabling bz voting, yeah.
19:34:05 <nirik> I think it can be useful to show bugs that affect a large number of people and might deserve more attention
19:34:32 <ajax> that's possible, but.
19:34:37 <nirik> and sure perhaps the maintainer can't do so, but if we know these we can poke upstream developers, try and get more traction, etc.
19:34:43 <ajax> as someone who owns a lot of bugs that affect a lot of people... meh.
19:34:43 <pjones> nirik: I think enough of those people will leave "me too" comments even with voting.
19:34:49 <ajax> i don't look at votes as it is.
19:34:53 <dgilmore> i think it can help give visability to a bug thats effecting lots of people
19:35:02 <dgilmore> but a big CC list should give that also
19:35:09 <nirik> pjones: but thats only visible to the maintainer.
19:35:12 <pjones> dgilmore: I think that _might_ have some validity if developers actually looked at it, but I don't think we do.
19:35:27 <ajax> i think there are other ways of statistically inferring bug "heat" without looking at votes.
19:35:40 <nirik> good point... would "most cc'ed bugs" be a useful thing to know for this?
19:35:46 <ajax> cc list, comment activity histogram, ...
19:35:48 <nirik> ie, vote with your mailbox.
19:35:58 <pjones> plausibly.
19:36:29 <pjones> the other problem with "voting" is that it further encourages people to "hop on" with even less in-depth understanding of the problem,
19:36:43 <pjones> which encourages the already existing problem of people mis-identifying their problem as another problem.
19:37:14 <nirik> ok, so if we ditch voting entirely, and do something with 'bugs with most cc' and 'bugs with most comments in the last week' would that be of help ?
19:38:08 <notting> that sounds a little more useful
19:38:10 <ajax> sounds reasonable to me.
19:38:14 <pjones> yeah
19:38:34 <nirik> mmcgrath: ok, can we update the ticket with that and see if we can get something? or close that one and open a new one?
19:38:46 <mmcgrath> nirik: go ahead and upate
19:38:58 <nirik> we might also want to file a bugzilla bug to disable voting if we are never going to use it.
19:39:04 <nirik> mmcgrath: ok.
19:39:27 <nirik> #agreed will drop voting, and look at most cc'ed bugs and most comments in previous timeperiod instead.
19:39:36 <nirik> ok, anything else on any FES tickets?
19:40:03 <nirik> ok, moving on
19:40:06 <Kevin_Kofler> nirik: Yes, we should get voting disabled in Bugzilla.
19:40:21 <nirik> Kevin_Kofler: yep. Sounds like.
19:40:21 <Kevin_Kofler> It doesn't make sense to tell people they can vote if we're throwing it away anyway.
19:40:27 <nirik> #topic Open Floor
19:40:34 <nirik> ok, anything for Open Floor?
19:41:28 * nirik listens to the crickets
19:41:30 <ajax> apologies for not looking at the mediawiki patch issue, i've been a bit busy with f13 blockers.
19:41:36 <ajax> that's all i had though.
19:41:44 <nirik> Oh, reminder that election nominations start this Saturday.
19:42:11 <notting> how long is the nomination period?
19:42:22 <nirik> The following seats will be open: Kevin Fenzi (nirik) (Chair), Dennis Gilmore (dgilmore), Bill Nottingham (notting), Seth Vidal (skvidal) and Kevin Kofler (kkofler)
19:42:28 * nirik looks.
19:42:37 * dgilmore notes he is not re-running
19:42:50 <nirik> https://fedoraproject.org/wiki/Elections
19:43:00 <nirik> Apr 24 - May 2nd
19:43:34 <nirik> ok, if nothing else, will close out the meeting in a few here.
19:43:40 * cwickert still needs to create a proposal on the dependency issues, but his new job leaves only very little time
19:43:53 <cwickert> I'll get back to that next week
19:44:02 <nirik> cwickert: yeah, know the feeling. Thanks.
19:44:04 <cwickert> we are not in a hurry as things won't change for F13 anyway
19:44:13 <nirik> ok, thanks for coming everyone!
19:44:21 <nirik> #endmeeting