18:01:21 <mitr> #startmeeting FESCO (2013-06-05)
18:01:21 <zodbot> 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 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:01:23 <mitr> #meetingname fesco
18:01:24 <zodbot> The meeting name has been set to 'fesco'
18:01:25 <mitr> #chair abadger1999 jwb mitr mmaslano notting nirik pjones t8m sgallagh
18:01:25 <zodbot> Current chairs: abadger1999 jwb mitr mmaslano nirik notting pjones sgallagh t8m
18:01:28 <mitr> #topic init process
18:01:29 <mitr> /me notes apologies from mmaslano, jwb
18:01:31 <mitr> Hello all
18:01:35 <nirik> morning
18:01:39 <pjones> hello, party people.
18:01:57 <notting> .... 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 <t8m> hello
18:03:58 <mitr> #topic #1119 Proven packager
18:04:01 <mitr> .fesco 1119
18:04:02 <mitr> #info The reporter has withdrawn the request, no action needed.
18:04:12 <mitr> #topic #1120 Request owner change for bacula
18:04:14 <mitr> .fesco 1120
18:04:47 <nirik> I'm fine doing this in this case... it's largely cosmetic, IMHO
18:04:57 <pjones> seems pretty legit
18:05:05 <sgallagh> So this request has turned into a discussion on modifying the non-responsive maintainer process
18:05:15 <pjones> the... circumvention of the policy is pretty disappointing :/
18:05:29 <t8m> sgallagh, I'd say it would be an addition to the non-responsive maintainer process
18:05:38 <nirik> well, this is a different case, no?
18:05:44 <pjones> I don't know that we need to actually change the policy
18:06:01 <pjones> 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 <sgallagh> pjones: They actually aren't codified as being possible
18:06:29 <pjones> sgallagh: hrm?
18:06:29 <sgallagh> nirik: I have a proposal in the ticket :)
18:06:41 <mitr> 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 <t8m> 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 <sgallagh> pjones: The non-responsive maintainer process has a hole in it that this owner was abusing.
18:07:07 <sgallagh> And there is no official path to addressing this; coming to FESCo was wise, but not clearly recommended by the policy
18:07:09 <mitr> sgallagh: OTOH the package seems pretty well maintained, so technically there wasn't much harm
18:07:10 <pjones> 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 <sgallagh> sure
18:07:46 <mitr> Can we simplify by voting on Proposal: ownership change requested in #1120 is approved , and then discuss the policy?
18:07:50 <pjones> 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 <t8m> mitr, +1
18:07:58 <pjones> mitr: sure, +1
18:07:59 <sgallagh> mitr: +1
18:08:01 <nirik> 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 <nirik> mitr: +1
18:08:21 <sgallagh> nirik: Pretty much, yes
18:08:38 <sgallagh> I mean <words, words, words>, but that's the boiled-down version
18:08:48 <pjones> nirik: but that's already implicit in pretty much *all* fedora policy.
18:08:53 <nirik> pjones: right.
18:09:02 <mitr> #agreed ownership change requested in #1120 is approved (+5)
18:09:18 <notting> belated +1
18:09:32 <pjones> so,
18:09:33 <abadger1999> +1
18:09:36 <mitr> #undo
18:09:36 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x21218210>
18:09:44 <mitr> #agreed ownership change requested in #1120 is approved (+7)
18:09:44 * abadger1999 was reading the additional discussion
18:10:07 <pjones> 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 <mitr> The bar for making the change should, probably, be a bit lower for long-term-unmaintained packages
18:10:29 <pjones> (we can always revisit it if they do become a serious problem, but...)
18:10:31 <mitr> As it is, it takes 7 steps and 4 weeks.
18:10:34 <zodbot> mitr: #1119 (Proven packager) – FESCo - https://fedorahosted.org/fesco/ticket/1119
18:10:36 <sgallagh> mitr: I attempted to address that in my proposal in the ticket. Feel free to recommend adustments.
18:10:43 <zodbot> mitr: #1120 (Request owner change for bacula) – FESCo - https://fedorahosted.org/fesco/ticket/1120
18:10:50 <nirik> note that in this case there was no non maintained package.
18:11:09 <pjones> 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 <pjones> mitr: and in almost all copies simply be orphaned
18:11:20 <pjones> er
18:11:22 <pjones> s/copies/cases/
18:11:24 <abadger1999> When the comaintainer has all the acls (approveacls and commit), then I'm for pjones's proposal.
18:11:27 <mitr> nirik, pjones: hm, right
18:11:50 * nirik is too.
18:12:19 <mitr> I'm actually most worried about "responsive" maintainers that ignore Fedora's bugzilla and just build upstream releases
18:12:26 <pjones> and if there are other problems like this, I'd honestly prefer we funnel them that way
18:12:27 <mitr> Perhaps that's something best not dragged into this discussion?
18:12:39 <pjones> since absent maintainer has a tendency to be mildly hostile, rather than a process of expiration
18:12:40 <t8m> pjones, how would we do the encouragement? mailing to Fedora devel explicitly or just into this FESCo meeting summary?
18:13:05 <nirik> 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 <pjones> t8m: I was just going to take it as given based on the fesco meeting summary
18:13:09 <pjones> t8m: a #info or so
18:13:23 <t8m> ok
18:13:30 <mitr> 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 <pjones> indeed.
18:13:40 <mitr> Except that it's really not obvious to find
18:13:42 <sgallagh> nirik: I can actually see that as being a benefit to FESCo
18:14:12 <sgallagh> 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 <nirik> 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 <sgallagh> Thus giving us some *actual* control over direction.
18:14:52 <nirik> sgallagh: sure, but it might result in a lot of those coming to us.
18:15:04 <nirik> and when is someone 'unresponsive'?
18:15:04 <notting> so maybe just rephrase the fast track paragraph?
18:15:04 <pjones> nirik: then they most likely should have filed the bug upstream anyway, but if it's important poke me on irc ;)
18:15:06 <sgallagh> 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 <mitr> 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 <pjones> notting: I wouldn't be against that
18:15:19 <t8m> nirik, if we are overwhelmed by such requests we can make the policy more stringent
18:15:32 <pjones> nirik: the policy already (avoids) defining that well, and with good reason
18:15:50 <sgallagh> mitr: Except that "claiming it explicitly" amounts to screaming at a thunderstorm
18:15:52 <nirik> t8m: true
18:16:06 <mitr> notting: yes, I think the policy needs rewording a bit to clarify without changing the substance.
18:16:31 <pjones> 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 <pjones> 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 <mitr> pjones: +1
18:17:12 <notting> "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 <pjones> (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 <nirik> do folks think we should drop the formal process and just have the 'fast track' one?
18:17:53 <notting> and maybe just rename it from 'Fast Track procedure' to 'Exception procedure'.
18:18:16 <t8m> 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 <mitr> nirik: I think the 3-4-week procedure is important to set expectations of what is reasonable/timely reply.
18:18:28 <pjones> 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 <pjones> also what mitr said
18:19:03 <nirik> 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 <mitr> notting: perhaps also add "See the Exception procedure for alternative options that may apply "after the current 7-item list?
18:19:10 <abadger1999> 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 <pjones> abadger1999: but again, first time we've had that happen.
18:19:51 <mitr> pjones: as the policy is written we don't necessarily hear about the other cases
18:19:52 <t8m> pjones, that anyone created a ticket to FESCo
18:20:00 <abadger1999> pjones: only if you define first time as first time ticketed.
18:20:00 <pjones> mitr: sure
18:20:05 <abadger1999> <nod>
18:20:27 <pjones> but the question is: if there are other cases, why haven't they come this far?
18:20:29 <abadger1999> I think notting's proposal would address that htough...
18:20:53 <mitr> 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 <pjones> I think notting was just spitballing there and didn't have a firm proposal.
18:21:01 <pjones> mitr: exactly
18:21:18 <abadger1999> 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 <notting> pjones: well, if people like it, we can go with that
18:22:34 <t8m> notting, can you please post your proposal again?
18:22:49 <t8m> I don't think we need to defer it to next week
18:22:58 <pjones> notting: sure.  with the ellipses removed and language inserted, whynot? ;)
18:23:15 * nirik has no problem with that
18:24:02 <notting> 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 <notting> used."
18:24:29 <pjones> good enough for me: +1
18:24:32 <sgallagh> +1
18:24:35 <abadger1999> +1
18:24:52 <nirik> sure, +1
18:24:57 <sgallagh> (Also, can we make sure this Exception Process is linked from the main non-responsive process page?)
18:24:59 <t8m> +1
18:25:07 <notting> sgallagh: it's on it at the bottom
18:25:11 <sgallagh> Ah, sorry.
18:25:20 <mitr> +1
18:25:45 <mitr> notting: care to edit the wiki as well?
18:25:51 <mmaslano> +1
18:25:53 <notting> i can
18:26:44 <mitr> #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 <mitr> ce. In such cases, this exception procedure  can be used."
18:26:51 <mitr> Anything else on this topic?
18:27:07 <pjones> I think t8m's point earlier was a good one, and as such:
18:27:38 <pjones> #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 <nirik> +1
18:28:54 <abadger1999> +1 if it needs a vote :-)
18:28:55 <pjones> not sure that needed a vote, but thanks ;)
18:29:04 <mitr> Moving on...
18:29:10 <mitr> #topic Open Floor
18:29:20 <mitr> #undo
18:29:20 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x498d0590>
18:29:21 <mitr> sorry
18:29:23 <mitr> #topic Next week's chair
18:30:24 <nirik> I guess I can if no one else will...
18:30:32 <mitr> thanks
18:30:39 <mitr> #info nirik will chair next week's meeting
18:30:44 <mitr> #topic Open Floor
18:30:56 <mitr> Are there any topics for open floor?
18:31:38 <nirik> There's a number of election town halls next week. ;) Everyone should try and attend and ask questions of candidates.
18:31:54 <notting> i thought there was only one for fesco?
18:32:22 * nirik thought the famsco one was announced, looking.
18:32:23 <mitr> https://fedoraproject.org/wiki/Elections#Townhall_Schedule lists one for each election
18:32:45 <nirik> https://fedoraproject.org/wiki/Elections#FAmSCo_.28Ambassadors.29
18:32:46 <nirik> yeah
18:32:51 <mitr> #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 <nirik> also, flock talk voting is underway.
18:34:09 <nirik> https://admin.fedoraproject.org/voting/about/flock-2013
18:35:04 <mitr> #info Flock talk voting is underway: https://admin.fedoraproject.org/voting/about/flock-2013
18:36:08 <mitr> Anything else?  If not, I'll close the meeting in 2 minutes
18:38:30 <mitr> Thanks everyone!
18:38:32 <mitr> #endmeeting