btw, this (uberpackager) is something we decided awhile back about in FESCo. sadmac2 merely implemented it.

dwmw2_HIO

it should be 'probation', 'packager', 'überpackager'

sadmac2

spot: bpepple is correct

spot

dwmw2_HIO: lets not paint the bikeshed

* sadmac2 searches for meeting minutes

warren

I care less what the group names are called

dwmw2_HIO

spot: there was a technical distinction there, not just the names

warren

but I think the 3 levels is a good idea.

nirik

I think the only point of contention is if 2 should have the existing cvsextras or 1 should

abadger1999

So 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

spot

bpepple: we really decided that packagers won't be able to touch things with open acls?

dwmw2_HIO

I mean, we shouldn't be moving people back from (2) to (1).

warren

it depends if packager is the lowest (probationary) level or not.

bpepple

yeah. we decided that it was easy enough for sponsors to upgrade the accounts of people that wanted access to all packages.

nirik

many current cvsextras people will not care, they only look at their own packages ever.

* spot shakes his head

warren

I think packager (former cvsextras) should be level 2.

bpepple

one moment, and let me see if I can find the minutes of the meeting we discussed this in.

nirik

warren: +1

abadger1999

1 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.

sadmac2

I 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.

I do appreciate that if it's _easy_ to move to (2) from (1) then it's mostly cosmetic

sadmac2

I'm betting 95% of maintainers won't even notice

jeremy

abadger1999: correct

dwmw2_HIO

but we want to _encourage_ participation and make people think it's easy

there are a lot of people who just wouldn't ask, unfortunately.

spot

the normal state for packagers should be uncontained

warren

Do we at least have agreement of the 3 level structure?

spot

not contained by default.

dwmw2_HIO

it's sad but true -- we exclude people just by making them ask for it

warren

dwmw2_HIO: +1

notting

i 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

sadmac2

ah, I see bpepple linked already

nirik

also, someone requesting will be more likely to use that to fix/help than someone who just happens to have it without really knowing it.

jeremy

spot: 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_HIO

notting: 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?

jeremy

nirik: that's a good point I hadn't even thought of

spot

jeremy: i'm not against new maintainer containment on a temporary basis

nirik

dwmw2_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.

spot

but i am against restricting people who get past unnecessarily

sadmac2

spot: well what's the deciding factor for who's "ready?"

dwmw2_HIO

another 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?

spot

sadmac2: i think a period of time along with the conditions that dwmw2 is describing are sufficient

abadger1999

So 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...

sadmac2

spot: 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

spot

i 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.

sadmac2

with the expectation that the worthy be promoted

abadger1999

dwmw2_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_HIO

abadger1999: any way for them to filter it differently would help. Doesn't have to be another list

sadmac2

I think the packaging system is noisy enough

dwmw2_HIO

could just be a header X-Fedora: NON MAINTAINER COMMIT BY dwmw2! You might want to check if he's broken it

nirik

abadger1999: no way to be sure... we could generate a list of them and ask...

dwmw2_HIO

that would let people highlight non-maintainer commits.

bpepple

sadmac2: +1

dwmw2_HIO

I 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

bpepple

If 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.

sadmac2

dwmw2_HIO: the individual can still say "um, no" but its expected that's rare

abadger1999

dwmw2_HIO: I think your suspicion may be correct :-(

nirik

bpepple: agreed.

dwmw2_HIO

if my suspicion _is_ correct, then we don't actually gain much by pushing people from (2) to (1) right now.

dwmw2_HIO

bpepple: yes, but we can get to a better proposal after we've talked it through and reached some form of consensus.

drago01

what about everyone can commit and only people in group "whatever" can build?

sadmac2

drago01: or tag

dwmw2_HIO

I think that would also encourage people to open up commits, yes.

nirik

the proposal's goal is to contain new maintainers... not all existing maintainers.

sadmac2

that makes cvs acls more complex

they're buckling as is....

dwmw2_HIO

build. tag. push. Or something

sadmac2

not to say we can't

abadger1999

build needs work in koji.

tag is only so so since koji will build from HEAD.

(Just scratch build, though.)

sadmac2

abadger1999: I thought koji built by tag

dwmw2_HIO

I 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.

abadger1999

sadmac2: Yes. But HEAD is a tag for this purpose.

drago01

you can commit anything and do make scratch-build

dwmw2_HIO

leaving 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)?

warren

packagers

?

dwmw2_HIO

s/packages/packagers/

warren

Does this mean we will indeed have 3 levels?

dwmw2_HIO

I think 3 levels makes sense

warren

Let'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?

drago01

rel-eng

abadger1999

two levels (third level is sort of there but hidden -- cvsadmin, secondary arch)

sadmac2

I don't think 3 is even in the scope here. It exists, we're not changing it

dwmw2_HIO

right

warren

OK, so that seems like agreement.

Now s/cvsextras/packager/ is level 1 or 2?

dwmw2_HIO

so it's really just a question of whether we move existing packages from (2) to (1) ?

notting

you typoed again

dwmw2_HIO

you should be used to it by now

drago01

packagers are just packages for dwmw2_HIO ;)

* dwmw2_HIO recompiles drago01 for powerpc

dwmw2_HIO

er, I mean ia64.

drago01

;)

dwmw2_HIO

since I'm actually sitting _in_ an Intel office right now.... :)

warren

If 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?

sadmac2

warren: its proven a pain in the ass to mess with the groups

abadger1999

warren: Not too complex.

warren

sadmac2: elaborate?

notting

i think the biggest issue with the new group is determining who goes in it to start off with

abadger1999

Need thought to make sure it works but what I'd do is:

notting

because certainly there are people in cvsextras now who probably should be there instead

sadmac2

warren: there's quite a bit of ugly hardcoded things in pkgdb

abadger1999

add all current cvsextras => uberpackager. Rename cvsextras and uberpackager as appropriate.

Should be fine.

warren

We need to come to agreement on *something*.

dwmw2_HIO

if 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

nirik

we 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_HIO

proposal: Most (if not all) existing packagers should go into group (2), which is currently called überpackager but might want renaming.

sadmac2

The 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

sadmac2

leave it alone, for all of our sake

It has a coat on it

dwmw2_HIO

whatever

proposal: Most (if not all) existing packagers should go into group (2)

warren

Shouldn'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.

nirik

how many packages do we still have with closed acls?

sadmac2

not sure

nirik

if 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?

sadmac2

part 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)

nirik

at least some of them may be happy with just new maintainers contained.

some of them may want the group of commiters to be smaller

abadger1999

nirik: 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.

warren

What are the points that we do have agreement on?

abadger1999

warren: Having a further level.

dwmw2_HIO

bpepple: feel free to put your chairman hat on and repeat my proposal in a way that makes people vote on it :)

abadger1999

warren: New maintainers go in the lowest level

dwmw2_HIO

+1, btw

abadger1999

warren: Undecided is: Where do present maintainers go? And How do we transition people from lowest level to second level?

warren

Let's decide on both now.

dividing line must be simple and imperfect so we'll actually decide now

ok, 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. ;)