| ---bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process | ||
| *jeremy may be a few minutes late | ||
| *tibbs may be a few minutes early | ||
| *c4chris too :) | ||
| bpepple | FESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren | |
|---|---|---|
| bpepple | Hi everybody; who's around? | |
| *f13 | ||
| *spot sighs | ||
| caillon | sigh. i'm sorta here. | |
| caillon | not really. | |
| *wwoods popcorn | ||
| *c4chris | ||
| caillon | but i'll try to be attentive today. | |
| *nirik is here. | ||
| *bpepple waits another minute or so to see who else shows up. | ||
| *notting is here. sorry about the delay | ||
| bpepple | notting: no worries. | |
| bpepple | ok, we can probably get started. | |
| ---bpepple has changed the topic to: FESCO-Meeting -- http://fedoraproject.org/wiki/FTBFS -- all | ||
| *dwmw2 arrives | ||
| bpepple | link to proposal: http://fedoraproject.org/wiki/FTBFS#.28Proposed.29_Package_Removal_for_Long-standing_FTBFS_bugs | |
| *dgilmore | ||
| bpepple | mdomsch wanted us to discuss his proposal. | |
| bpepple | looks pretty reasonable to me. | |
| *dwmw2 reading it to find the definition of 'long-standing' | ||
| spot | i'd argue we need to go one step further and initiate non-responsive maintainer proceedings | |
| f13 | yes | |
| f13 | that was my proposal | |
| f13 | http://fedoraproject.org/wiki/JesseKeating/AutomatedMIAProposal | |
| *abadger1999 looks in | ||
| nirik | looks pretty good, but not sure about what 'long standing' is... since the current cycle started? | |
| f13 | 'long standing' IMHO should match the timeframe for any bug not getting a response and thus being valid for Non Responsive | |
| bpepple | nirik: I would guess so, but we could ask mdomsch to clarify. | |
| notting | right, even if you're looking to remove at alpha, you don't want to start non-responsive for something that just broke the week before | |
| *dwmw2 should fix one or two 'glibc hid more stuff and now it doesn't compile' packages, rather than waiting till the next time they need touching anyway :) | ||
| f13 | https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers fyi. ALthough I think this process is way too involved | |
| *jeremy is here now | ||
| nirik | so, I guess the question is, should we move forward with this one, or try and polish up and get moving on a more comprehensive non responsive thing. | |
| bpepple | alright, it sounds like most folks agree with the general idea of mdomsch's proposal, but we just need to clarify a few items. Am I correct in that thinking? | |
| drago01 | there is also the case where a package fails to build because one of its deps is "broken" | |
| tibbs | bpepple: +1 | |
| c4chris | bpepple: +1 | |
| drago01 | so even if the mainatiner is active he has to wait for them to get fixed first | |
| dwmw2 | yeah, I don't mind the proposal per se, but automating it scares me | |
| nirik | bpepple: sure. | |
| f13 | bpepple: I think his proposal falls in line with my more reaching proposal. I think the FTBFS bugs can classify as the first bug to start the NonResponsive process on. | |
| dwmw2 | there's too much broken churn in bugzilla already | |
| tibbs | drago01: Yes, but if the dep gets blocked from the distro, then everything that depends on it is going to have to go as well. | |
| dwmw2 | f13: +1 | |
| f13 | the maintainer just has to comment in the bug why they're waiting for it and that counts as a response | |
| drago01 | ok | |
| drago01 | ex is the sudden mono breakage that is happening now | |
| tibbs | Which is probably another discussion topic. | |
| spot | most of that is cleaned up now, or should be. | |
| notting | bpepple: +1 | |
| *warren here | ||
| dgilmore | +1 | |
| bpepple | ok, so what items do we want mdomsch to clarify? We want to him to clarify what 'long-standing' is. Is there anything else? | |
| tibbs | Could we agree on a value here? Or do we want another pass through the process? | |
| f13 | tibbs: to be fair, we already agreed upon it when I got buy-off on my proposal | |
| c4chris | we want the drop to occur rigth before alpha, right ? | |
| f13 | c4chris: not 'right' before, as that can threaten the ability to get alpha out in time | |
| f13 | I'd say 2 weeks before alpha freeze | |
| tibbs | Proposal says "immediately following the Alpha". | |
| f13 | or that | |
| f13 | as to not threaten beta (: | |
| f13 | honestly I think mdomsch and I just need to work together on this, and maybe I can spend some of Casey's time on my proposal this summer | |
| nirik | and removed means: dead.package and blocked from koji? along with all dependent packages? Should we first orphan and give a chance for someone else to pick it up? | |
| c4chris | what's the time elapsed between release (current) and alpha (next) | |
| tibbs | http://fedoraproject.org/wiki/Releases/10/Schedule | |
| tibbs | Alphs is 2008-07-29 | |
| tibbs | Beta is 2008-09-02 | |
| wwoods | typically ~3months between final release and the next alpha | |
| c4chris | I'd say broken since release | |
| f13 | nirik: I think dead.package and block is the right first step, as it's removal will send mails to those that depend on it via the rawhide report | |
| nirik | f13: ok. Note that a number of these might then get picked up by a new maintainer with more interest in fixing them... | |
| f13 | I'm just not sure we need an extra level of culling here. Non-responsive maintainers of broken packages can be handled by our non-responsive maintainer policy. If tha'ts not sufficient, fix the policy, don't come up with a new one. | |
| c4chris | gives two months to react | |
| dwmw2 | yeah, I don't see the need for anything new | |
| c4chris | k | |
| dwmw2 | we should try to achieve as much as possible, with as little policy as possible. | |
| tibbs | f13: Would the NRMP if active now let is clean these packages out by 2008-08-01? | |
| nirik | f13: +1... it would be nice to get your MIA proposal finished up and coded. | |
| dwmw2 | I've always hated 'policy'. It's so often just a euphemism for not having to think. :) | |
| c4chris | need to start the process right after each release | |
| f13 | tibbs: the nonresponsive policy has been active for a while now. It just takes someone/something to do the necessary legwork of that policy (ping the bug every day or whatever) | |
| f13 | tibbs: so one could use the policy today just by hand. | |
| f13 | my proposal is about automating it, and I don't know if automation can be ready in time to clean these things out by that date. | |
| dwmw2 | this automation is what led to the 'powerpc-utils-papr FTBFS on x86_64' bug, right? :) | |
| dwmw2 | although to be fair, that's part of 'not ready' | |
| f13 | heh, sure, automation will need tweaking, and dry running and manual verification. | |
| notting | dwmw2: missing exclusivearch, or ftbfs didn't honor it? | |
| *nirik needs to also spam maintainers and eventually setup something like FTBFS for the source file auditing. | ||
| dwmw2 | the latter, I believe | |
| c4chris | nirik: agreed | |
| bpepple | ok, f13 your going to get in contact with mdomsch on this then? | |
| dgilmore | nirik: we need some exceptions for that | |
| f13 | bpepple: yes. | |
| bpepple | f13: in that case, we can probably move on. | |
| dgilmore | nirik: one of my packages has a messed up upstream. and i cant put the actual url in | |
| nirik | dgilmore: sure, I have a exceptions file... but those should be pretty rare... (ie, need to submit a form for download or whatever) | |
| nirik | yeah, or upstream that insists on ? in the url, where rpm can't grok it. | |
| bpepple | moving on, unless someone objects....... | |
| ---bpepple has changed the topic to: FESCO-Meeting -- New Maintainer Containment Membership-- f13 | ||
| bpepple | f13, you want to lead this? | |
| f13 | sure! | |
| f13 | Casey's got some work done that will make this proposal a reality | |
| warren | work in fas? | |
| f13 | http://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment that is. | |
| f13 | warren: he's done some work in pkgdb, not sure about fas yet, fas is mostly just the creation of a new group | |
| f13 | the missing parts now are A) what to name the 'supergroup' and B) how to prime that supergroup. | |
| dgilmore | f13: i like the idea of promoting sponsors first and having them elevate people they sponsor | |
| f13 | dgilmore: I do too, with the twist that sponsors would be able to sponsor /anybody/ they choose into the supergroup | |
| f13 | that was a good addition by abadger1999 | |
| notting | by implementing this, we will (at first) have *fewer* people that can commit to no-acl packages, correct? | |
| *nirik thinks this sounds great | ||
| dgilmore | nirik: yes | |
| *c4chris likes it | ||
| dgilmore | notting: yes | |
| jeremy | f13: +1 from me | |
| f13 | notting: that is correct. | |
| bpepple | notting: yeah, until they are elevated by a sponsor. | |
| dgilmore | notting: there will be much larger acls | |
| nirik | so as part of this, all currently cvsextras: no packages will get a ping to open up to the supergroup? | |
| nirik | or they will just be opened? | |
| f13 | notting: ideally what will happen is this. We'll have fewer people that can commit to no-acl, however those that /can/ are more likely to, and more likely to do it correctly. Because of this, the number of no-acl packages will increase, giving a net positive of people vs access | |
| notting | f13: +1 from me, although we may catch flak from people who can no longer commit | |
| f13 | nirik: there is a second proposal to automatically open all those that are currently closed, unless the maintianer opts-out | |
| dgilmore | +1 from me | |
| f13 | notting: nod, theoretically it'll just take some quick clicking for a sponsor to bring those people into the supergroup. | |
| f13 | not all supergroup users need to be sponsors, we're just priming the pool with sponsors. adn you ahve to be a sponsor to bring somebody new into the pool | |
| abadger1999 | f13: I see a lot of value to this as long as the second proposal is also approved to go forward. | |
| bpepple | abadger1999: +1 | |
| *nirik nods at abadger1999 | ||
| f13 | http://fedoraproject.org/wiki/JesseKeating/PackageACLOpening that's the second proposal | |
| tibbs | Can someone document this from the perspective of a new packager? | |
| f13 | that Casey has also been working on | |
| tibbs | I suck at that kind of pseudo-motivational kind of thing. | |
| nirik | also, would be good to provide a link to the group of sponsors so people know who to bug to get into the supergroup. | |
| f13 | tibbs: that's a good thought, how does this look from the new packager perspective. | |
| warren | http://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment seems a little unclear what the process is for a new contributor, can this be written out | |
| f13 | nirik: indeed. | |
| f13 | warren: I'll work with Casey to get it documented. | |
| tibbs | f13: I think it will look pretty good because they won't have to wait around forever to get sponsored. | |
| warren | perhaps "what does this mean to existing contributors" can be spelled out too | |
| f13 | in short, the new contributor does the same as always, applies for a group, gets sponsored, has write access to their packages. | |
| f13 | tibbs: I don't think we're removing the need to get sponsored | |
| f13 | warren: also a good point. | |
| tibbs | f13: I didn't say we did. But with containment, sponsors will be more likely to actually sponsor people. | |
| nirik | no, but sponsors can feel better about sponsoring when they know the new packager can only mess up their own package(s). | |
| f13 | tibbs: good point. | |
| f13 | excellent point. | |
| c4chris | +1 on both proposals | |
| nirik | +1 on both here. Sooner the better. ;) | |
| f13 | (: | |
| warren | I like it in concept but I really want it to be spelled out. | |
| f13 | hooray for interns | |
| tibbs | We still need to figure out how to sell the idea of getting higher access, so that the "supergroup" actually grows over time. | |
| tibbs | ANyway, +1 on both proposals from me. | |
| notting | +1 on both, just to clarify | |
| bpepple | +1 to both proposals. | |
| warren | I'm +1 to PackageACLOpening only at the moment | |
| dgilmore | +! from me also | |
| dgilmore | on both | |
| *bpepple lost power, so I'm not sure what the vote count is. | ||
| dgilmore | warren: there will be resistence to PackageACLOpening without NewMaintainerContainment | |
| f13 | bpepple: there has been no - votes. | |
| bpepple | f13: ok. | |
| f13 | warren: yeah, PackageACLOpening will be a failure without the containment. TO be fair, containment was approved by FESCo in the past, almost as is written. | |
| warren | I'm not against NewMaintainerContainment in concept, but the details seem really unclear to me | |
| f13 | with the promise that I would come back with code in hand later for one more round of discussion. | |
| warren | the way it is written now is confusing | |
| abadger1999 | bpepple: c4chris and nirik +1'd both before you got back. | |
| warren | I want to see how it flows from different point of views | |
| f13 | warren: what is confusing to you? | |
| tibbs | For some reason I'm not confused, which is surprising to me. | |
| *warren just woke up. a little fuzzy. | ||
| warren | 7:38am here | |
| tibbs | warren: Regarding your previous question, there is no change for a new contributor. | |
| f13 | warren: as a new maintainer, the only thing that changes is you have write access to your package(s), and any package(s) somebody has explicitly granted you write access to. | |
| f13 | the process of becoming a new contributor doesn't change at all | |
| f13 | (other than s/cvsextras/packagers/) | |
| warren | f13: OK, I'll just give +1 now, but I want to see how it improves | |
| warren | packagers or packager? | |
| warren | (the latter seems better to me) | |
| spot | +1 from me, fwiw. | |
| *nirik doesn't care at all what the groups are called.. thats bikeshed painting to me. | ||
| c4chris | I now count 8 +1 on containment and openACL | |
| f13 | warren: it's whatever you already created. | |
| f13 | warren: we're re-using the group that exists and has code written to handle it. | |
| warren | ok | |
| notting | so we're not renaming the groups to rhesus and capuchin? | |
| f13 | anybody have an opinion on doing 'packager' as the base level and 'superpackager' as the elevated level? 'heropackager' ? | |
| dgilmore | f13: id avoid super and hero | |
| dwmw2 | packagemonkey and maintainer? :) | |
| c4chris | dementors ? | |
| dgilmore | packager and advancedpackager | |
| f13 | dgilmore: worksforme | |
| dgilmore | dwmw2: that would promote the wrong attitute | |
| dgilmore | attitude | |
| dwmw2 | heh | |
| dwmw2 | überpackager? with the umlaut being mandatory | |
| dwmw2 | utf-8 ftw | |
| f13 | hahaha | |
| f13 | dwmw2: that's actually not a bad idea | |
| abadger1999 | dwmw2: +1 | |
| c4chris | ü | |
| abadger1999 | (not on fesco) :-) | |
| f13 | I'll run with that and see what breaks. | |
| f13 | (überpackager) that is. | |
| f13 | anyway, that's all I have for that. | |
| bpepple | f13: cool, thanks. | |
| ---bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora | ||
| bpepple | ok, that's it for the scheduled items this week. anything else folks wish to discuss? | |
| *bpepple listens to the crickets. | ||
| *dgilmore has nothing | ||
| c4chris | crickets 'til Monday ? | |
| tibbs | Yeah, Monday. | |
| bpepple | c4chris: yeah. ;) | |
| bpepple | ok, since there doesn't seem to be anything else, I'll start the countdown. | |
| *bpepple will end the meeting in 60 | ||
| warren | what's monday? | |
| tibbs | I'm kind of unclear on just what's supposed to happen on monday. | |
| dgilmore | warren: read your email | |
| c4chris | we fry the crickets :) | |
| f13 | discussion with the board about the future role of FESCo | |
| warren | it appears that I will be off the plane by then | |
| *bpepple will end the meeting in 30 | ||
| *bpepple will end the meeting in 15 | ||
| bpepple | -- MARK -- Meeting End | |
Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!