19:30:02 <nirik> #startmeeting FESCO (2010-06-29)
19:30:02 <zodbot> Meeting started Tue Jun 29 19:30:02 2010 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:30:02 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:30:02 <nirik> #meetingname fesco
19:30:02 <nirik> #chair mclasen notting nirik SMParrish kylem ajax pjones cwickert mjg59
19:30:02 <nirik> #topic init process
19:30:02 <zodbot> The meeting name has been set to 'fesco'
19:30:02 <zodbot> Current chairs: SMParrish ajax cwickert kylem mclasen mjg59 nirik notting pjones
19:30:19 <pjones> it's that time again.
19:30:47 <nirik> indeed.
19:30:50 * cwickert is here
19:31:00 * SMParrish here
19:31:24 * notting is here
19:31:28 * nirik will wait a minute or two more for folks to wander in from the lobby.
19:32:04 <mjg59> Hi
19:32:06 <gholms|work> Will these meetings consistently be short handed like this?
19:32:09 * skvidal eavesdrops
19:32:32 * zaniyah is lurking.
19:32:46 <notting> gholms|work: ideally not. but when we sorted out meeting times, this was the best. originally there were *zero* times when everyone was free
19:32:49 <mjg59> We're missing mclasen and notting?
19:33:02 <nirik> #info mclasen is unable to attend today and has added his comments to tickets.
19:33:23 <pjones> notting appears to be here.
19:33:31 <nirik> I think ajax is all we are missing?
19:33:39 <pjones> ajax /should/ be here, he's in the office today.
19:33:42 <nirik> oh, and kylem
19:33:46 <mjg59> Oh, sorry, yes
19:33:51 <mjg59> kyle's on vacation
19:34:00 <nirik> in any case we do have quorum, so lets go ahead.
19:34:16 <nirik> #topic #351 Create a policy for updates - status report on implementation
19:34:16 <nirik> .fesco 351
19:34:18 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351
19:34:25 <nirik> Just a quick update here on implementation.
19:34:33 <nirik> lmacken is testing a bodhi update in staging now.
19:34:49 <nirik> So, hopefully that will pass all it's testing soon and we can update in production.
19:34:50 <notting> i do believe QA's got proventesters going now
19:35:03 <lmacken> notting: bodhi will support proventesters momentarily.
19:35:04 * nirik nods.
19:35:38 <nirik> so, we can make live everything except autoqa soon, and hopefully that won't be too far behind. ;)
19:36:11 <nirik> anyone have anything further on this? or shall we move along?
19:36:39 <gholms|work> (Nice job, folks!)
19:36:43 <jlaska> nirik: no glaring warts on the AutoQA front.  Wwoods is starting to tame the many autoqa project roadmaps into something more manageable.  This will provide for a better ETA.
19:36:52 <ajax> i'm here
19:36:59 <nirik> jlaska: excellent. Please keep us posted.
19:37:15 <jlaska> nirik: will do
19:37:36 <nirik> I note that while nothing is sure, autoqa or proventesters would likely have caught the recent f13 evolution broken deps issue
19:37:55 * bioinfornatics here
19:38:04 <nirik> #topic #382 Implementing Stable Release Vision
19:38:04 <nirik> .fesco 382
19:38:05 <zodbot> nirik: #382 (Implementing Stable Release Vision) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/382
19:38:22 <nirik> did anyone have a chance to add ideas to https://fedoraproject.org/wiki/Stable_release_updates_vision_implementation_ideas over the last week?
19:38:31 <nirik> do we want to discuss some of the existing ideas there?
19:38:31 <mjg59> Afraid not :(
19:39:37 <nirik> so, how can we move this forward? The Board would like some kind of implementation timeline/plan...
19:39:38 <notting> not i
19:39:46 <nirik> which means we need to decide what we are going to want to implement. ;)
19:39:55 <notting> probably the best is to assign people to work on it
19:40:17 <nirik> well, I was hoping an ideas container wiki page would help us all add to it...
19:40:59 <notting> but you can't give a timeline unless someone's actively working on those items
19:41:09 <nirik> true.
19:41:10 <pjones> sorry, I spent all of last week hiding in a bunker near seattle.
19:41:39 <nirik> I was hoping: a) we add ideas, b) we discuss which we want and what timeframe, c) we try and get FES to work on some, us on others
19:41:55 <nirik> we could solicit ideas from the list/community.
19:41:55 <cwickert> I think we already enough ideas, the question is how to make them happen
19:42:20 <cwickert> was there a post to devel-ist? I recall none
19:42:34 <mjg59> cwickert: We were supposed to have come up with a better formed document first
19:42:37 <nirik> no, we said last week that we would try and populate things some before asking the community.
19:42:46 <cwickert> ah, ok
19:43:05 <nirik> I can post to the devel list with my flame retardent suit if folks would like.
19:43:42 <mjg59> I think we really ought to discuss this, but we're failing pretty hard right now
19:43:58 <mjg59> Maybe give it one more week? I've finally got most of my urgent workload handled.
19:44:03 <notting> discuss... here? on-list?
19:44:11 <notting> if you mean add more ideas to the page, we can
19:44:12 <mjg59> Wiki, then on-list
19:44:28 <notting> but i think that starting next week we should come up with an implementation plan with assignees, not just a list of ideas
19:44:53 <mjg59> Yeah
19:45:37 <nirik> ok, so 'try harderer' for another week?
19:45:40 <mjg59> Yeah
19:45:46 <cwickert> +1
19:46:14 <nirik> any objections?
19:46:21 <SMParrish> none here
19:46:38 <nirik> #info Will try and add ideas to container this coming week, discuss again next week hopefully to assign and plan.
19:46:49 <nirik> #topic #387 compile list of supported CPUs and reacto to recent loss of support for Geode LX on F13
19:46:49 <nirik> .fesco 387
19:46:50 <zodbot> nirik: #387 (compile list of supported CPUs and react to recent loss of support for Geode LX on F13) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/387
19:47:00 * cjb appears
19:47:02 <nirik> ok, any news on our fav gcc/glic/fun?
19:47:32 <cjb> we delegated to kyle, he came up with a patch*, he tested that the patch works, he went off to chat with upstream binutils about it
19:47:53 <cjb> *: http://bombadil.infradead.org/~kyle/add-processor-i686.diff
19:48:03 <nirik> ah, and he's out this week?
19:48:04 <cjb> (note that this is a very different solution to our previous one.)
19:48:26 <mjg59> Yeah, it seems a reasonable approach
19:48:31 <mjg59> If upstream can be sold on it
19:48:53 <nirik> which package is that in?
19:49:01 <cjb> if it does get accepted, I suppose it solves both F13 and F14?
19:49:10 <cjb> nirik: it's a gas patch, and gas ships inside binutils
19:49:25 <ajax> it should, yes
19:49:25 <nirik> cjb: yeah, ok.
19:49:47 <cjb> ok.  so I'm happy if we just leave it there for this week, and hear back from Kyle when he's back from vacation.
19:50:06 <glandvador> what if not accepted upstream ?
19:50:06 <nirik> ok, +1 to defer and revisit (again) next week.
19:50:18 <nirik> glandvador: we can burn that bridge when we come to it?
19:50:21 <cjb> glandvador: not too much point talking about that until it happens
19:50:56 <nirik> ok, any objections to defer and moving on? going once...
19:51:04 <ajax> nope.
19:51:20 <nirik> #topic Provenpackager / Sponsor policy revisit
19:51:35 <nirik> ok, I have a question on our new provenpackager/sponsor policy.
19:51:46 <nirik> I didn't file a ticket on this, but I could...
19:52:08 <hicham> the complaint ticket is enough
19:52:34 <nirik> currently, people file a ticket, I fwd it to sponsors. If they get 3 +1 votes they are approved, if they get a -1 vote it goes to fesco.
19:52:46 <nirik> What happens if they don't get either?
19:53:01 <notting> closed -> deferred?
19:53:05 <nirik> do they sit in limbo? do I close the ticket asking them to try again later? do I bug sponsors again?
19:53:38 <nirik> ok, and anytime they reopen I mail sponsors again?
19:53:47 <ajax> sounds reasonable
19:53:59 <SMParrish> works for me
19:54:01 <notting> with some caveat of 'don't keep reopening it 5 minutes after it's cloesd'
19:54:22 <nirik> ok, just wanted to clarify that...
19:55:01 <nirik> proposal: If there are insufficent votes in a week, the ticket is closed and the submitter asked to try again later. When they reopen the ticket the process begins again.
19:55:28 <ajax> +1
19:55:36 <SMParrish> +1
19:55:46 <mjg59> +1
19:55:47 <notting> +1
19:55:57 * nirik can update the wiki page(s) and the 2 to 3 tickets that are in this state.
19:56:04 <nirik> +1 from me too.
19:56:12 <nirik> #agreed If there are insufficent votes in a week, the ticket is closed and the submitter asked to try again later. When they reopen the ticket the process begins again.
19:56:36 <nirik> #action nirik will update trac/wiki pages.
19:56:39 <nirik> moving on.
19:56:43 <nirik> #topic #403 Abuse of Privileges / Procedure Overruled
19:56:43 <nirik> .fesco 403
19:56:44 <zodbot> nirik: #403 (Abuse of Privileges / Procedure Overruled) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/403
19:56:50 <nirik> we have 2 things to decide here.
19:56:56 <nirik> a policy for mass acl changes.
19:57:06 <nirik> and what to do about the last change that happened.
19:58:17 <gholms|work> What does abadger1999 refer to when he says "proof-before-sponsorship model?"
19:58:40 <gholms|work> Err, wait.  Ignore that.
19:58:47 * gholms|work read it backwards
19:59:01 <nirik> I like my own option #9.
19:59:07 <cwickert> so first the mass acl change?
19:59:17 <nirik> cwickert: no, there have been others.
19:59:42 <nirik> this one was different because it was 'perl-sig' based, and abadger2001 didn't understand what that was/meant.
20:00:13 <cwickert> sorry nirik, what is #9? comment 9 was from rvokal
20:00:27 <pjones> so, I guess the first question is: what do we think was wrong about how this was done?
20:00:36 <nirik> in comment 15
20:00:45 <nirik> pjones: I do.
20:00:57 <pjones> nirik: I think you might not have read the question very well ;)
20:01:12 <nirik> sorry.
20:01:19 <cwickert> the behavior of rvokal was COMPLETELY wrong
20:01:33 <notting> pjones: the request appeared to be 'add these people to packages the perl sig maintains'
20:01:34 <nirik> I think the problem was that the requestor didn't have acl permissions on all the packages changed.
20:01:45 <notting> pjones: the request as implemented was 'add these people to all perl packages'
20:01:49 <notting> which was not the same thing
20:01:52 <pjones> I mean, there are several different ways to look at it.  Before we address what the ongoing policy is, or what we think we should do to address the damage, actually quantifying the problem seems like a good start.
20:02:23 <cwickert> notting: but even "the perl sig maintains these packages" was wrong
20:03:09 <nirik> if action is being done, the requestor should have permissions to do that. This mass change procedure is just a convienience for large numbers of changes. It shouldn't bypass the permissions system.
20:03:51 <cwickert> +1, every package maintainer should be asked or at least be notified, AFAICS this didn't happen
20:04:11 <rsc> cwickert: no, this did not happen.
20:04:11 <mjg59> Well, it seems that there was an attempt to notify the maintainers
20:04:12 <cwickert> notified = notified in advance
20:04:25 <ajax> well, no.  but for perl-sig, that's not a particularly well-defined set of people.
20:04:31 <mjg59> It just turned out that that didn't work very well
20:04:32 <pjones> "notified" isn't quite right - consulted seems more accurate.
20:04:53 <cwickert> mjg59: the message to the perl list doesn't qualify as a valid try to contact maintainers IMHO
20:05:11 <cwickert> pjones: ether way, I'm not a native speaker ;)
20:05:18 <ajax> cwickert: then what does?
20:05:25 <notting> cwickert: ... it's probably valid as far as 'contacting the perl sig' goes. now, the problem comes when it's applied to packages that aren't in that set
20:05:26 <nirik> my proposal for process is:  a) check and confirm requestor has aproveacls on any packages changed, if no it goes to fesco. b) mail all package-owners about the change being made and who requested it, c) make change.
20:05:36 <cwickert> ajax: mails to foo-owner for example
20:05:56 <pjones> cwickert: ... but if the request was for packages owned by the perl-sig...
20:06:04 <SMParrish> nirik: need to have some time between b & c for objections and feedback
20:06:12 <cwickert> pjones: AFAICS it was not
20:06:20 <pjones> SMParrish: hince I said "consulted"
20:06:26 <nirik> pjones: 'owned by the perl-sig' is a undefined set
20:06:37 <notting> SMParrish: how so? if requestor had approveacls on the package, they could do this *right now* without any delay. the mass change is just done to make it less of a PITA
20:06:37 <cwickert> rsc: was one of your packages affected? and was it owned by you only or the perl-sig?
20:06:41 <nirik> SMParrish: I disagree... since the requestor has approveacls they could just do it anytime.
20:07:27 <rsc> cwickert: Multiple of my packages were affected, I got no e-mail about a planned change and the packages are owned by me (and maybe perl-sig additionally)
20:07:46 <nirik> perl-sig shouldn't own anything... it's just used for cc's on bugs.
20:07:52 <SMParrish> I'm refering to instances where the requestor does not have approveacls
20:07:53 <notting> perl-sig doesn't *own* anything, afaik. it gets tossed in watchbugzilla, etc.
20:07:55 <cwickert> +1 to nirik
20:08:01 <rsc> nirik: well, perl-sig is listed in FAS for my packages or so.
20:08:08 <rsc> nirik: s/FAS/pkgdb/ of course
20:08:12 <notting> SMParrish: per nirirk's proposal, it's already kicked to fesco at that point
20:08:22 <nirik> SMParrish: well, it would go to fesco... and IMHO need a very good reason.
20:08:31 <notting> honestly, i'd prefer it not have to always come to fesco, but that's the escalation point we have
20:09:10 <nirik> perl-sig has no approveacls owner or commit privs...
20:09:11 <notting> but i think nirik's first change is absolutely required (for mass acl changes, requestor must have approveacls on the packages in question)
20:09:11 <cwickert> sorry, but one thing I don't understand: why does rvokal have approve acls to all these packages? he is not the owner
20:09:14 <nirik> https://admin.fedoraproject.org/pkgdb/users/packages/perl-sig?acls=owner&acls=approveacls&acls=commit
20:09:40 <nirik> cwickert: rvokal?
20:09:56 <notting> cwickert: huh? he didn't. he wasn't the one that requested the change, nor was he the one that enacted the change
20:10:37 <cwickert> so who requested the change then?
20:10:52 <notting> ppisar requested the change
20:10:53 <nirik> ppisar requested it.
20:11:09 <nirik> mmaslano and iarnell said it was fine.
20:11:11 <cwickert> and he doesn't have approve acls to anything
20:11:20 <nirik> (they own a bunch of packages, but not all changed ones)
20:11:30 <notting> although that was at the request of marcela, who i'm fairly sure does have approveacls access. lemme check
20:11:52 <nirik> not on all the packages changed.
20:11:59 <nirik> it was all perl-sig cc'ed packages.
20:12:09 <notting> right, that's the issue. she does have approveacls on a subset
20:12:18 * nirik notes they own 168/145 packages between them.
20:12:21 <notting> inc. perl itself.
20:12:50 * nirik nods.
20:12:55 <pjones> so it sounds like what actually happened was that somebody did the mass ACL change thinking mmaslano and iarnell had approved it, not realizing that they didn't have standing to approve most of it.
20:13:03 <cwickert> mmaslano backed up the request, but AFAIK she became owner of some of the packages in without asking the maintainers ether
20:13:06 <notting> basically, this shows the need for having group-based ACLs. but that's an issue for the future and toshio's copious spare time
20:13:09 <nirik> pjones: thats my understanding, yes
20:13:20 <notting> cwickert: ... how would that happen?
20:13:27 <pjones> notting: yeah.
20:13:35 <notting> cwickert: are you implying she had toshio forcibly reassign them?
20:13:47 <notting> (or some other pkgdb admin)
20:14:03 <cwickert> notting: ask rsc, he got a formal email from red hat that his packages will become part of RHEL 6 and therefor need to be maintained by a RH employee
20:14:11 <nirik> there were requests in the past like:
20:14:17 <cwickert> s/his packages/some of his packages
20:14:29 <nirik> Hi, I am maintainer $foo, I would like you to make $bar co-maintainer on all my packages.
20:15:07 <nirik> cwickert: weird.
20:15:08 <rsc> nirik: haha. No Red Hat employee sent me such an e-mail without making noise before from my side.
20:15:27 <rsc> nirik: no one, except one. Sorry.
20:15:32 <nirik> rsc: no, I was saying toshio has gotten requests like that before...
20:15:57 <nirik> ok, we are past 15min now.
20:16:01 <nirik> votes to continue?
20:16:04 <cwickert> continue please
20:16:08 <nirik> +1, I would like to see us resolve this.
20:16:09 <pjones> we probably ought to continue, yeah.
20:16:15 <notting> sure, why not
20:16:23 <notting> shall we vote on individual segments?
20:16:48 * nirik still likes his proposal, but sure... how can we break it up?
20:16:57 <notting> proposal: no mass acl change will be made unless the requester has approveacls on the packages requested. if not, escalate to fesco.
20:17:16 <nirik> +1 here, that only makes sense to me.
20:17:23 <ajax> +!
20:17:27 <pjones> I'm +1 on that.
20:17:28 <notting> +1
20:17:34 <mjg59> +1
20:17:34 <pjones> in that it seems completely obvious.
20:17:41 <notting> (this is nirik's proposal, i'm just stating it)
20:17:46 <cwickert> +1
20:18:02 <nirik> #agreed no mass acl change will be made unless the requester has approveacls on the packages requested. if not, escalate to fesco.
20:18:22 <notting> atlhough i'd encourage in this case for people to talk about it amongst the maintainers before escalating
20:18:56 <nirik> always.
20:19:16 <cwickert> how about: making direct contact mandatory if requestor doesn't have approveacls?
20:19:38 <cwickert> and direct contact is something like foo-owner but not a mailing list
20:19:48 <gholms|work> Is that scalable?
20:19:51 <notting> well, i like mailing lists b/c there's a record
20:20:19 <nirik> cwickert: if we approved something like this, I would say yes, we should inform maintainers somehow.
20:20:25 <notting> but the people may not be on a particular list
20:20:30 * nirik isn't sure there is a case where he would approve such a request off hand.
20:20:39 <cwickert> notting: you can still write to the mailing list, but we need to make sure that the maintainers are actually consulted
20:21:16 <notting> hm
20:21:36 <nirik> can anyone think of cases where we would approve a mass change where the requestor didn't have approveacls?
20:22:00 <pjones> not really one we need to care about
20:22:05 <notting> nirik: "if the owners of the packages where the requestor didn't have approveacls agreed to it"
20:22:19 <pjones> I mean, an emergency could happen, but in that case it seems like provenpackagers should handle it.
20:22:23 * nirik wonders if we can mass 'request'
20:22:44 <pjones> and in other cases simply escalating to fesco should handle things.
20:22:51 <nirik> ie, just mass request for the person commit/co-maintainer... it would still be up to the maintainer to approve it.
20:23:32 <cwickert> gholms|work: I have to admit that it doesn't really scale, but a mass acl change needs to be scripted somehow anyway, so why not for the mails too?
20:23:43 <nirik> how about we decide how to handle a request like that when/if we ever approve one?
20:24:51 <nirik> because I think how we handle it might depend on whatever extraordinary reason we wanted to approve that for...
20:25:52 <nirik> I'd like us to also consider making a email to affected package owners part of this process before/as the change is made.
20:26:13 * nirik taps the mic. Is this thing on? :)
20:26:33 <ajax> yep.
20:26:38 <ajax> i think that sounds reasonable
20:26:55 <tremble> nirik: If you're going to do that could it be a single email, rather than 1 per package?
20:27:14 <nirik> I think thats important, because otherwise it's unclear where this change came from and why.
20:27:29 <nirik> tremble: either way, whatever can be implemented...
20:27:55 <cwickert> I suggest *before* rather than *as* the change is made
20:27:56 <nirik> packagewhatever-owner@ is easy, but one email per package. toshio might be able to generate a list easier tho and just mail one.
20:28:15 <nirik> cwickert: sure, reasonable.
20:28:23 <tremble> Getting the list would be trivial, I've been poking that code recently
20:28:38 <nirik> ok, then one email would be just dandy.
20:28:46 <nirik> with me anyhow.
20:28:53 <nirik> so, +1 to that. Votes?
20:29:06 <ajax> +1
20:29:15 <cwickert> +1
20:29:38 <mjg59> +1
20:29:44 <pjones> +1
20:30:20 <notting> +1
20:30:41 <nirik> #agreed mass change admin will mail all affected package owners before the mass change is made explaining who requested it and what and why.
20:31:17 <nirik> ok, next subtopic: what do we do with the changes from this last mass change?
20:31:38 * mclasen apologizes for being late
20:32:19 <notting> i would assume revert them from the packages where mmaslano didn't have approveacls
20:32:32 <spot> fwiw, that is my suggestion as well
20:32:38 <cwickert> revert and if they want it, they should follow the procedure that we just agreed on
20:32:51 <cwickert> ok, then we hate at least +3 for revert
20:32:52 <pjones> yeah, I think that's probably the right thing to do
20:32:53 <mjg59> Yeah
20:33:06 <pjones> and possibly contact maintainers for everything else and ask them to ack/nack
20:33:11 <ajax> up, enter
20:33:25 <nirik> well, and iarnell, who also approved of the change I think.
20:33:29 <pjones> since the problem really seems to be that the change went forward too quickly.
20:34:04 <nirik> any objections?
20:34:28 <nirik> proposal: revert permissions on packages where approving maintainers didn't have approveacls
20:34:35 <nirik> (does that sound like what everyone wants?)
20:34:48 <notting> +1
20:35:00 <pjones> +1
20:35:10 <cwickert> +1
20:35:12 <pjones> with a note that re-requesting on the rest is fine.
20:35:30 <mjg59> Yes
20:35:33 <nirik> +1 here.
20:35:51 <nirik> pjones: re-requesting? you mean using the normal pkgdb interface that requres maintainer approval?
20:36:20 <pjones> nirik: that would be appropriate.
20:36:24 <ajax> +1
20:36:33 <SMParrish> Sorry bout that  bad storm here, power is off and on
20:37:03 <nirik> SMParrish: no worries. Current proposal is about reverting the last mass change (or part of it):
20:37:07 <nirik> proposal: revert permissions on packages where approving maintainers didn't have approveacls
20:37:24 <SMParrish> I'm +1 for that
20:37:28 <nirik> #agreed revert permissions on packages where approving maintainers didn't have approveacls
20:37:43 <nirik> ok, anything further on this? or shall we move on? I think we answered the pending questions...
20:38:12 <nirik> ok, moving on
20:38:15 <nirik> #topic #405 Request to find resolution for the binutils static library saga
20:38:15 <nirik> .fesco 405
20:38:17 <zodbot> nirik: #405 (Request to find resolution for the binutils static library saga) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/405
20:38:21 <nirik> more fun with binutils! :)
20:38:46 <cwickert> erm, sorry, one more thing on the privilege abuse
20:38:47 <mjg59> Ngh. Yeah.
20:39:01 <nirik> #undo
20:39:01 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x2aaaab5871d0>
20:39:04 <nirik> cwickert: ?
20:39:06 <cwickert> I'd like to request that rvokal steps down as a sponsor
20:39:19 <nirik> cwickert: what part did rvokal play in this?
20:39:35 <pjones> I think maybe we should give him guidance and some more opportunities to contribute instead.
20:39:45 <cwickert> he wanted to sponsor people that haven't proven themselves to the community in any way
20:39:57 <pjones> I mean, I realize you're upset because two people he sponsored are involved in a fiasco, but that doesn't actually mean he's a bad sponsor.
20:40:11 <pjones> people do make errors (and in this case it's not entirely clear he did so)
20:40:21 <cwickert> but obviuosly he doesn't understand the sponsoring guidelines really
20:40:33 <pjones> then we should try to teach him
20:40:44 <mjg59> cwickert: If you believe someone will do a good job and you have a mechanism to rapidly handle cases where they don't, I don't think it matters if they have prior community involvement
20:40:45 <nirik> there is no requirement that people must prove themselves to the community before being sponsored...
20:40:55 <nirik> at least that I know of.
20:41:11 <cwickert> they need to submit a package or do reviews
20:41:25 <cwickert> the soft path for co-maintainership was never ratified AFAIK
20:42:02 <pjones> hmm.
20:42:07 <nirik> thats the usual path, but there is nothing saying thats required.
20:42:14 <cwickert> they must prove themselves somehow and saying "they have proven to us, otherwise we wouldn't have hired them" is unacceptable IMHP
20:42:16 <cwickert> IMHO
20:42:27 <mjg59> cwickert: The documentation does not require that
20:42:57 <rsc> mjg59: seriously? Then we IMHO need to correct our docs.
20:42:58 <nirik> cwickert: "The best ways for you to illustrate your understanding of the packaging guidelines are to submit quality packages and to assist with package reviews"
20:43:03 <nirik> but thats not required.
20:43:15 <cwickert> the documentation only talks about maintainers that submit a new package, that is correct. but the other path is not documented and we never ratified
20:43:27 <cwickert> so submitting a package is the only way I think
20:43:27 <nirik> if you can convince a sponsor that you understand the guidelines and would be a good maintainer why shouldn't they sponsor you?
20:44:01 <mjg59> cwickert: If our documentation doesn't match our requirements, then that's a problem with our documentation and not people who follow our documentation
20:44:46 <nirik> cwickert / rsc: I guess if you want that changed, write up a proposal and we can discuss it when we know exactly what it looks like?
20:44:49 <cwickert> mjg59: its not only the documentation but also FESCO votes. if we didn't vote for a policy, then that policy is not in place
20:46:01 <mjg59> cwickert: And I'm saying that it's entirely unreasonable to attempt to punish someone for failing to follow requirements that haven't been written down
20:46:20 <nirik> my understanding of our current guidelines is that sponsors sponsor packagers who they feel understand the guidelines and that they would feel would do a good job. The typical way to show a sponsor that is by submitting reviews and packages. If the sponsor knows this some other way they can still sponsor them.
20:46:55 <cwickert> https://fedoraproject.org/wiki/PackageMaintainers/Join only lists one way and that is through a new package submission and also includes doing reviews
20:47:02 <cwickert> non of that happened
20:47:34 <nirik> our wiki pages are a mess.
20:47:57 <mjg59> cwickert: https://fedoraproject.org/wiki/How_to_sponsor_a_new_contributor seems like much more relevant documentation
20:48:19 <mjg59> There's a "should" there
20:48:26 <cwickert> how about https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group#Sponsorship_model then?
20:48:38 <cwickert> "The Fedora package submission process requires that new package  submitters be sponsored before they are granted access to the 'packager'  group."
20:48:58 <cwickert> note the *requires*, but I have to admit that it only applies to new packages
20:49:19 <mjg59> That says that new package submitters must be sponsored, not that sponsors must have submitted packages
20:49:38 <cwickert> ok, but where is documentation for the latter case?
20:49:45 <mjg59> Fuzzy
20:49:49 <notting> and, arguably it's broken if we require someone that wants to help package thunderbird submit some random game before they can do so
20:49:55 <cwickert> is it just "find someone who trusts you"?
20:50:30 <mjg59> Find someone who trusts you and who can deal with any mess you create
20:50:47 <nirik> cwickert: yes.
20:50:54 <cwickert> this will end up in abuse I'm afraid
20:51:03 <cwickert> anyway, I agree we the guidelines are fuzzy and we need to improve them
20:51:28 <cwickert> I think a admonition should be enough for rvokal then
20:51:42 <nirik> it's been this way since the fedora-extras days. It's not been documented at all well, but sponsors have sponsored people who haven't submitted packages at various times over the years.
20:52:00 <nirik> #info our docs on sponsorship need serious work.
20:52:02 * cwickert doesn't recall a single case
20:52:34 <gholms|work> cwickert: The people asking for sponsorship for co-maintenance?
20:52:57 <nirik> ok, so where do we go from here? try and find someone to fix our docs? people wanting changes submit proposals?
20:53:00 <Oxf13> cwickert: do you watch each and every sponsorship interaction that happens every single day?
20:53:34 <nirik> shall we move along?
20:53:41 <mjg59> Sure
20:53:46 <SMParrish> yes
20:53:53 * gholms|work notes the time
20:53:54 <cwickert> Oxf13: no, that's why I'm surprised to hear that it should be common to become members of the packager group without a single review or package
20:53:55 <nirik> #topic #405 Request to find resolution for the binutils static library saga
20:53:55 <nirik> .fesco 405
20:53:56 <zodbot> nirik: #405 (Request to find resolution for the binutils static library saga) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/405
20:54:13 <nirik> cwickert: I wouldn't say common, but it's there.
20:54:36 * cwickert likes to see examples for that because he really thinks this is wrong
20:54:43 <cwickert> anyway, move on
20:55:05 <nirik> on this thing I am +1 to mclasen's suggestions...
20:55:18 <nirik> but how can we get upstream/fedora maintainers to do that? :)
20:56:19 <notting> so, they seem to be mis-following the guidelines now, correct?
20:56:29 <notting> they package static and devel together in -static with a virtual provide
20:56:41 <notting> and they're supposed to do it in -devel with a virtual provide for -static?
20:57:37 <nirik> and the .so's are not .so's
20:57:51 <ajax> that's not unusual, really.
20:57:53 <notting> a few packages have that
20:58:02 <nirik> crazy. ok.
20:58:36 <ajax> linker scripts as installed objects are generally a little sketchy, but not intrinsically wrong
20:58:59 <pjones> ... didn't we once ship libc.so that way?
20:59:12 <notting> once? still.
20:59:13 <ajax> once nothing
20:59:17 <pjones> oh, right.
20:59:47 <notting> so
20:59:59 <notting> proposal: ask binutils maintainer to rename -static to -devel, adjust provides accordingly
21:00:48 <pjones> sounds fine.
21:01:01 <nirik> ok by me from my understanding of the issue.
21:01:05 <SMParrish> +1
21:01:19 <mjg59> +1
21:01:41 <notting> +1
21:01:46 <notting> (if i need to do that)
21:01:47 <mclasen> +1
21:01:59 <ajax> hang about.
21:02:02 <nirik> #agreed ask binutils maintainer to rename -static to -devel, adjust provides accordingly
21:02:06 <nirik> notting: can you ask?
21:02:10 <notting> ajax: yes?
21:02:33 <mclasen> ajax: if you only ship a static library, is there any need to include such a fake .so, though ?
21:02:35 <mjg59> Now, this is only true if binutils-devel provides *no* dynamic libraryes, right?
21:02:35 <ajax> notting: doesn't simply renaming put them right back into violation of the "-devel shouldn't contain .a files" guideline?
21:02:48 <mjg59> ajax: -devel can contain .as if it *only* contains .as
21:03:10 <mjg59> But it's unclear whether a .so that's a linker script counts
21:03:27 <pjones> mjg59: it shouldn't - the linker script may still be usable at static build time
21:03:41 <pjones> (and required, even)
21:03:49 <notting> if they only want static linking, doesn't removing the .so files (as mclasen suggests) accomplish the same thing?
21:04:12 <mclasen> binutils-devel also contains libopcodes.so
21:04:20 <mclasen> but thats just the same, a linker script
21:04:31 <ajax> unless, of course, they want static linking for some things and not others.
21:04:39 <ajax> like, binutils itself could dynamically link
21:04:46 <ajax> but if they don't actually provide any DSOs then...
21:04:52 <mjg59> If they want static linking for some things and not others, then the guidelines suggest that there has to be a split
21:05:21 <mclasen> ajax: binutils actually has the dsos
21:05:33 <pjones> ieeeeee
21:05:34 <mjg59> Anyway, I'm reluctant to impose a solution without feedback from the maintainer
21:05:47 <mjg59> But it should be pointed out that the current situation is in violation of the guidelines
21:06:12 <ajax> mclasen: oi
21:06:42 <mclasen> /usr/lib64/libbfd-2.20.51.0.7-4.fc14.so
21:06:42 <ajax> i hate to ever recommend rpaths for anything, but man if this isn't exactly what rpaths are for
21:06:55 * notting goes off to find the specific guidelines
21:07:00 <mjg59> Ugh. Ok. So right now, binutils-static contains no dynamic objects. The .sos it contains can never be used to link to dynamic objects.
21:07:15 <mjg59> So just renaming the package seems the most straightforward thing to do
21:07:38 <ajax> mjg59: -devel you mean
21:07:46 <nirik> devel -> static ?
21:07:49 <mjg59> ajax: No. There is no -devel package.
21:07:56 <ajax> oh right, i'm querying from an f12 machine
21:08:18 <notting> yes, just renaming seems to put it in accordance with the guidelines
21:08:49 <ajax> yeah, fair enough
21:08:51 <mjg59> So absent anything else, rename the package and be done with it
21:08:54 <notting> although then all the build requires need to be 'changed' to refer to the provide, not the package name. why do we have that requirement?
21:08:56 <nirik> right.
21:09:03 <ajax> i still think they're being needlessly clever
21:09:08 <mjg59> And yeah, it seems kind of unnecessary
21:09:10 <mjg59> But still
21:09:27 <mjg59> So back to notting's proposal?
21:09:29 <nirik> ok, so we already agreed to that, notting will talk to the maintainer?
21:09:35 <notting> um, sure!
21:09:50 <nirik> ok, anything more? will move on in minute if not...
21:09:58 <ajax> not from me
21:10:04 <nirik> #topic #404 Binary Name Conflicts in freeze and mlt
21:10:04 <nirik> .fesco 404
21:10:06 <zodbot> nirik: #404 (Binary Name Conflicts in freeze and mlt) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/404
21:10:24 <mjg59> I honestly have trouble caring about this one
21:10:38 <mjg59> If mlt is never called by users then it seems the simplest to change
21:10:43 <mjg59> It's also outside our archive
21:12:06 * nirik re-reviews the ticket
21:12:11 * mclasen would be fine with letting the conflict remain in place, and maybe just make it explicit
21:12:29 <mclasen> I mean freeze is not in the default install, I hope
21:12:30 <nirik> .whoowns freeze
21:12:30 <zodbot> nirik: robert
21:12:39 <mjg59> I don't think conflicts are the right tool here
21:13:03 <pjones> um.
21:13:14 <pjones> the conflict is implicit; of course it's not the right tool.
21:13:42 <rsc> mclasen: nope, freeze is not in the default installation.
21:13:44 <ajax> i think mclasen was saying to explicitly do Conflicts: mlt
21:13:59 <nirik> rsc: ok, so you think alternatives could work, as they are similar enough?
21:14:06 <pjones> so anyway, I don't honestly think this is something fesco needs to weigh in on.  if the rpmfusion guys want to make a working repo, they really can't conflict with stuff in the repo it's based on.
21:14:14 <rsc> nirik: no, I got told, they're completely two different tools.
21:14:15 <mjg59> nirik: One's part of a media framework. One's a file decompressor
21:14:26 <ajax> yeah, this isn't what alternatives is for
21:14:41 * mclasen notes in passing that binutils does in fact link its own binaries dynamically
21:14:46 <nirik> just clarifiying from the comment about that in the ticket.
21:15:23 <pjones> anyway, I think the thing to do is send the rpmfusion maintainer an email telling him that he might want to consider fixing his package.
21:15:28 <mjg59> Yeah
21:15:43 <ajax> fine with me
21:15:56 <nirik> right, so fedora just stays as it is... rpmfusion has to change names or add conflict?
21:16:20 <nirik> so, does anyone have an exact thing to vote on here?
21:16:21 <notting> yeah. although if the fedora packager wants to remove the melt symlink, i certainly won't stand in his way
21:16:51 <mjg59> Hang on
21:16:59 <mjg59> The rpmfusion maintainer doesn't want the fedora package renamed
21:17:07 <mjg59> The rpmfusion maintainer is happy to rename his binary in rawhide
21:17:12 <mjg59> What are we even talking about?
21:17:23 <pjones> yeah, I think it's time to ignore this as hard as we can.
21:17:31 <ajax> ignore what?
21:17:38 <pjones> what are you talking about?
21:17:38 <mjg59> #propsal closed->noturproblem
21:17:52 <mjg59> Imagine that that contained more of the letter o
21:18:07 <mjg59> Can we move on?
21:18:35 <nirik> ok, so we just close it and let them work it out? any objections?
21:18:57 <pjones> that sounds great.
21:18:58 <pjones> let's move on.
21:19:04 <nirik> #info FESCo feels this is not something we can/should weigh in on. Please work it out between maintainers.
21:19:11 <nirik> feature time.
21:19:14 <nirik> #topic #406 F14Feature: http://fedoraproject.org/wiki/Features/F14Boost144
21:19:14 <nirik> .fesco 406
21:19:16 <zodbot> nirik: #406 (F14Feature: http://fedoraproject.org/wiki/Features/F14Boost144) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/406
21:19:47 <mjg59> +1
21:20:25 <SMParrish> +1
21:20:41 <ajax> +1 boring
21:20:43 <nirik> +1 here, please to be using a seperate tag for builds to avoid breakage.
21:21:07 <notting> +1, what nirik said
21:21:29 <nirik> #agreed Feature is approved.
21:21:36 <nirik> #topic #407 F14Feature: http://fedoraproject.org/wiki/Features/Python_2.7
21:21:36 <nirik> .fesco 407
21:21:37 <zodbot> nirik: #407 (F14Feature: http://fedoraproject.org/wiki/Features/Python_2.7) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/407
21:21:44 * dmalcolm is lurking FWIW
21:21:45 <nirik> +1. Ditto.
21:22:13 <notting> wheee, rebase pain. +1
21:22:17 <notting> although
21:22:23 <notting> if we're also going to get a gcc-4.5 rebuild
21:22:27 <pjones> +1 to continue trusting dmalcolm to do the right thing ;)
21:22:30 <notting> it would be nice to synchronize these somehow
21:22:31 <SMParrish> +1 but cannot break python3 tandem install
21:22:39 <ajax> gcc4.5 rebuild needs to precede python rebuild
21:22:42 <ajax> (i think)
21:22:53 <mjg59> +1
21:23:07 <ajax> but +1
21:23:54 <cwickert> +1
21:24:06 <nirik> #agreed Feature is approved.
21:24:23 <mclasen> dmalcolm: is the 2.7 update somehow related to 3.0, or will those just continue to coexist ?
21:24:24 <nirik> does anyone know if gcc 4.5 is planned?
21:24:38 * mclasen hasn't heard either way
21:24:41 <mclasen> notting ?
21:25:05 <notting> i have heard rumors, but no facts. need to go sit on ebachalo to get an answer, or something.
21:25:27 <nirik> ok, no worries.
21:25:31 <nirik> #topic #408 F14Feature: http://fedoraproject.org/wiki/Features/ipmiutil
21:25:31 <nirik> .fesco 408
21:25:32 <zodbot> nirik: #408 (F14Feature: http://fedoraproject.org/wiki/Features/ipmiutil) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/408
21:25:33 <dmalcolm> mclasen: 2.* and 3.* continue to be independent.  3.2 looks like it isn't going to make it in time for F14; I have an unfinished feature page for it here: https://fedoraproject.org/wiki/Features/Python_3.2 (ignore the Fedora version there, that's just the template)
21:25:54 <nirik> dmalcolm: thanks for the info.
21:27:34 <ajax> libipmiutil.a boooooo
21:28:02 <mjg59> Yeah
21:28:13 <mclasen> so what does ipmi mean ?
21:28:22 <mjg59> ipmi is a spec for querying server hardware
21:28:23 <ajax> intelligent something management interface
21:28:27 <ajax> probably "platform"
21:28:30 <notting> 'server hardware management cruft'
21:28:31 <mclasen> p is not panic ?
21:28:40 <pjones> ipmi means "shitty method of interfacing with hardware"
21:28:46 * mclasen some references to panic on some of the wiki links
21:28:57 <mjg59> So reading hardware sensors, power meters, performing firmware updates, looking at cycle counts, that kind of madness
21:29:06 <ajax> weak +1 for this, it barely seems worth mentioning
21:29:09 <notting> pjones: 'shitty' in the churchill-democracy sense?
21:29:11 <mjg59> It's important in the management space
21:29:15 <pjones> notting: yeah.
21:29:17 <mclasen> "ipmiutils (was panicsel)"
21:29:18 <mjg59> I can't believe I just said "management space"
21:29:29 <pjones> mjg59: you have failed.
21:29:37 <mjg59> Anyway, it's not something that's terribly relevant to Fedora, but it's something that's good for Linux
21:29:48 <mjg59> But I think we need to politely suggest that that static library die
21:29:51 * nirik gets a page. I have to step out for a bit. Can someone else run things for a bit?
21:29:57 <mjg59> Especially given that there's nothing using it right now
21:30:05 <mjg59> But, +1 for now
21:30:11 <notting> but yes, it just seems to be another CLI tool
21:30:14 <notting> which... *shrug*
21:30:17 <notting> not sure it's feature-worthy
21:30:26 <notting> weak +1
21:30:30 <pjones> +1 for barely caring.
21:30:38 <mclasen> do we have a server sig that would be interested in this ?
21:30:50 <ajax> if we do have a server sig, they would be interested i'm sure.
21:30:51 <notting> the cluster folks may be interested in using this for fencing, i would think
21:31:01 <ajax> note my use of the subjunctive.
21:31:18 <mjg59> We need one more vote, I think
21:32:06 <SMParrish> +1 sorry wife on phone
21:32:11 <ajax> there we go
21:32:16 * mclasen needs to step out for a few minutes too
21:32:23 <ajax> #agreed Feature is approved.
21:32:48 <mjg59> Ok
21:32:58 <mjg59> That's everythig on the agenda
21:33:06 <pjones> I vote to end this meeting.
21:33:18 <mjg59> And, yeah, we're at two hours
21:33:25 <ajax> RUN
21:33:47 <mjg59> Unless anyone has anything vitally important, I'm going to suggest that we leave the engineering tickets until next week
21:34:57 <mjg59> Ok
21:34:58 <mjg59> #endmeeting