16:59:59 #startmeeting FESCo meeting 20090918 16:59:59 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 17:00:04 #chair dgilmore jwb notting nirik sharkcz jds2001 j-rod skvidal Kevin_Kofler 17:00:04 Current chairs: Kevin_Kofler dgilmore j-rod jds2001 jwb nirik notting sharkcz skvidal 17:00:14 who all is around for todays FESCo meeting? 17:00:20 * sharkcz is here 17:00:41 Present. 17:01:09 nirik: Hey, you started a second early! ;-) 17:01:14 * notting is here 17:01:25 * nirik checks his ntp server. ;) 17:02:04 man, ntp not running... 2seconds off. ;( 17:03:14 we don't have quorm yet, do we? 17:04:24 skvidal / dgilmore ? you guys around? 17:05:24 * nirik guesses it will be a pretty short meeting today then. 17:05:31 We could get up to +5 for Till's sponsor application counting jds2001's +1 from Trac. 17:05:53 (assuming we all vote for it, otherwise we won't have a quorum :-) ) 17:06:07 yes, he get +1 from me 17:06:07 sorry, here now 17:06:15 cool. Lets get started then. 17:06:25 #topic sponsor application by Till Maas 17:06:31 .fesco 252 17:06:32 nirik: #252 (sponsor application by Till Maas) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/252 17:06:41 jds2001 was +1 in the ticket. 17:06:45 +1 for till, very worthy, all positive feedback on the list 17:06:46 +1, apparently no objections from anyone. 17:06:48 +1 17:07:00 * notting is +1 to till 17:07:10 +1 from me as well, I think he will do a good job. 17:07:29 #action sponsorship approved for Till Maas 17:07:37 #topic simplify non-responsive maintainer process 17:07:46 .fesco 251 17:07:47 nirik: #251 (simplify non-responsive maintainer process) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/251 17:08:31 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 Right (and jds2001 said something similar on Trac: https://fedorahosted.org/fesco/ticket/251#comment:1 ) 17:09:19 reassigning a package after 3 days seems very quick, and could easily hit people who are vacationing, or just busy. 17:09:51 It also looks like no ping directly to the maintainer is required. 17:10:08 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 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 That sounds a bit radical to me. 17:10:32 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 nirik: I agree with that. 17:11:16 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 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 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 But yes, I was about to come to that problem. 17:11:39 tyll: so this would be a 'fast track' alternate procedure? 17:12:28 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 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 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 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 i think the base procedure could be bettre 17:16:36 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 wouldnt it be possible to "automate" that? 17:16:44 bugs that are 2 months old and have status "new" ;) 17:17:09 if that happens send a notification to a "bugzilla-noresponse" list 17:17:23 i mean bugs should be atleast assigned right? 17:17:36 Status NEW means no triaging, not no maintainer response. 17:17:48 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 there are lots of maintainers who don't necessarily bother with a new/assigned distinction 17:18:00 status NEW doesn't mean squat half the time 17:18:06 hah. what notting said. 17:18:12 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 Kevin_Kofler, that doesent seem to work really though *looking at my overview page... 17:18:57 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 That behavior stops with F12 released IIRC. Then we use only a keyword "triaged" 17:19:11 Well, the way we use ASSIGNED is just broken anyway. 17:19:26 however, that's a bit far afield from a general non-responsive maintainer procedure 17:19:29 We abuse NEW as UNCONFIRMED, ASSIGNED as NEW and the nonstandard ON_DEV state as ASSIGNED. 17:19:35 well but tying response to a status change would make it rather easy to track stuff automatically 17:19:46 The problem is that RH Bugzilla's states are designed for RHEL. 17:19:49 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 The scripts for such status reports are here: http://cvs.fedoraproject.org/viewvc/status-report-scripts/?root=fedora 17:19:59 For Fedora, something closer to upstream Bugzilla would make a lot more sense. 17:20:12 But states are global in Bugzilla. 17:20:16 * nirik thinks we are getting sidetracked. ;) 17:21:59 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 But that also doesn't always make sense. 17:22:55 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 (and that's just one example) 17:23:58 Then the bug could be set to needinfo-reporter 17:24:46 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 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 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 silly buggbot 17:25:47 nirik: that works for m 17:25:50 nirik: that works for m 17:25:51 nirik: that works for me 17:25:57 stupid keyboard. 17:26:25 The next fesco meeting alternative would be good too. 17:26:37 can we make #3 be direct email with fedora-devel-list cc'd? 17:27:16 then there's no doubt they've tried to make direct contact, which addresses jds2001's concerns in the ticket 17:27:23 good idea 17:27:32 notting, hmm that will lead to alot escalations 17:28:04 che: there do not seem to be that many of these procedures 17:28:11 tyll: what do you think of notting's simplifed version? would that meet your needs? 17:30:07 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 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 nirik: yes 17:32:27 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 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 nim-nim: sorry I was late 17:32:40 err nirik 17:32:42 nirik: wfm 17:33:00 nirik: work also for me 17:33:26 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 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 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 for some maintainers I would suspect it would be easy to find a bug they haven't commented in... 17:35:36 That's true. 17:35:40 in two weeks. 17:35:57 KDE SIG is chronically overworked with bugs, and it's worse for stuff like the kernel. 17:36:11 yeah. 17:36:28 "A bug"? Doesn't that lend itself to abuse? 17:36:55 abadger1999: yeah, thats what I am worried about... 17:37:37 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 yeah. 17:39:20 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 sure 17:39:47 * notting is +1 to the amended fast track procedure 17:39:51 What amended fast track procedure are we voting for now? 17:40:06 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 notting's? 17:40:45 "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 this is an added 'fast track' procedure added to the existing one. 17:41:34 +1, works for me 17:41:38 it's +1 from me 17:41:46 Shouldn't there be some criteria on when we'd vote for that ticket? 17:42:08 People will try to use the fast track procedure in all cases, even where it's inappropriate. 17:42:09 for time you mean? or criteria that we would approve the request? 17:42:41 they could... we could get mad at them for wasting our time tho. ;) 17:42:49 I mean criteria based on which we'd approve or reject the request. 17:43:20 * skvidal finishes the backscroll 17:43:30 +1 on the ammended procedure 17:44:02 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 +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 right 17:45:25 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 ok, I think that passed. ;) 17:45:55 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 #agreed Add new Fast Track non responsive maintainer procedure to the existing procedure. 17:47:46 #topic Open Floor 17:47:52 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 ok 17:50:54 thanks for running the meeting nirik 17:50:57 Thanks for coming everyone. 17:51:00 no problem. 17:51:03 #endmeeting