=================================== #fedora-meeting: FESCO (2010-06-29) ===================================
Meeting started by nirik at 19:30:02 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2010-06-29/fesco.2010-06-29-19.30.log.html Meeting summary --------------- * init process (nirik, 19:30:02) * mclasen is unable to attend today and has added his comments to tickets. (nirik, 19:33:02) * #351 Create a policy for updates - status report on implementation (nirik, 19:34:16) * #382 Implementing Stable Release Vision (nirik, 19:38:04) * Will try and add ideas to container this coming week, discuss again next week hopefully to assign and plan. (nirik, 19:46:38) * #387 compile list of supported CPUs and reacto to recent loss of support for Geode LX on F13 (nirik, 19:46:49) * Provenpackager / Sponsor policy revisit (nirik, 19:51:20) * 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. (nirik, 19:56:12) * ACTION: nirik will update trac/wiki pages. (nirik, 19:56:36) * #403 Abuse of Privileges / Procedure Overruled (nirik, 19:56:43) * LINK: https://admin.fedoraproject.org/pkgdb/users/packages/perl-sig?acls=owner&acls=approveacls&acls=commit (nirik, 20:09:14) * AGREED: no mass acl change will be made unless the requester has approveacls on the packages requested. if not, escalate to fesco. (nirik, 20:18:02) * AGREED: mass change admin will mail all affected package owners before the mass change is made explaining who requested it and what and why. (nirik, 20:30:41) * AGREED: revert permissions on packages where approving maintainers didn't have approveacls (nirik, 20:37:28) * LINK: https://fedoraproject.org/wiki/PackageMaintainers/Join only lists one way and that is through a new package submission and also includes doing reviews (cwickert, 20:46:55) * our docs on sponsorship need serious work. (nirik, 20:52:00) * #405 Request to find resolution for the binutils static library saga (nirik, 20:53:55) * AGREED: ask binutils maintainer to rename -static to -devel, adjust provides accordingly (nirik, 21:02:02) * #404 Binary Name Conflicts in freeze and mlt (nirik, 21:10:04) * FESCo feels this is not something we can/should weigh in on. Please work it out between maintainers. (nirik, 21:19:04) * #406 F14Feature: http://fedoraproject.org/wiki/Features/F14Boost144 (nirik, 21:19:14) * AGREED: Feature is approved. (nirik, 21:21:29) * #407 F14Feature: http://fedoraproject.org/wiki/Features/Python_2.7 (nirik, 21:21:36) * AGREED: Feature is approved. (nirik, 21:24:06) * #408 F14Feature: http://fedoraproject.org/wiki/Features/ipmiutil (nirik, 21:25:31) * AGREED: Feature is approved. (ajax, 21:32:23) Meeting ended at 21:34:58 UTC. -- 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
signature.asc
Description: PGP signature
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
