--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process
bpeppleFESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren
Hi everybody; who's around?
* jwb is 1/2 here for a bit
dwmw2_HIO is
nirik is here, but is running over to get coffee, back in a sec.
warrenI guess this is my last fesco meeting ever?
* jeremy
bpepplewarren: you don't have to be on FESCo to join the meetings. ;)
bpeppleok, I see seven FESCo members so we can probably get started.
--- bpepple has changed the topic to: FESCo-Meeting -- new maintainer containment update -- sadmac2, abadger1999
bpeppleabadger1999 or sadmac2 about?
sadmac2bpepple: here
bpeppleyou want to take the lead on this?
So, we are getting ready to execute on the new maintainer containment proposal
There's 3 steps to this:
1) Rename cvsextras to packager (mostly a cosmetic change)
2) Add ACLs for the new uberpackager group to all packages
3) Add all current sponsors to the uberpackager group
oh, also 4) remove acls for regular packager group for all packages
5) ??? 6) Profit. etc. etc.
* dwmw2_HIO likes (4)
sadmac2dwmw2_HIO: this was the purpose of all this
dwmw2_HIOer, I think
warrenwe will really call it uberpackager?
sadmac2warren: ys
as of now
dwmw2_HIOit _has_ to be überpackager
notting'remove acls for regular packager' == 'open for all', or 'no longer open'?
ianwellerdoes FAS like the umlaut? ;)
sadmac2dwmw2_HIO: we tried. there are pieces of software involved that hate unicode
nottingi.e., have non-sponsors effectively been downgraded?
dwmw2_HIOit should be open for all, right?
sadmac2notting: they will be open to all uberpackagers and their owners
abadger1999Really... 4?
dwmw2_HIOer, isn't that a backward step?
we want all packages to be open to all people. Except perhaps to a few 'junior packagers' who can only touch their own
sadmac2notting: the process for getting sponsored for uberpackager is going to be trivial. within hours anyone who ever really needed the access will have it
jeremydwmw2_HIO: the problem is amongst our existing set of packagers, how do you determine who are the junior vs not?
sadmac2dwmw2_HIO: Its not going to be terribly hard to become an uberpackager
dwmw2_HIOok, so _most_ people who care should be 'überpackagers'?
fine. Then it's just that I was a bit mislead by the terminology
jeremydwmw2_HIO: by putting the sponsors there (and giving sponsors the ability to put other people in teh group), that should work itself out to the "correct" state pretty quickly
warrenhow about uberpackager requires a sponsor to upgrade them?
sponsors are approved only by fesco vote
and we have a good number of existing sponsors
abadger1999sadmac2: Is 4 really going to happen or is that something for individual package maintainers to decide?
sadmac2warren: uberpackager requires an existing uberpackager to approve
warrenthat's fine to me
sadmac2abadger1999: it is, in preparation for the mass ACL open. We can't do that without the containment line
warrenthen make uberpackager == sponsors at first
nottingsadmac2: so, the acl open is actually 'acl open to uberpackagers'?
abadger1999sadmac2: Why can't mass acl open open packages to uberpackager?
sadmac2notting: precisely
sadmac2abadger1999: then permissions become very complicated and people get confused
drago01sound worse than what we have know ... less people with access to everything
sadmac2abadger1999: the idea is packagers can ONLY touch packages they are maintainers of
spotthat seems... wrong.
dwmw2_HIOI agree
spoti have cvsextras open on my packages specifically so others can make changes if they need to
dwmw2_HIOideally, all packagers should be able to touch all packages where appropriate
sadmac2spot, dwmw2_HIO: I stress again that it will not be hard by any stretch of the imagination to become an uberpackager
spoteven still.
dwmw2_HIOa lot of people have deliberately opened the ACLs on their packages
_those_ packages should remain open to all packagers
sadmac2you just have to find someone who is, and ping them. thats it
spotif you want to temporarily contain people, that is fine
dwmw2_HIOit should be a kind of 'probation period' for new maintainers
spot(new people)
abadger1999sadmac2: Could you explain who is in uberpackager and who is in cvsextras?
ideally... not at first.
dwmw2_HIOand 'überpackager' status should actually be the norm. You shouldn't really have to jump through hoops for it -- however simple those hoops actually are
sadmac2abadger1999: uberpackager is anyone who wants to be there, and has convinced at least one person who is there already that they are not an idiot
spotI see three groups here: 1. New Packager (can only touch their package) 2. Packager (can touch anything with open ACLs) 3. Super Packager (can touch anything)
dwmw2_HIOcan we do a separate commits-list for commits made by people who aren't maintainers?
sadmac2dwmw2_HIO: so you just want it on a timeout
dwmw2_HIOthat would help to improve the security situation where we are worried about malicious commits to other packages
sadmac2spot: the need for group 3 hasn't really arisen yet
dwmw2_HIOsadmac2: maybe not _actually_ a timeout. But something like that
sadmac2spot: packager and uberpackager are 1 and 2
spotsadmac2: actually, it has. secondary arch groups are in 3.
2 is what everyone is now
abadger1999spot: Group 3 exists but is not separate from cvsadmin.  We could make that group at any time really... populating the initial sponsors would be the only hard part.
sadmac2spot: well we're moving people back to 1 and creating a new 2
nottingif we're intending to have a group 3, then we probably shouldn't call 2 uberpackager
spotsadmac2: which is what i am opposed to.
everyone in the system now should stay in 2 as is.
drago01example where group 3 would help: https://bugzilla.redhat.com/show_bug.cgi?id=455734
buggbotBug 455734: low, low, ---, Parag, NEW , broken dep in rawhide
* sadmac2 really wishes jesse was here for this
spotif you want to create a containment for new packagers, thats fine
bpepplebtw, this (uberpackager) is something we decided awhile back about in FESCo.  sadmac2 merely implemented it.
dwmw2_HIOit should be 'probation', 'packager', 'überpackager'
sadmac2spot: bpepple is correct
spotdwmw2_HIO: lets not paint the bikeshed
* sadmac2 searches for meeting minutes
warrenI care less what the group names are called
dwmw2_HIOspot: there was a technical distinction there, not just the names
warrenbut I think the 3 levels is a good idea.
nirikI think the only point of contention is if 2 should have the existing cvsextras or 1 should
abadger1999So here's the goals I heard from f13: 1) Have a way to contain new maintainers 2) Get more packagers to open the acls of their packages to (nearly) all the other packagers
spotbpepple: we really decided that packagers won't be able to touch things with open acls?
dwmw2_HIOI mean, we shouldn't be moving people back from (2) to (1).
warrenit depends if packager is the lowest (probationary) level or not.
bpeppleyeah.  we decided that it was easy enough for sponsors to upgrade the accounts of people that wanted access to all packages.
nirikmany current cvsextras people will not care, they only look at their own packages ever.
* spot shakes his head
warrenI think packager (former cvsextras) should be level 2.
bpeppleone moment, and let me see if I can find the minutes of the meeting we discussed this in.
nirikwarren: +1
abadger19991 is easy to envision.  I think f13's idea was if we put everyone in 2 and have an immediate shaking out of sponsors pushing people into 2 we'd build confidence for cautious maintainers to allow 2 to happen.
sadmac2I think we're all overestimating how important level 2 is
* spot notes that this is a pointless exercise, if we do this, i will promptly elevate everyone in sight to l2.
bpepplespot: I believe it was at this meeting: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20080605
dwmw2_HIOI do appreciate that if it's _easy_ to move to (2) from (1) then it's mostly cosmetic
sadmac2I'm betting 95% of maintainers won't even notice
jeremyabadger1999: correct
dwmw2_HIObut we want to _encourage_ participation and make people think it's easy
there are a lot of people who just wouldn't ask, unfortunately.
spotthe normal state for packagers should be uncontained
warrenDo we at least have agreement of the 3 level structure?
spotnot contained by default.
dwmw2_HIOit's sad but true -- we exclude people just by making them ask for it
warrendwmw2_HIO: +1
nottingi think the idea is that if you make an actual process of having elevated privleges, you make it more likely that maintainers with ACLs will remove them
sadmac2ah, I see bpepple linked already
nirikalso, someone requesting will be more likely to use that to fix/help than someone who just happens to have it without really knowing it.
jeremyspot: and if that's the normal state, then we haven't changed a thing from where we are today and the maintainers who don't want to open acls are going to continue to not want to
dwmw2_HIOnotting: I suppose that's a useful goal. Do we have stats on how many people have removed their ACLs?
and their reasons for not doing so?
jeremynirik: that's a good point I hadn't even thought of
spotjeremy: i'm not against new maintainer containment on a temporary basis
nirikdwmw2_HIO: I have bugged any new cvs requests with closed cvsextras about it... most have said "too many people in that group" or the like for why they want to do it.
spotbut i am against restricting people who get past unnecessarily
sadmac2spot: well what's the deciding factor for who's "ready?"
dwmw2_HIOanother way to assuage their concerns might be a special commits list for 'non-maintainer commits', which would have a bit less traffic and a few more eyes than the main commits list
and a threat of demoting people to 'probationary packager' status (or whatever we call state (1)) if there are bad commits on that list
and/or maybe non-maintainer commits could be Cc'd to the sponsor of the committer
there are a bunch of ways to make people happier about opening up the ACLs. do we really need to do _this_ one this way?
spotsadmac2: i think a period of time along with the conditions that dwmw2 is describing are sufficient
abadger1999So here's a question: Will a separate group actually make any of these maintainers comfortable enough to open their acls?  Or is it still going to be... there's too many people in that group...
sadmac2spot: what about a combination: after a period of time in stead of just getting promoted, fedora-devel-list just gets poked informing everyone that these people are still packagers
spoti think if we do this, we will end up with a lot of people who can no longer use open acls, thus defeating the point of opening things up.
sadmac2with the expectation that the worthy be promoted
abadger1999dwmw2_HIO: I sort of like that... although we already have mail from the commit going directly to the maintainers of the package.  Will another mailing list help?
dwmw2_HIOabadger1999: any way for them to filter it differently would help. Doesn't have to be another list
sadmac2I think the packaging system is noisy enough
dwmw2_HIOcould just be a header X-Fedora: NON MAINTAINER COMMIT BY dwmw2! You might want to check if he's broken it
nirikabadger1999: no way to be sure... we could generate a list of them and ask...
dwmw2_HIOthat would let people highlight non-maintainer commits.
bpepplesadmac2: +1
dwmw2_HIOI suspect that if we really do make it easy to obtain state (2), then the 'too many people' argument would still apply
if all you have to do is _ask_, then the only people who are excluded are the people who weren't going to commit to other packages _anyway_
except by accident in a fit of drunkenness, perhaps
but I haven't done that for years
bpeppleIf we're going to change the requirements of new maintainer containment, I would like to see a proposal instead of doing it ad-hoc during the meeting.
sadmac2dwmw2_HIO: the individual can still say "um, no" but its expected that's rare
abadger1999dwmw2_HIO: I think your suspicion may be correct :-(
nirikbpepple: agreed.
dwmw2_HIOif my suspicion _is_ correct, then we don't actually gain much by pushing people from (2) to (1) right now.
dwmw2_HIObpepple: yes, but we can get to a better proposal after we've talked it through and reached some form of consensus.
drago01what about everyone can commit and only people in group "whatever" can build?
sadmac2drago01: or tag
dwmw2_HIOI think that would also encourage people to open up commits, yes.
nirikthe proposal's goal is to contain new maintainers... not all existing maintainers.
sadmac2that makes cvs acls more complex
they're buckling as is....
dwmw2_HIObuild. tag. push. Or something
sadmac2not to say we can't
abadger1999build needs work in koji.
tag is only so so since koji will build from HEAD.
(Just scratch build, though.)
sadmac2abadger1999: I thought koji built by tag
dwmw2_HIOI think there are a lot of ways we can encourage people to open their ACLs, and moving existing packagers from (2) to (1) possibly _doesn't_ achieve it as much as we'd want it to anyway.
abadger1999sadmac2: Yes.  But HEAD is a tag for this purpose.
drago01you can commit anything and do make scratch-build
dwmw2_HIOleaving the other encouragements aside for now, let's get back to the containment. Is the only question whether we want to move existing packages from (2) to (1)?
warrenDoes this mean we will indeed have 3 levels?
dwmw2_HIOI think 3 levels makes sense
warrenLet's come to agreement on that part first because it is easier?
dwmw2_HIO(1) is only their own packages. (2) is all open packages, (3) is all closed packages too
* nirik nods. 3 levels is fine... the 3rd right now is cvsadmins and secondary arch leads, right?
abadger1999two levels (third level is sort of there but hidden -- cvsadmin, secondary arch)
sadmac2I don't think 3 is even in the scope here. It exists, we're not changing it
warrenOK, so that seems like agreement.
Now s/cvsextras/packager/ is level 1 or 2?
dwmw2_HIOso it's really just a question of whether we move existing packages from (2) to (1) ?
nottingyou typoed again
dwmw2_HIOyou should be used to it by now
drago01packagers are just packages for dwmw2_HIO ;)
* dwmw2_HIO recompiles drago01 for powerpc
dwmw2_HIOer, I mean ia64.
dwmw2_HIOsince I'm actually sitting _in_ an Intel office right now.... :)
warrenIf s/cvsextras/packager/ becomes level 2, then acl's don't change at all for them.  Then we need a new group for level 1, where they have access only to packages they own.  Is this really complex to implement?
sadmac2warren: its proven a pain in the ass to mess with the groups
abadger1999warren: Not too complex.
warrensadmac2: elaborate?
nottingi think the biggest issue with the new group is determining who goes in it to start off with
abadger1999Need thought to make sure it works but what I'd do is:
nottingbecause certainly there are people in cvsextras now who probably should be there instead
sadmac2warren: there's quite a bit of ugly hardcoded things in pkgdb
abadger1999add all current cvsextras => uberpackager.  Rename cvsextras and uberpackager as appropriate.
Should be fine.
warrenWe need to come to agreement on *something*.
dwmw2_HIOif there are really people we want to exclude (who'd be offended if we just named them and said so) then we can invent heuristics for deciding whether each existing packager goes into (1) or (2)
and then 'promote' people as required afterwards
nirikwe could possibly gather a list of all people who have commited to a package not their own and add them to 2? seems a lot of effort for not much tho
dwmw2_HIOproposal: Most (if not all) existing packagers should go into group (2), which is currently called überpackager but might want renaming.
sadmac2The name is a bikeshed. Furthermore its a bikeshed that has to be painted upside down in zero gravity with special teflon paint thats made by monks in egypt
sadmac2leave it alone, for all of our sake
It has a coat on it
proposal: Most (if not all) existing packagers should go into group (2)
warrenShouldn't we decide upon 1) a dividing line and 2) who gets to promote them?
* nirik is fine with that, but hopes it won't mean that closed acl packages would stay closed.
nirikhow many packages do we still have with closed acls?
sadmac2not sure
nirikif we are trying to get those maintainers comfortable with opening things up, shouldn't we ask them what we need to do to get them happy and comfortable?
or do we care?
sadmac2part of this proposal was that we would open all of them afterward (with an opt-out checkbox in pkgdb if you really didn't want that)
nirikat least some of them may be happy with just new maintainers contained.
some of them may want the group of commiters to be smaller
abadger1999nirik: I think that would be good.  I talked to one during FudCON which would support dwmw2_HIO's suspicion (only one data point though)
* nirik has a hard time telling as he has all his open.
* bpepple sees that we've spent 45 minutes discussing this.
warrenWhat are the points that we do have agreement on?
abadger1999warren: Having a further level.
dwmw2_HIObpepple: feel free to put your chairman hat on and repeat my proposal in a way that makes people vote on it :)
abadger1999warren: New maintainers go in the lowest level
dwmw2_HIO+1, btw
abadger1999warren: Undecided is: Where do present maintainers go?  And How do we transition people from lowest level to second level?
warrenLet's decide on both now.
dividing line must be simple and imperfect so we'll actually decide now
* nirik wonders if we are going to decide on anything here.
warrenStarting membership in level 2: "owns 8 packages on X date" + FESCO/releng
bpeppleok, so I see two proposals here.  1) The original proposal we approved back in June, 2) New proposal to move all current cvsextras member to the uberpackager group, and have new maintainers join the packager group.
* nirik wonders if the rest of fesco is off having fun instead of providing input here. ;)
bpeppleDoes that sound correct?
nirikbpepple: whats the link to the orig proposal from 1?
warrenperhaps we need to follow up on list.  we don't have quorum?
* bpepple sees if he can find the link. It's summarized here though: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20080605
dwmw2_HIOwarren: that seems close enough to me. There's no point in arguing about details since we can move people. +1 to 'owns 8 packagers + FESCo/releng'
dwmw2_HIOas an initial heuristic for it
warren'owns 8 packagers + FESCo/releng' is just an arbitrary, simple and imperfect line to draw so we can decide on something.
damn it
8 packages
* spot pwns 8 packagers
warrendwmw2_HIO: did you do that intentionally?  I didn't type packagers at first.
* stickster points out that respect means not owning people
nirikthats fine for me +1
spotfwiw, that is ok for me as well (+1)
warrenseemingly we don't have enough people to vote?
sadmac2stickster: what if they're noobs? can I still own noobs hardcore
warrenAnyhow, the second part we need to decide:
Who gets to promote?
Any existing level 2 member?
jeremy+1 I guess, although why we need to re-decide I'm still not quite clear
warrenLevel 3 + FESCO + rel-eng?
* nirik thinks we need to redecide because people were unclear on what we decided last time.
bpepplejeremy: agreed, I don't see the point either.
+1 reluctantly.
nottingjeremy: well, if it's just changing the initial population of $GROUP_NAME, consider it an amendment?
warrenLevel 3 = Sponsors, FESCO, releng (possibly others)?
sadmac2warren: level 3 is outside the scope
warren: its there, we need not change it for this proposal
warrensadmac2: not exactly
Who gets to promote someone from level 1 to level 2 is important.
abadger1999Adreed.  Level 3 is outside of scope *and* was essentially decided last week.
sadmac2warren: if you're going to make that depend on level 3 don't redefine level 3 in the process
warrenWhat is level 3 currently defined as?
dwmw2_HIOare sponsors all in level 3 (can commit to _all_ packages) ?
abadger1999(cvsadmin sponsor/admins can decide who is in level 3)
sponsors are level 2 at this point.
and under the current proposals.
nirikwe agreed before that sponsors can elevate people from 1->2.
I am fine with that.
warrenbut anybody who becomes level 2 is a sponsor then?
nottingeh, just sponsors seems fine to me. people need sponsored to get to level 1 anyway
nirikwarren: don't think so... sponsors are people approved by fesco to be packaging sponsors.
Are there any remaining disagreements then?
Let's recap exactly what will happen?
sadmac2first will be the cvsextras rename
bpepplewarren: please do, so it will make it easier when I write the meeting summary.
sadmac2then uberpackager will be seeded with the set we defined here and given appropriate acls everywhere
then we will remove acls for packager
* nirik nods.
warrenThen sponsors can go ahead and promote anyone they want?
* nirik would like a email to fedora-devel-announce outlining this entire thing if possible, so maintainers know whats going on.
bpepplenirik: agreed.
jeremynirik: I thought that was a given :)
warrenoh, one more amendment
Initial uberpackagers: owns 8 packages today + fesco/releng + sponsors
(forgot sponsors earlier)
abadger1999: could you generate a list of accounts who own at least 8 packages quickly?
abadger1999warren: Do we want to include comaintainers?
warrengood question
abadger1999actually.... this may get tricky.
abadger1999Well... alright if we know that some people will be left out and will need to be leveled-up then it's okay.
warrenlevelled up
bpeppleok, anything else on this, or should we move on?
abadger1999(Thinking of desktop group, for instance, where they have opened acls so that everyone in their team can commit.... not relying on setting commit for the individual members)
abadger1999bpepple: Do you guys want me to include commaintainers?
warrenabadger1999: but those teams have a sponsor on their team
abadger1999and we can define that as either: has approveacls or has commit.
nirikbpepple: move on++ (of course we are already over our time... but perhaps we should try to do some more things today)
warrenabadger1999: or... we include them in the initial
nottingbpepple: if they're comaintainers , they've already demonstrated enough knowledge that someone trusts them outside of their packages, so i'd count them
bpeppleyeah, I'm inclined to include co-maintainers.
nirik: do you mind if we bump your bodhi karma topic to next week?
abadger1999k.  I'll generate a list and send a link to the fesco-list.
nirikbpepple: yeah, it's all solved I think. see lmacken's post.
bpeppleabadger1999: thanks.
nirik: great.
nirikbpepple: you can remove it from the schedule.
bpeppleok, let's try to get through a few features before we wrap up. Is that alright with everyone?
btw, thanks for your time sadmac2 & abadger1999.
--- bpepple has changed the topic to: FESCo-Meeting Feature Acceptance -- https://fedoraproject.org/wiki/Features/ConnectionSharing
bpepple+1 this looks like a cool addition to NM.
notting+1. is it really 100%?
nirik+1 here.
bpepplenotting: Not sure.  Don't have rawhide on my lappy.
nirikI hope it works with wireless + EVDO.
dwmw2_HIOI hope it works with IPv6 :)
jeremydwmw2_HIO: dcantrell has been making progress on ipv6 in nm afaik.  but neither here nor there
nirikalso do some wireless cards still not do Master mode?
dwmw2_HIOmany don't
nirikbonus points for the documentation there pointing to that same page. ;)
so it should detect those that can't and not show that option.
mclasenhey, I completed the section :-)
bpepplenirik: nice.  didn't notice that.
nirikmclasen: indeed. ;)
drago01nirik: no thats why it uses IBSS (ad-hoc) and not master mode
nirikah ha. Missed that.
bpeppleok, I see 3 votes for this feature.  Anyone else want to weigh-in? warren, jeremy, spot, dwmw2_HIO
bpepplehmmm, do we only have 6 fesco members here?  That could be a problem.....
nirikspot: you still around? want to chime in?
EmpLinuxhai i am applied for ambassadors. what i have to do/
nirikmclasen: do you know if this is fully implemented in rawhide already?
mclasennirik: to my knowledge, yes
hence the 100%...
bpeppleok, it looks like we don't have a majority of members still here, so we should probably wrap up the meeting.
nirikmclasen: cool. Wonder if I can just grab NM from rawhide and try it on f9.
nirikbpepple: yeah, if we can't approve features, no point in doing them. ;(
bpepplenirik: agreed, sorta sucks.
alright, If there's nothing else let's end the meeting.
* nirik nods. ;(
* bpepple will end the meeting in 60
EmpLinux :'(
nirikperhaps we could do a special meeting early next week to just get thru features.
* bpepple will end the meeting in 30
sticksternirik: +1 fwiwi
drago01nirik: NetworkManager-0.7.0-0.10.svn3747.fc9 should have it
bpepplenirik: I'm fine with that, but it might be best to wait for the new fesco, since they will probably have a better turnout.
dwmw2_HIOwhen's the election?
nirikbpepple: when is the election over?
sticksterdwmw2_HIO: now through the 22nd.
nirikdrago01: cool. will give it a whirl.
* 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!