18:01:21 #startmeeting FESCO (2013-06-05) 18:01:21 Meeting started Wed Jun 5 18:01:21 2013 UTC. The chair is mitr. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:01:21 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:01:23 #meetingname fesco 18:01:24 The meeting name has been set to 'fesco' 18:01:25 #chair abadger1999 jwb mitr mmaslano notting nirik pjones t8m sgallagh 18:01:25 Current chairs: abadger1999 jwb mitr mmaslano nirik notting pjones sgallagh t8m 18:01:28 #topic init process 18:01:29 /me notes apologies from mmaslano, jwb 18:01:31 Hello all 18:01:35 morning 18:01:39 hello, party people. 18:01:57 .... comrades? no, not that party. 18:02:00 * sgallagh is here but attending a meatspace meeting at the same time 18:02:18 * notting is three chairs down from sgallagh 18:03:04 * abadger1999 is here 18:03:41 hello 18:03:58 #topic #1119 Proven packager 18:04:01 .fesco 1119 18:04:02 #info The reporter has withdrawn the request, no action needed. 18:04:12 #topic #1120 Request owner change for bacula 18:04:14 .fesco 1120 18:04:47 I'm fine doing this in this case... it's largely cosmetic, IMHO 18:04:57 seems pretty legit 18:05:05 So this request has turned into a discussion on modifying the non-responsive maintainer process 18:05:15 the... circumvention of the policy is pretty disappointing :/ 18:05:29 sgallagh, I'd say it would be an addition to the non-responsive maintainer process 18:05:38 well, this is a different case, no? 18:05:44 I don't know that we need to actually change the policy 18:06:01 in cases where it becomes an issue, appeals to fesco are already possible and welcome. 18:06:13 * nirik thinks we should revamp the non responsive maintainer process, but thats something for someone to propose changes to. 18:06:15 pjones: They actually aren't codified as being possible 18:06:29 sgallagh: hrm? 18:06:29 nirik: I have a proposal in the ticket :) 18:06:41 nirik's point that package ownership is mostly cosmetic still stands - OTOH that kind of recognition is one of the few ways we can actually use, so let's not throw it away 18:06:43 pjones, formally we don't have to, but it might be nice to have a "guideline" that reassignment is possible under certain circumstances 18:06:45 pjones: The non-responsive maintainer process has a hole in it that this owner was abusing. 18:07:07 And there is no official path to addressing this; coming to FESCo was wise, but not clearly recommended by the policy 18:07:09 sgallagh: OTOH the package seems pretty well maintained, so technically there wasn't much harm 18:07:10 sgallagh: sure, but in this case it's being handled as it should - they're asking for us to recognize that that's what's going on, and (it seems like) we are. 18:07:32 sure 18:07:46 Can we simplify by voting on Proposal: ownership change requested in #1120 is approved , and then discuss the policy? 18:07:50 sgallagh: I'd rather keep the policy simple and handle real exceptions manually, as they're few and far between, than address a minor issue by making the policy complex. 18:07:55 mitr, +1 18:07:58 mitr: sure, +1 18:07:59 mitr: +1 18:08:01 sgallagh: so I guess your proposed policy amounts to... if you think a package owner isn't doing their job, ask fesco to reassign? 18:08:14 mitr: +1 18:08:21 nirik: Pretty much, yes 18:08:38 I mean , but that's the boiled-down version 18:08:48 nirik: but that's already implicit in pretty much *all* fedora policy. 18:08:53 pjones: right. 18:09:02 #agreed ownership change requested in #1120 is approved (+5) 18:09:18 belated +1 18:09:32 so, 18:09:33 +1 18:09:36 #undo 18:09:36 Removing item from minutes: 18:09:44 #agreed ownership change requested in #1120 is approved (+7) 18:09:44 * abadger1999 was reading the additional discussion 18:10:07 Proposal: since exceptions to the process for this reason haven't been a serious problem, leave the policy as is, and encourage people to bring exceptions to fesco as they would for any fesco policy. 18:10:08 The bar for making the change should, probably, be a bit lower for long-term-unmaintained packages 18:10:29 (we can always revisit it if they do become a serious problem, but...) 18:10:31 As it is, it takes 7 steps and 4 weeks. 18:10:34 mitr: #1119 (Proven packager) – FESCo - https://fedorahosted.org/fesco/ticket/1119 18:10:36 mitr: I attempted to address that in my proposal in the ticket. Feel free to recommend adustments. 18:10:43 mitr: #1120 (Request owner change for bacula) – FESCo - https://fedorahosted.org/fesco/ticket/1120 18:10:50 note that in this case there was no non maintained package. 18:11:09 mitr: it seems like if the maintainer is actually /absent/ and needs to be reassigned, it'll get into FTBFS and whatnot 18:11:17 mitr: and in almost all copies simply be orphaned 18:11:20 er 18:11:22 s/copies/cases/ 18:11:24 When the comaintainer has all the acls (approveacls and commit), then I'm for pjones's proposal. 18:11:27 nirik, pjones: hm, right 18:11:50 * nirik is too. 18:12:19 I'm actually most worried about "responsive" maintainers that ignore Fedora's bugzilla and just build upstream releases 18:12:26 and if there are other problems like this, I'd honestly prefer we funnel them that way 18:12:27 Perhaps that's something best not dragged into this discussion? 18:12:39 since absent maintainer has a tendency to be mildly hostile, rather than a process of expiration 18:12:40 pjones, how would we do the encouragement? mailing to Fedora devel explicitly or just into this FESCo meeting summary? 18:13:05 well, it's not an easy problem. The current process is cumbersome, but if it's too easy people will try and use it to make changes they disagree with maintainers on... 18:13:07 t8m: I was just going to take it as given based on the fesco meeting summary 18:13:09 t8m: a #info or so 18:13:23 ok 18:13:30 The policy actually already provides for a fast track when "the maintainer has been non-responsive for a long time, but the above procedure has never been completed" 18:13:40 indeed. 18:13:40 Except that it's really not obvious to find 18:13:42 nirik: I can actually see that as being a benefit to FESCo 18:14:12 If the policy always requires it to come to FESCo, then we can make decisions based on which maintainer's view fits best with Fedora's goals (whatever they are at the time) 18:14:23 sgallagh: well, if it's "I filed a grub2 bug last week and the maintainer didn't answer, so give me commits to push my change, oh, and while I am there, I will change this other thing... " 18:14:30 Thus giving us some *actual* control over direction. 18:14:52 sgallagh: sure, but it might result in a lot of those coming to us. 18:15:04 and when is someone 'unresponsive'? 18:15:04 so maybe just rephrase the fast track paragraph? 18:15:04 nirik: then they most likely should have filed the bug upstream anyway, but if it's important poke me on irc ;) 18:15:06 nirik: Well, that's not the same thing, and as long as we don't revoke the primary maintainer's permissions, it may well sort itself out 18:15:15 sgallagh: I don't really like that approach. To misquote a bit, If we want control over direction, let's claim it explicitly, instead of hoping for conflicts so that we can have a say. 18:15:18 notting: I wouldn't be against that 18:15:19 nirik, if we are overwhelmed by such requests we can make the policy more stringent 18:15:32 nirik: the policy already (avoids) defining that well, and with good reason 18:15:50 mitr: Except that "claiming it explicitly" amounts to screaming at a thunderstorm 18:15:52 t8m: true 18:16:06 notting: yes, I think the policy needs rewording a bit to clarify without changing the substance. 18:16:31 but I really do think the bottom line is that we get these requests fairly infrequently, and this is the first time I recall getting one for this particular circumstance. So changing the policy to fit this situation isn't necessarily warranted. 18:17:00 so if somebody wants to re-work that clause and make it fit better, maybe they could do that and come back with a proposal and a new ticket? ;) 18:17:09 pjones: +1 18:17:12 "There are some cases where it may be needed to reassign a package even if this procedure has not yet finished. Examples include when many dependencies are broken, version updates are needed for security or stability reasons, or maintainer response prevents the nonresponsive process from proceeding without actually increasing maintenance. In such cases, ..." 18:17:23 (and as the person who wrote the original policy that's largely still intact, if you want to run your language by me, I'd be happy to help review it.) 18:17:49 do folks think we should drop the formal process and just have the 'fast track' one? 18:17:53 and maybe just rename it from 'Fast Track procedure' to 'Exception procedure'. 18:18:16 notting, +1 18:18:28 * abadger1999 notes that he sees this problem fairly regularly even though this is the first fesco ticket. 18:18:28 nirik: I think the 3-4-week procedure is important to set expectations of what is reasonable/timely reply. 18:18:28 nirik: eh. the goal of the formal process is to make it not get that far unless it has to. I think that has utility still. 18:18:51 also what mitr said 18:19:03 I think it may be too heavily weighted toward the maintainer, but I've not had time to think of a better process. ;) 18:19:09 notting: perhaps also add "See the Exception procedure for alternative options that may apply "after the current 7-item list? 18:19:10 where the problem is: maintainer is unresponsive to bug reports unless the awol policy is initiated and then only to the extent to say, I'm still alive. 18:19:31 abadger1999: but again, first time we've had that happen. 18:19:51 pjones: as the policy is written we don't necessarily hear about the other cases 18:19:52 pjones, that anyone created a ticket to FESCo 18:20:00 pjones: only if you define first time as first time ticketed. 18:20:00 mitr: sure 18:20:05 18:20:27 but the question is: if there are other cases, why haven't they come this far? 18:20:29 I think notting's proposal would address that htough... 18:20:53 pjones: OTOH there have been all of 6 {un,non}responsive maintainer threads this year, so the abuses can't be _that_ frequent 18:20:57 I think notting was just spitballing there and didn't have a firm proposal. 18:21:01 mitr: exactly 18:21:18 as in -- the expectation now becomes, okay, the maintainer does enough to abort the non-responsive policy but doesn't actually do more to fix the package... time to start phase two of the policy. 18:22:12 pjones: well, if people like it, we can go with that 18:22:34 notting, can you please post your proposal again? 18:22:49 I don't think we need to defer it to next week 18:22:58 notting: sure. with the ellipses removed and language inserted, whynot? ;) 18:23:15 * nirik has no problem with that 18:24:02 proposal: s/Fast Track/Exception/. replace first paragraph with: "There are some cases where it may be needed to reassign a package even if this procedure has not yet finished. Examples include when many dependencies are broken, version updates are needed for security or stability reasons, or maintainer response prevents the nonresponsive process from proceeding without actually resuming maintenance. In such cases, this exception procedure can be 18:24:03 used." 18:24:29 good enough for me: +1 18:24:32 +1 18:24:35 +1 18:24:52 sure, +1 18:24:57 (Also, can we make sure this Exception Process is linked from the main non-responsive process page?) 18:24:59 +1 18:25:07 sgallagh: it's on it at the bottom 18:25:11 Ah, sorry. 18:25:20 +1 18:25:45 notting: care to edit the wiki as well? 18:25:51 +1 18:25:53 i can 18:26:44 #agreed Nonresponsive maintainer policy update (+8): s/Fast Track/Exception/. replace first paragraph with: "There are some cases where it may be needed to reassign a package even if this procedure has not yet finished. Examples include when many dependencies are broken, version updates are needed for security or stability reasons, or maintainer response prevents the nonresponsive process from proceeding without actually resuming maintenan 18:26:46 ce. In such cases, this exception procedure can be used." 18:26:51 Anything else on this topic? 18:27:07 I think t8m's point earlier was a good one, and as such: 18:27:38 #info if anybody feels that the nonresponsive maintainer process is being avoided without the maintainer actually becoming responsive, they are encouraged to bring it up with FESCo. 18:28:35 +1 18:28:54 +1 if it needs a vote :-) 18:28:55 not sure that needed a vote, but thanks ;) 18:29:04 Moving on... 18:29:10 #topic Open Floor 18:29:20 #undo 18:29:20 Removing item from minutes: 18:29:21 sorry 18:29:23 #topic Next week's chair 18:30:24 I guess I can if no one else will... 18:30:32 thanks 18:30:39 #info nirik will chair next week's meeting 18:30:44 #topic Open Floor 18:30:56 Are there any topics for open floor? 18:31:38 There's a number of election town halls next week. ;) Everyone should try and attend and ask questions of candidates. 18:31:54 i thought there was only one for fesco? 18:32:22 * nirik thought the famsco one was announced, looking. 18:32:23 https://fedoraproject.org/wiki/Elections#Townhall_Schedule lists one for each election 18:32:45 https://fedoraproject.org/wiki/Elections#FAmSCo_.28Ambassadors.29 18:32:46 yeah 18:32:51 #info There's a number of election town halls next week, see https://fedoraproject.org/wiki/Elections#Townhall_Schedule . Everyone should try and attend and ask questions of candidates. 18:33:43 also, flock talk voting is underway. 18:34:09 https://admin.fedoraproject.org/voting/about/flock-2013 18:35:04 #info Flock talk voting is underway: https://admin.fedoraproject.org/voting/about/flock-2013 18:36:08 Anything else? If not, I'll close the meeting in 2 minutes 18:38:30 Thanks everyone! 18:38:32 #endmeeting