---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 :)
bpeppleFESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren
bpeppleHi everybody; who's around?
*spot sighs
caillonsigh.  i'm sorta here.
caillonnot really.
*wwoods popcorn
caillonbut 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
bpepplenotting: no worries.
bpeppleok, we can probably get started.
---bpepple has changed the topic to: FESCO-Meeting -- http://fedoraproject.org/wiki/FTBFS -- all
*dwmw2 arrives
bpepplelink to proposal: http://fedoraproject.org/wiki/FTBFS#.28Proposed.29_Package_Removal_for_Long-standing_FTBFS_bugs
bpepplemdomsch wanted us to discuss his proposal.
bpepplelooks pretty reasonable to me.
*dwmw2 reading it to find the definition of 'long-standing'
spoti'd argue we need to go one step further and initiate non-responsive maintainer proceedings
f13that was my proposal
*abadger1999 looks in
niriklooks 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
bpepplenirik: I would guess so, but we could ask mdomsch to clarify.
nottingright, 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 :)
f13https://fedoraproject.org/wiki/PackageMaintainers/Policy/NonResponsiveMaintainers fyi.  ALthough I think this process is way too involved
*jeremy is here now
nirikso, 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.
bpepplealright, 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?
drago01there is also the case where a package fails to build because one of its deps is "broken"
tibbsbpepple: +1
c4chrisbpepple: +1
drago01so even if the mainatiner is active he has to wait for them to get fixed first
dwmw2yeah, I don't mind the proposal per se, but automating it scares me
nirikbpepple: sure.
f13bpepple: 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.
dwmw2there's too much broken churn in bugzilla already
tibbsdrago01: Yes, but if the dep gets blocked from the distro, then everything that depends on it is going to have to go as well.
dwmw2f13: +1
f13the maintainer just has to comment in the bug why they're waiting for it and that counts as a response
drago01ex is the sudden mono breakage that is happening now
tibbsWhich is probably another discussion topic.
spotmost of that is cleaned up now, or should be.
nottingbpepple: +1
*warren here
bpeppleok, so what items do we want mdomsch to clarify?  We want to him to clarify what 'long-standing' is.  Is there anything else?
tibbsCould we agree on a value here?  Or do we want another pass through the process?
f13tibbs: to be fair, we already agreed upon it when I got buy-off on my proposal
c4chriswe want the drop to occur rigth before alpha, right ?
f13c4chris: not 'right' before, as that can threaten the ability to get alpha out in time
f13I'd say 2 weeks before alpha freeze
tibbsProposal says "immediately following the Alpha".
f13or that
f13as to not threaten beta (:
f13honestly 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
nirikand 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?
c4chriswhat's the time elapsed between release (current) and alpha (next)
tibbsAlphs is 2008-07-29
tibbsBeta is 2008-09-02
wwoodstypically ~3months between final release and the next alpha
c4chrisI'd say broken since release
f13nirik: 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
nirikf13: ok. Note that a number of these might then get picked up by a new maintainer with more interest in fixing them...
f13I'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.
c4chrisgives two months to react
dwmw2yeah, I don't see the need for anything new
dwmw2we should try to achieve as much as possible, with as little policy as possible.
tibbsf13: Would the NRMP if active now let is clean these packages out by 2008-08-01?
nirikf13: +1... it would be nice to get your MIA proposal finished up and coded.
dwmw2I've always hated 'policy'. It's so often just a euphemism for not having to think. :)
c4chrisneed to start the process right after each release
f13tibbs: 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)
f13tibbs: so one could use the policy today just by hand.
f13my 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.
dwmw2this automation is what led to the 'powerpc-utils-papr FTBFS on x86_64' bug, right? :)
dwmw2although to be fair, that's part of 'not ready'
f13heh, sure, automation will need tweaking, and dry running and manual verification.
nottingdwmw2: 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.
dwmw2the latter, I believe
c4chrisnirik: agreed
bpeppleok, f13 your going to get in contact with mdomsch on this then?
dgilmorenirik: we need some exceptions for that
f13bpepple: yes.
bpepplef13: in that case, we can probably move on.
dgilmorenirik: one of my packages has a messed up upstream.  and i cant put the actual url in
nirikdgilmore: sure, I have a exceptions file... but those should be pretty rare... (ie, need to submit a form for download or whatever)
nirikyeah, or upstream that insists on ? in the url, where rpm can't grok it.
bpepplemoving on, unless someone objects.......
---bpepple has changed the topic to: FESCO-Meeting -- New Maintainer Containment Membership-- f13
bpepplef13, you want to lead this?
f13Casey's got some work done that will make this proposal a reality
warrenwork in fas?
f13http://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment that is.
f13warren: he's done some work in pkgdb, not sure about fas yet, fas is mostly just the creation of a new group
f13the missing parts now are A) what to name the 'supergroup' and B) how to prime that supergroup.
dgilmoref13: i like the idea of promoting sponsors first and having them elevate people they sponsor
f13dgilmore: I do too, with the twist that sponsors would be able to sponsor /anybody/ they choose into the supergroup
f13that was a good addition by abadger1999
nottingby implementing this, we will (at first) have *fewer* people that can commit to no-acl packages, correct?
*nirik thinks this sounds great
dgilmorenirik: yes
*c4chris likes it
dgilmorenotting: yes
jeremyf13: +1 from me
f13notting: that is correct.
bpepplenotting: yeah, until they are elevated by a sponsor.
dgilmorenotting: there will be much larger acls
nirikso as part of this, all currently cvsextras: no packages will get a ping to open up to the supergroup?
nirikor they will just be opened?
f13notting: 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
nottingf13: +1 from me, although we may catch flak from people who can no longer commit
f13nirik: there is a second proposal to automatically open all those that are currently closed, unless the maintianer opts-out
dgilmore+1 from me
f13notting: nod, theoretically it'll just take some quick clicking for a sponsor to bring those people into the supergroup.
f13not 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
abadger1999f13: I see a lot of value to this as long as the second proposal is also approved to go forward.
bpeppleabadger1999: +1
*nirik nods at abadger1999
f13http://fedoraproject.org/wiki/JesseKeating/PackageACLOpening  that's the second proposal
tibbsCan someone document this from the perspective of a new packager?
f13that Casey has also been working on
tibbsI suck at that kind of pseudo-motivational kind of thing.
nirikalso, would be good to provide a link to the group of sponsors so people know who to bug to get into the supergroup.
f13tibbs: that's a good thought, how does this look from the new packager perspective.
warrenhttp://fedoraproject.org/wiki/JesseKeating/NewMaintainerContainment seems a little unclear what the process is for a new contributor, can this be written out
f13nirik: indeed.
f13warren: I'll work with Casey to get it documented.
tibbsf13: I think it will look pretty good because they won't have to wait around forever to get sponsored.
warrenperhaps "what does this mean to existing contributors" can be spelled out too
f13in short, the new contributor does the same as always, applies for a group, gets sponsored, has write access to their packages.
f13tibbs: I don't think we're removing the need to get sponsored
f13warren: also a good point.
tibbsf13: I didn't say we did.  But with containment, sponsors will be more likely to actually sponsor people.
nirikno, but sponsors can feel better about sponsoring when they know the new packager can only mess up their own package(s).
f13tibbs: good point.
f13excellent point.
c4chris+1 on both proposals
nirik+1 on both here. Sooner the better. ;)
warrenI like it in concept but I really want it to be spelled out.
f13hooray for interns
tibbsWe still need to figure out how to sell the idea of getting higher access, so that the "supergroup" actually grows over time.
tibbsANyway, +1 on both proposals from me.
notting+1 on both, just to clarify
bpepple+1 to both proposals.
warrenI'm +1 to PackageACLOpening only at the moment
dgilmore+! from me also
dgilmoreon both
*bpepple lost power, so I'm not sure what the vote count is.
dgilmorewarren: there will be resistence to PackageACLOpening without NewMaintainerContainment
f13bpepple: there has been no - votes.
bpepplef13: ok.
f13warren: yeah, PackageACLOpening will be a failure without the containment.  TO be fair, containment was approved by FESCo in the past, almost as is written.
warrenI'm not against NewMaintainerContainment in concept, but the details seem really unclear to me
f13with the promise that I would come back with code in hand later for one more round of discussion.
warrenthe way it is written now is confusing
abadger1999bpepple: c4chris and nirik +1'd both before you got back.
warrenI want to see how it flows from different point of views
f13warren: what is confusing to you?
tibbsFor some reason I'm not confused, which is surprising to me.
*warren just woke up. a little fuzzy.
warren7:38am here
tibbswarren: Regarding your previous question, there is no change for a new contributor.
f13warren: 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.
f13the process of becoming a new contributor doesn't change at all
f13(other than s/cvsextras/packagers/)
warrenf13: OK, I'll just give +1 now, but I want to see how it improves
warrenpackagers 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.
c4chrisI now count 8 +1 on containment and openACL
f13warren: it's whatever you already created.
f13warren: we're re-using the group that exists and has code written to handle it.
nottingso we're not renaming the groups to rhesus and capuchin?
f13anybody have an opinion on doing 'packager' as the base level and 'superpackager' as the elevated level?  'heropackager' ?
dgilmoref13: id avoid super and hero
dwmw2packagemonkey and maintainer? :)
c4chrisdementors ?
dgilmorepackager and advancedpackager
f13dgilmore: worksforme
dgilmoredwmw2: that would promote the wrong attitute
dwmw2├╝berpackager? with the umlaut being mandatory
dwmw2utf-8 ftw
f13dwmw2: that's actually not a bad idea
abadger1999dwmw2: +1
abadger1999(not on fesco) :-)
f13I'll run with that and see what breaks.
f13(├╝berpackager) that is.
f13anyway, that's all I have for that.
bpepplef13: cool, thanks.
---bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
bpeppleok, that's it for the scheduled items this week.  anything else folks wish to discuss?
*bpepple listens to the crickets.
*dgilmore has nothing
c4chriscrickets 'til Monday ?
tibbsYeah, Monday.
bpepplec4chris: yeah. ;)
bpeppleok, since there doesn't seem to be anything else, I'll start the countdown.
*bpepple will end the meeting in 60
warrenwhat's monday?
tibbsI'm kind of unclear on just what's supposed to happen on monday.
dgilmorewarren: read your email
c4chriswe fry the crickets :)
f13discussion with the board about the future role of FESCo
warrenit 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!