16:59:59 <nirik> #startmeeting FESCo meeting 20090918
16:59:59 <zodbot> Meeting started Fri Sep 18 16:59:59 2009 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:59:59 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:04 <nirik> #chair dgilmore jwb notting nirik sharkcz jds2001 j-rod skvidal Kevin_Kofler
17:00:04 <zodbot> Current chairs: Kevin_Kofler dgilmore j-rod jds2001 jwb nirik notting sharkcz skvidal
17:00:14 <nirik> who all is around for todays FESCo meeting?
17:00:20 * sharkcz is here
17:00:41 <Kevin_Kofler> Present.
17:01:09 <Kevin_Kofler> nirik: Hey, you started a second early! ;-)
17:01:14 * notting is here
17:01:25 * nirik checks his ntp server. ;)
17:02:04 <nirik> man, ntp not running... 2seconds off. ;(
17:03:14 <nirik> we don't have quorm yet, do we?
17:04:24 <nirik> skvidal / dgilmore ? you guys around?
17:05:24 * nirik guesses it will be a pretty short meeting today then.
17:05:31 <Kevin_Kofler> We could get up to +5 for Till's sponsor application counting jds2001's +1 from Trac.
17:05:53 <Kevin_Kofler> (assuming we all vote for it, otherwise we won't have a quorum :-) )
17:06:07 <sharkcz> yes, he get +1 from me
17:06:07 <j-rod> sorry, here now
17:06:15 <nirik> cool. Lets get started then.
17:06:25 <nirik> #topic sponsor application by Till Maas
17:06:31 <nirik> .fesco 252
17:06:32 <zodbot> nirik: #252 (sponsor application by Till Maas) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/252
17:06:41 <nirik> jds2001 was +1 in the ticket.
17:06:45 <j-rod> +1 for till, very worthy, all positive feedback on the list
17:06:46 <Kevin_Kofler> +1, apparently no objections from anyone.
17:06:48 <sharkcz> +1
17:07:00 * notting is +1 to till
17:07:10 <nirik> +1 from me as well, I think he will do a good job.
17:07:29 <nirik> #action sponsorship approved for Till Maas
17:07:37 <nirik> #topic simplify non-responsive maintainer process
17:07:46 <nirik> .fesco 251
17:07:47 <zodbot> nirik: #251 (simplify non-responsive maintainer process) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/251
17:08:31 <nirik> I think the current procedure does have issues and should be revisited. I think the proposed solution might be too far the other way.
17:09:09 <Kevin_Kofler> Right (and jds2001 said something similar on Trac: https://fedorahosted.org/fesco/ticket/251#comment:1 )
17:09:19 <nirik> reassigning a package after 3 days seems very quick, and could easily hit people who are vacationing, or just busy.
17:09:51 <Kevin_Kofler> It also looks like no ping directly to the maintainer is required.
17:10:08 <Kevin_Kofler> So if people aren't watching fedora-devel-list daily, they might not even know a non-responsive process is running against them.
17:10:21 <notting> i'm not sure why there's even a time period. why not request just goes to agenda for the next meeting?
17:10:21 <Kevin_Kofler> That sounds a bit radical to me.
17:10:32 <nirik> Perhaps it would be possible to bring to the attention of a provenpackager to fix the immediate issue, then the maintainership could be moved later if the maintainer still doesn't respond.
17:10:48 <Kevin_Kofler> nirik: I agree with that.
17:11:16 <tyll> That's not what I meant. I want it more changed to recommend the current procedure, but in case it is pretty obvious that the person is non-responsive, then a faster approach should be possible.
17:11:17 <nirik> part of the problem with that tho is that provenpackagers fix something, the bug gets closed, people move on, and the package really is still unmaintained.
17:11:18 <Kevin_Kofler> I think it's not so important to speed up the non-responsive process because provenpackagers can fix it (e.g. won't till be one now that we approved him as a sponsor?).
17:11:31 <Kevin_Kofler> But yes, I was about to come to that problem.
17:11:39 <nirik> tyll: so this would be a 'fast track' alternate procedure?
17:12:28 <tyll> nirik, it's more like if people already tried to reach someone but did not call it non-responsive maintainer process etc. then they could try to persuade FESCo to get this settled
17:12:31 <Kevin_Kofler> Just having provenpackagers fix the issue is good for that particular issue, but we do need to make sure the non-responsive maintainer process is started so the package gets actually maintained.
17:13:36 <nirik> right. So the question is here, when do we start that process? and can we/should we make it less a hassle for people to do that.
17:15:22 <nirik> I guess I don't have a problem with a 'fast track' type thing where a specific case is brought to fesco, but I think perhaps we could try and revisit the base procedure to make it less burdensome.
17:15:32 * nirik shuts up and waits for anyone else to have input.
17:15:46 <notting> i think the base procedure could be bettre
17:16:36 <tyll> The current process takes very long, even if there has been already similiar action performed, e.g. there was already such a process started in a current case, but it got stopped after the maintainer orphaned some packages
17:16:41 <che> wouldnt it be possible to "automate" that?
17:16:44 <che> bugs that are 2 months old and have status "new" ;)
17:17:09 <che> if that happens send a notification to a "bugzilla-noresponse" list
17:17:23 <che> i mean bugs should be atleast assigned right?
17:17:36 <Kevin_Kofler> Status NEW means no triaging, not no maintainer response.
17:17:48 <tyll> there was some Fedora health support performed a long time ago, which also contained lists of unchanged bugs for X weeks, this could be reactivated
17:17:58 <notting> there are lots of maintainers who don't necessarily bother with a new/assigned distinction
17:18:00 <j-rod> status NEW doesn't mean squat half the time
17:18:06 <j-rod> hah. what notting said.
17:18:12 <Kevin_Kofler> Maintainers will generally not touch that (maybe they should?), but more importantly, bugs will normally be moved out of NEW by triage.
17:18:48 <che> Kevin_Kofler, that doesent seem to work really though *looking at my overview page...
17:18:57 <Kevin_Kofler> So NEW or ASSIGNED measures only triage activity (and activity by those few maintainers who do this change themselves), not maintainer activity.
17:19:09 <thomasj> That behavior stops with F12 released IIRC. Then we use only a keyword "triaged"
17:19:11 <Kevin_Kofler> Well, the way we use ASSIGNED is just broken anyway.
17:19:26 <notting> however, that's a bit far afield from a general non-responsive maintainer procedure
17:19:29 <Kevin_Kofler> We abuse NEW as UNCONFIRMED, ASSIGNED as NEW and the nonstandard ON_DEV state as ASSIGNED.
17:19:35 <che> well but tying response to a status change would make it rather easy to track stuff automatically
17:19:46 <Kevin_Kofler> The problem is that RH Bugzilla's states are designed for RHEL.
17:19:49 <nirik> also, some packages have way too many incoming bugs to deal with... (kernel/etc). Would you orphan the kernel due to non response to a bug?
17:19:58 <tyll> The scripts for such status reports are here: http://cvs.fedoraproject.org/viewvc/status-report-scripts/?root=fedora
17:19:59 <Kevin_Kofler> For Fedora, something closer to upstream Bugzilla would make a lot more sense.
17:20:12 <Kevin_Kofler> But states are global in Bugzilla.
17:20:16 * nirik thinks we are getting sidetracked. ;)
17:21:59 <Kevin_Kofler> If we want to judge nonresponsiveness by the maintainer, we should be looking at the absence of comments and state changes from the maintainer, not at the current state.
17:22:18 <Kevin_Kofler> But that also doesn't always make sense.
17:22:55 <Kevin_Kofler> If a triager or a tester already answered that the bug is nonreproducible, do we really require the maintainer to parrot that?
17:23:12 <Kevin_Kofler> (and that's just one example)
17:23:58 <tyll> Then the bug could be set to needinfo-reporter
17:24:46 <nirik> looking at the proposed change, I would be ok with it if 2) was changed to 'the ticket be voted on/discussed at the next fesco meeting' instead of asking for just some fesco members to ack it.
17:25:09 <notting> so, a 'simpler' policy would be - 1) open a bug 2) wait two weeks 3) send *direct* e-mail 4) wait one week 5) escalate to fesco
17:25:10 <buggbot> Bug https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2 low, medium, ---, pbrown, CLOSED CURRENTRELEASE, broken links of default index.html
17:25:46 <nirik> silly buggbot
17:25:47 <notting> nirik: that works for m
17:25:50 <notting> nirik: that works for m
17:25:51 <notting> nirik: that works for me
17:25:57 <notting> stupid keyboard.
17:26:25 <tyll> The next fesco meeting alternative would be good too.
17:26:37 <j-rod> can we make #3 be direct email with fedora-devel-list cc'd?
17:27:16 <j-rod> then there's no doubt they've tried to make direct contact, which addresses jds2001's concerns in the ticket
17:27:23 <sharkcz> good idea
17:27:32 <che> notting, hmm that will lead to alot escalations
17:28:04 <tyll> che: there do not seem to be that many of these procedures
17:28:11 <nirik> tyll: what do you think of notting's simplifed version? would that meet your needs?
17:30:07 <tyll> nirik: I would like to have some procedure that allows to reuse old bugs or communication attempts, e.g. if I already tried to reach a maintainer several times with bigger intervals and no response
17:30:59 <nirik> tyll: ok, so you would still like a fast track ability to go to fesco because you know the maintainer hasn't responded to old bugs for a long time?
17:31:30 <tyll> nirik: yes
17:32:27 <nirik> so, how about we vote on adding the fast track, but with 2) changed to "go to fesco" and then we propose the simplification notting said to the mailing list and vote on it next week with feedback?
17:32:33 <tyll> nirik: but there should be already some ping messages in the old bug reports, so just untouced bugs wold not be enough
17:32:35 <skvidal> nim-nim: sorry I was late
17:32:40 <skvidal> err nirik
17:32:42 <notting> nirik: wfm
17:33:00 <sharkcz> nirik: work also for me
17:33:26 <Kevin_Kofler> I'd suggest a variant of notting's version: if there's a bug with no response for 2+ weeks to point to, allow starting directly at step 3 (even if the bug didn't talk about the "non-responsive maintainer process" by name).
17:33:26 * nirik finds it to work for him. ;) Other votes?
17:34:09 <Kevin_Kofler> That'd address tyll's suggestion, yet the maintainer still gets a direct mail and a week to react and FESCo can still vote it down (and request restarting at step 1) if the evidence is insufficient.
17:35:00 <tyll> that sound good, too, but I g2g now. In case you would decide this already, can you maybe decide on the current process that I pointed to at the mailing list? the link is in the ticket iirc
17:35:08 <nirik> for some maintainers I would suspect it would be easy to find a bug they haven't commented in...
17:35:36 <Kevin_Kofler> That's true.
17:35:40 <nirik> in two weeks.
17:35:57 <Kevin_Kofler> KDE SIG is chronically overworked with bugs, and it's worse for stuff like the kernel.
17:36:11 <nirik> yeah.
17:36:28 <abadger1999> "A bug"?  Doesn't that lend itself to abuse?
17:36:55 <nirik> abadger1999: yeah, thats what I am worried about...
17:37:37 <Kevin_Kofler> I'd be quite likely to answer "hey, I'm not unresponsive" within 12 hours of the direct mail, or within 2-3 days if I'm on vacation, but not everyone is as glued to his e-mail as me. ;-)
17:39:07 <nirik> yeah.
17:39:20 <nirik> can we vote on just adding the amended fast track procedure now, and discuss the revamp of the main procedure on list more?
17:39:39 <notting> sure
17:39:47 * notting is +1 to the amended fast track procedure
17:39:51 <Kevin_Kofler> What amended fast track procedure are we voting for now?
17:40:06 <nirik> so, how about we vote on adding the fast track, but with 2) changed to "go to fesco" and then we propose the simplification notting said to the mailing list and vote on it next week with feedback?
17:40:09 <Kevin_Kofler> notting's?
17:40:45 <nirik> "1) Write a mail to fedora-devel with the problems of the package and a summary of communication attempts and open a ticket in FESCo to track all this. 2) The ticket is discussed/voted on in the next FESCo meeting."
17:41:09 <nirik> this is an added 'fast track' procedure added to the existing one.
17:41:34 <j-rod> +1, works for me
17:41:38 <sharkcz> it's +1 from me
17:41:46 <Kevin_Kofler> Shouldn't there be some criteria on when we'd vote for that ticket?
17:42:08 <Kevin_Kofler> People will try to use the fast track procedure in all cases, even where it's inappropriate.
17:42:09 <nirik> for time you mean? or criteria that we would approve the request?
17:42:41 <nirik> they could... we could get mad at them for wasting our time tho. ;)
17:42:49 <Kevin_Kofler> I mean criteria based on which we'd approve or reject the request.
17:43:20 * skvidal finishes the backscroll
17:43:30 <skvidal> +1 on the ammended procedure
17:44:02 <nirik> Kevin_Kofler: well, the current policy does not have that either... it just says "If at least one FESco member approves the takeover and no one objects within 3 days"
17:45:14 <Kevin_Kofler> +1 to the amended fast track procedure, if people abuse it we'll notice and we'll find a way to make them stop wasting our time ;-)
17:45:20 <skvidal> right
17:45:25 <nirik> so I would say it's our judgement... do we have some other way of contacting the maintainer? Is the package part of a SIG or the like that would have someone step up? Is the package a critical one and one of us should take it over? Is the maintainer known to work upstream instead of with redhat bugzilla bugs and doesn't usually respond, etc.
17:45:42 <nirik> ok, I think that passed. ;)
17:45:55 <nirik> Does someone want to step up to amend the page and announce it ?
17:47:17 * nirik listens to the crickets. ;) ok, I guess I can, or we can get jds2001 to do it. ;)
17:47:42 <nirik> #agreed Add new Fast Track non responsive maintainer procedure to the existing procedure.
17:47:46 <nirik> #topic Open Floor
17:47:52 <nirik> anyone have anything for open floor?
17:49:05 * nirik will close out the meeting in a few here if no one brings anything up.
17:50:48 <skvidal> ok
17:50:54 <skvidal> thanks for running the meeting nirik
17:50:57 <nirik> Thanks for coming everyone.
17:51:00 <nirik> no problem.
17:51:03 <nirik> #endmeeting