Currently our cvsadmin request template looks like:
New Package CVS Request ======================= Package Name: Short Description: Owners: Branches: InitialCC: Cvsextras Commits:
To me this looks like you have to opt /in/ to Cvsextras Commits, and I'm not sure what will happen if you don't fill in a value.
Could we word it in such a way that as a requester you'd have to explicitly opt out of of having open acls.
I don't have suggested phrasing in mind just yet, but I wondered if folks were open to the change.
On Di Dezember 4 2007, Jesse Keating wrote:
Currently our cvsadmin request template looks like:
Cvsextras Commits:
To me this looks like you have to opt /in/ to Cvsextras Commits, and I'm not sure what will happen if you don't fill in a value.
Could we word it in such a way that as a requester you'd have to explicitly opt out of of having open acls.
I don't have suggested phrasing in mind just yet, but I wondered if folks were open to the change.
One could prefil the template with "yes", then one has to remove it or change it to "no" to opt out.
Regards, Till
On Tue, 4 Dec 2007 16:36:25 -0500 jkeating@redhat.com (Jesse Keating) wrote:
Currently our cvsadmin request template looks like:
New Package CVS Request
Package Name: Short Description: Owners: Branches: InitialCC: Cvsextras Commits:
To me this looks like you have to opt /in/ to Cvsextras Commits, and I'm not sure what will happen if you don't fill in a value.
Could we word it in such a way that as a requester you'd have to explicitly opt out of of having open acls.
I don't have suggested phrasing in mind just yet, but I wondered if folks were open to the change.
I think thats a fine idea, perhaps it could be something like:
New Package CVS Request ================= Required Fields:
Package Name: Short Description: Owners:
Optional Fields:
Branches: (defaults to devel only) InitialCC: (defaults to none, NOTE that owners are automatically cc'ed or assigned bugs, there is never a need to add owners to this field) Cvsextras Commits: (defaults to yes).
Further note that all usernames must be in Fedora Account System names, not email address.
kevin
Jesse Keating wrote:
To me this looks like you have to opt /in/ to Cvsextras Commits, and I'm not sure what will happen if you don't fill in a value.
Could we word it in such a way that as a requester you'd have to explicitly opt out of of having open acls.
I don't have suggested phrasing in mind just yet, but I wondered if folks were open to the change.
I think open by default is reasonable. For those packages that want tighter control perhaps "Private Commits" would be good wording.
On Tue, 2007-12-04 at 17:10 -0500, Todd Zullinger wrote:
I think open by default is reasonable.
I agree.
For those packages that want tighter control perhaps "Private Commits" would be good wording.
It would be nice if you also needed to give a _good_ reason for making it private. Perhaps even a reason which is approved by FESCo in advance.
On 05.12.2007 13:02, David Woodhouse wrote:
On Tue, 2007-12-04 at 17:10 -0500, Todd Zullinger wrote:
I think open by default is reasonable.
I agree.
I disagree for packages that have at least one co-maintainer.
For those packages that want tighter control perhaps "Private Commits" would be good wording.
It would be nice if you also needed to give a _good_ reason for making it private. Perhaps even a reason which is approved by FESCo in advance.
"I fear that a just sponsored contributer puts something bad in one of my packages" and "the CTRL+C trick in CVS still works, thus I as maintainer might not even get a mail if someone changes my package(¹)" are the reasons why I excluded cvsextras for those of my packages that have co-maintainers.
OTOH I think we IMHO should have a group in FAS called something like "experienced maintainers" with sponsors and long term contributers that gets access everywhere; I trust those way more then a just-sponsored contributer that came out of the blue.
CU knurd
(¹) -- not to mention that we are all AFK now and then for a few days
Hi,
On Wed, 2007-12-05 at 13:25 +0100, Thorsten Leemhuis wrote:
On 05.12.2007 13:02, David Woodhouse wrote:
On Tue, 2007-12-04 at 17:10 -0500, Todd Zullinger wrote:
I think open by default is reasonable.
I agree.
I disagree for packages that have at least one co-maintainer.
Definitely makes some sense. Packages that have a more maintainer are more likely to deserve all the love they deserve compared to ones who get to Fedora from Core and have a single maintainer with cvsextras off by default (I've seen a maintainer of ex-Core package that was not even aware that noone else but him can commit).
For those packages that want tighter control perhaps "Private Commits" would be good wording.
It would be nice if you also needed to give a _good_ reason for making it private. Perhaps even a reason which is approved by FESCo in advance.
"I fear that a just sponsored contributer puts something bad in one of my packages" and "the CTRL+C trick in CVS still works, thus I as maintainer might not even get a mail if someone changes my package(¹)" are the reasons why I excluded cvsextras for those of my packages that have co-maintainers.
Why would he put something bad? Being malicious? He can do that in different places also when he has a FAS account, is in cvsextras and can build packages. Being not experienced enough? That's the purpose he has a sponsor for. (btw that CTRL+C thing should get fixed, is there an infra ticket for it?)
OTOH I think we IMHO should have a group in FAS called something like "experienced maintainers" with sponsors and long term contributers that gets access everywhere; I trust those way more then a just-sponsored contributer that came out of the blue.
I'd say all sponsored people are "experienced maintainers". Those who are not experienced do post their work in bugzilla. At least I think of sponsorship should serve exactly this purpose, if you believe it is not, then it is unuseful and have to be dealt with somehow. If we solved that by separating the group further, we may end up with something like "extra most super experienced maintainers" groups.
Thanks,
On 05.12.2007 13:59, Lubomir Kundrak wrote:
On Wed, 2007-12-05 at 13:25 +0100, Thorsten Leemhuis wrote:
On 05.12.2007 13:02, David Woodhouse wrote:
On Tue, 2007-12-04 at 17:10 -0500, Todd Zullinger wrote:
For those packages that want tighter control perhaps "Private Commits" would be good wording.
It would be nice if you also needed to give a _good_ reason for making it private. Perhaps even a reason which is approved by FESCo in advance.
"I fear that a just sponsored contributer puts something bad in one of my packages" and "the CTRL+C trick in CVS still works, thus I as maintainer might not even get a mail if someone changes my package(¹)" are the reasons why I excluded cvsextras for those of my packages that have co-maintainers.
Why would he put something bad? Being malicious?
Yes. Sure, for most people the hurdle is likely to high to go that route, but OTOH it a great way to get bad code out to lots of systems quickly (and a way to ruin our fame)
He can do that in different places also when he has a FAS account, is in cvsextras and can build packages.
Not exactly sure what you mean. His own packages? Sure, that's easy. But as a malicious person I'd would likely take a popular package that more users have installed *if* I have access to it.
Being not experienced enough? [...]
We all make errors now and then. IOW: no, I didn't mean that.
(btw that CTRL+C thing should get fixed, is there an infra ticket for it?)
There was one in bugzilla iirc; then there was one in OTRS and someone looked into it, but it didn't get fixed; then infrastructure switched to something else, and there is no current ticket I'm aware off.
OTOH I think we IMHO should have a group in FAS called something like "experienced maintainers" with sponsors and long term contributers that gets access everywhere; I trust those way more then a just-sponsored contributer that came out of the blue.
I'd say all sponsored people are "experienced maintainers".
So someone that just baked his first spec file in his life, got it reviewed, himsel sponsored and the spec file imported is directly "experienced"?
/me wonders if we are confusing the terms "sponsored people" and "sponsors"
Those who are not experienced do post their work in bugzilla. At least I think of sponsorship should serve exactly this purpose, if you believe it is not, then it is unuseful and have to be dealt with somehow. If we solved that by separating the group further, we may end up with something like "extra most super experienced maintainers" groups.
Sure, but OTHO it's black (no access) and white (access everywhere) might be a over simplification. Three or maybe four contributer-levels (access to his own packages, access everywhere, sponsors, admins) IMHO would be better and not that complicated.
Cu knurd
Why would he put something bad? Being malicious?
Yes. Sure, for most people the hurdle is likely to high to go that route, but OTOH it a great way to get bad code out to lots of systems quickly (and a way to ruin our fame)
Linux has been mostly immune to malware. For anyone writing malware one of the challenges is propagating the infected code.
So lets not give bad folks the perfect vehicle for distributing their malware through an official update channel which automatically gets pushed to tens of thousands of machines with the implication of being clean software. Such an event would be devastating to the entire open source community.
If one doesn't think this is going to happen or you think the ultimate consequences for open source adoption would be benign then I have a bridge I'd like to sell you.
Also, if you think the bar to getting a Fedora account is so high as to make this unlikely then you've forgotten that anyone with enough software savvy to write malware would view that hurdle as a house of straw.
If you think there aren't plenty of folks the world over just waiting for their 15 minutes of hacker fame or who have a desire to teach RedHat/Fedora a lesson then I can offer you a discount on that bridge.
Do we need a better mechanism for accepting contributions from the community, probably. Are open commit lists the answer, no.
If you think the problem would be mitigated by package maintainers rigorously reviewing all changes *after* they've been committed you're forgetting human nature and the fact most maintainers are over worked to begin with. By extension if you demand maintainers review every commit then how is that effectively different than the current process of posting a patch in a bugzilla and asking the maintainer to review it before committing it?
On Wed, 05 Dec 2007 09:29:41 -0500 John Dennis jdennis@redhat.com wrote:
Linux has been mostly immune to malware. For anyone writing malware one of the challenges is propagating the infected code.
So lets not give bad folks the perfect vehicle for distributing their malware through an official update channel which automatically gets pushed to tens of thousands of machines with the implication of being clean software. Such an event would be devastating to the entire open source community.
If one doesn't think this is going to happen or you think the ultimate consequences for open source adoption would be benign then I have a bridge I'd like to sell you.
Also, if you think the bar to getting a Fedora account is so high as to make this unlikely then you've forgotten that anyone with enough software savvy to write malware would view that hurdle as a house of straw.
If you think there aren't plenty of folks the world over just waiting for their 15 minutes of hacker fame or who have a desire to teach RedHat/Fedora a lesson then I can offer you a discount on that bridge.
Do we need a better mechanism for accepting contributions from the community, probably. Are open commit lists the answer, no.
If you think the problem would be mitigated by package maintainers rigorously reviewing all changes *after* they've been committed you're forgetting human nature and the fact most maintainers are over worked to begin with. By extension if you demand maintainers review every commit then how is that effectively different than the current process of posting a patch in a bugzilla and asking the maintainer to review it before committing it?
And if you think we're the first Linux distro of any size to have wider access to our software source control you're also mistaken. We're not paving new ground here.
Debian has NMUs which allow for a Debian maintainer other than the package owner to upload new builds of a package for various reasons: http://www.us.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu
Ubuntu has a "Development Team" that have commit access across all the Universe packages, and a "Core Development Team" that has access to the packages in main. This is a lot more like what we used to have, with Core/Extras, but it still gives pretty wide commit access to a number of people. Just as dangerous as what you're worried about.
"Open"Suse is a different story. Only Novell employees can maintain opensuse packages. However they have a buildservice which allows just about anybody to build software and publish in a public repo. YaST has clickable links to a number of popular repos.
So we're hardly the first, and certainly not the largest, linux distro to have "open" commits for project members.
On 05.12.2007 16:10, Jesse Keating wrote:
On Wed, 05 Dec 2007 09:29:41 -0500 John Dennis jdennis@redhat.com wrote:
Linux has been mostly immune to malware. For anyone writing malware one of the challenges is propagating the infected code.
So lets not give bad folks the perfect vehicle for distributing their malware through an official update channel which automatically gets pushed to tens of thousands of machines with the implication of being clean software. Such an event would be devastating to the entire open source community.
[...]
If you think the problem would be mitigated by package maintainers rigorously reviewing all changes *after* they've been committed you're forgetting human nature and the fact most maintainers are over worked to begin with. By extension if you demand maintainers review every commit then how is that effectively different than the current process of posting a patch in a bugzilla and asking the maintainer to review it before committing it?
And if you think we're the first Linux distro of any size to have wider access to our software source control you're also mistaken. We're not paving new ground here.
[... some examples ....]
So we're hardly the first, and certainly not the largest, linux distro to have "open" commits for project members.
So your option as FESCo member is what? Just continue with the current procedure and hope and pray that nothing happens?
For me something like the ubuntu solution ("Development Team" that have commit access across all the Universe packages) sounds good -- we could create such a team by putting sponsors, rel-eng-people and some hand selected red hat employees as well as some long term contributers into a "group" and call them "Development Team" as well.
CU knurd
On Wed, 05 Dec 2007 16:30:10 +0100 Thorsten Leemhuis fedora@leemhuis.info wrote:
For me something like the ubuntu solution ("Development Team" that have commit access across all the Universe packages) sounds good -- we could create such a team by putting sponsors, rel-eng-people and some hand selected red hat employees as well as some long term contributers into a "group" and call them "Development Team" as well.
The only difference between the ubuntu "developer" team and cvsextras membership is we seem a lot more eager to hand out sponsorships. If we were less eager to hand it out, then we'd have that "team".
An alternative that has been talked about before, which I see some value in, is that a new group is created, cvsnewbies if you will, and members of those groups only have access to the packages they own. They over time can be promoted to cvspkgs or cvsextras or whatever we're going to call it. Insert some criteria for promotion here.
At the end of the day, I just want our package set to be accessible to as many people as possible instead of locked away from as many people as possible.
Having just looked a bit closer and talked with Jeremy, here is what I think we can do.
"cvsextras" as a FAS group becomes something like just 'cvspkgs'. Warren is already planning on doing this. Membership in this group gives you a couple things.
1) file level ACLs on the cvs server to write to the file system. Everybody has to have this in order for cvs to write out files on your behalf.
2) A grouping of all Fedora package maintainers. All maintainers would have to be in cvspkgs.
We would then create a new group, cvsexperienced or some other name such as this. This group is the group that gets CVS ACLs to all modules that haven't opted out of this openness. This takes the place of what we have in pkgdb currently as cvsextras commit. Entry to this group should be relatively low barrier, but there is still a barrier between the fresh contributors and everybody elses packages.
Finally we have the cvsadmin group who just has blanket access no matter what, and this doesn't have to change.
With some relatively small changes this could be accomplished. The interesting discussion points are A) what is the criteria to get added to cvsexperienced? Obviously sponsors are automatically added, but there should be other ways to get in. B) who from the current members of cvsextras would we grandfather into cvsexperienced? C) what is a better name for "cvsexperienced". D) when to make this happen.
On Wed, 5 Dec 2007 10:41:20 -0500 Jesse Keating jkeating@redhat.com wrote:
Having just looked a bit closer and talked with Jeremy, here is what I think we can do.
"cvsextras" as a FAS group becomes something like just 'cvspkgs'. Warren is already planning on doing this. Membership in this group gives you a couple things.
- file level ACLs on the cvs server to
write to the file system. Everybody has to have this in order for cvs to write out files on your behalf.
- A grouping of all Fedora package maintainers. All maintainers
would have to be in cvspkgs.
We would then create a new group, cvsexperienced or some other name such as this. This group is the group that gets CVS ACLs to all modules that haven't opted out of this openness. This takes the place of what we have in pkgdb currently as cvsextras commit. Entry to this group should be relatively low barrier, but there is still a barrier between the fresh contributors and everybody elses packages.
Finally we have the cvsadmin group who just has blanket access no matter what, and this doesn't have to change.
With some relatively small changes this could be accomplished. The interesting discussion points are A) what is the criteria to get added to cvsexperienced? Obviously sponsors are automatically added, but there should be other ways to get in. B) who from the current members of cvsextras would we grandfather into cvsexperienced? C) what is a better name for "cvsexperienced". D) when to make this happen.
I forgot to mention. Membership in cvspkgs does not give you wide access. In fact, the members of cvspkgs are not "considered" when creating CVS ACLs. The owners/co-maintainers of packages are, and members of cvsexperienced are (provided the package in question allows for cvsexperienced commit access).
This effectively keeps new packagers to only A) the packages they own, and B) the packages the co-maintain with other people.
On 05.12.2007 16:51, Jesse Keating wrote:
On Wed, 5 Dec 2007 10:41:20 -0500 Jesse Keating jkeating@redhat.com wrote:
Having just looked a bit closer and talked with Jeremy, here is what I think we can do.
In general: looks good. But it's actually quite similar that was purposed in a older discussion not that many months ago but not further realized because then I was told that having a second group in FAS is not that easy to realize for this task.
"cvsextras" as a FAS group becomes something like just 'cvspkgs'. Warren is already planning on doing this. Membership in this group gives you a couple things.
- file level ACLs on the cvs server to
write to the file system. Everybody has to have this in order for cvs to write out files on your behalf.
- A grouping of all Fedora package maintainers. All maintainers
would have to be in cvspkgs.
We would then create a new group, cvsexperienced or some other name such as this. This group is the group that gets CVS ACLs to all modules that haven't opted out of this openness. This takes the place of what we have in pkgdb currently as cvsextras commit. Entry to this group should be relatively low barrier, but there is still a barrier between the fresh contributors and everybody elses packages.
With this words it sounds to me like a bit to low barrier, but that depends on the exact definition.
Finally we have the cvsadmin group who just has blanket access no matter what, and this doesn't have to change.
With some relatively small changes this could be accomplished. The interesting discussion points are A) what is the criteria to get added to cvsexperienced? Obviously sponsors are automatically added, but there should be other ways to get in.
IMHO is the barrier should be something like "invested quite some work into Fedora (something like: maintained 8 packages or did a lot of other work in Fedora-land and is around for more then 3 or 6 months)" and "showed that be knows the packaging guidelines"; IOW: can be trusted.
But something like that is not easily written down. I think FESCo (or some other group; the sponsors maybe?) should just approve people if they trust them. And people should have a reasons to get that access; we should not simply hand it out accoring to some static rules.)
B) who from the current members of cvsextras would we grandfather into cvsexperienced?
I'd say only sponsors, people around for a long time (two years maybe?) or with a lot of packages (more then 12 maybe?) and are active.
C) what is a better name for "cvsexperienced".
cvstrusted ?
D) when to make this happen.
E) how to maintain that group, as people become inactive or leave over time again.
I forgot to mention. Membership in cvspkgs does not give you wide access. In fact, the members of cvspkgs are not "considered" when creating CVS ACLs. The owners/co-maintainers of packages are, and members of cvsexperienced are (provided the package in question allows for cvsexperienced commit access).
This effectively keeps new packagers to only A) the packages they own, and B) the packages the co-maintain with other people.
CU knurd
Jesse Keating wrote:
An alternative that has been talked about before, which I see some value in, is that a new group is created, cvsnewbies if you will, and members of those groups only have access to the packages they own. They over time can be promoted to cvspkgs or cvsextras or whatever we're going to call it. Insert some criteria for promotion here.
Refer
http://www.debian.org/vote/2007/vote_003
Rahul
Jesse Keating wrote:
On Wed, 05 Dec 2007 09:29:41 -0500 John Dennis jdennis@redhat.com wrote:
Linux has been mostly immune to malware. For anyone writing malware one of the challenges is propagating the infected code.
So lets not give bad folks the perfect vehicle for distributing their malware through an official update channel which automatically gets pushed to tens of thousands of machines with the implication of being clean software. Such an event would be devastating to the entire open source community.
If one doesn't think this is going to happen or you think the ultimate consequences for open source adoption would be benign then I have a bridge I'd like to sell you.
Also, if you think the bar to getting a Fedora account is so high as to make this unlikely then you've forgotten that anyone with enough software savvy to write malware would view that hurdle as a house of straw.
If you think there aren't plenty of folks the world over just waiting for their 15 minutes of hacker fame or who have a desire to teach RedHat/Fedora a lesson then I can offer you a discount on that bridge.
Do we need a better mechanism for accepting contributions from the community, probably. Are open commit lists the answer, no.
If you think the problem would be mitigated by package maintainers rigorously reviewing all changes *after* they've been committed you're forgetting human nature and the fact most maintainers are over worked to begin with. By extension if you demand maintainers review every commit then how is that effectively different than the current process of posting a patch in a bugzilla and asking the maintainer to review it before committing it?
And if you think we're the first Linux distro of any size to have wider access to our software source control you're also mistaken. We're not paving new ground here.
Debian has NMUs which allow for a Debian maintainer other than the package owner to upload new builds of a package for various reasons: http://www.us.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu
Only Debian Developers can do NMUs. Last I checked the process of becoming a Debian Developer was roughly an order of magnitude more rigorous than ours (and possibly to the extent of being beyond reason).
Can't comment on the rest of the distros.
Zack
On Wed, 05 Dec 2007 13:17:02 -0500 Zack Cerza zcerza@redhat.com wrote:
Only Debian Developers can do NMUs.
Right, we're not talking about just having anonymous cvs commit access. You'd have to be a Fedora developer.
Jesse Keating wrote:
On Wed, 05 Dec 2007 13:17:02 -0500 Zack Cerza zcerza@redhat.com wrote:
Only Debian Developers can do NMUs.
Right, we're not talking about just having anonymous cvs commit access. You'd have to be a Fedora developer.
Sure, I'm just pointing out that it's easier to get access to Fedora than to Debian.
On Wed, Dec 05, 2007 at 09:29:41AM -0500, John Dennis wrote:
If you think the problem would be mitigated by package maintainers rigorously reviewing all changes *after* they've been committed you're forgetting human nature and the fact most maintainers are over worked to begin with. By extension if you demand maintainers review every commit then
I completly disagree with that. If a packager is not capable of reviewing everything that goes through for his package then something is definitely wrong. Either the packager should orphan the package or ask for co-maintainership but should never let something happen without noticing.
how is that effectively different than the current process of posting a patch in a bugzilla and asking the maintainer to review it before committing it?
It is different, not the same workflow. It seems to me that, for example, it is very time saving to have someone change the spec, ask a mail for rebuild, without going through bugzilla. Still the package maintainer has to understand enough every patch (or trust the other contributor enough after review).
(As a side note I personally think that rebuilds/publishing should not be open while cvs should be.) It is more or less the case given that there is bodhi for stable, but for rawhide it is not the case.
-- Pat
On 05.12.2007 16:27, Patrice Dumas wrote:
On Wed, Dec 05, 2007 at 09:29:41AM -0500, John Dennis wrote:
If you think the problem would be mitigated by package maintainers rigorously reviewing all changes *after* they've been committed you're forgetting human nature and the fact most maintainers are over worked to begin with. By extension if you demand maintainers review every commit then
I completly disagree with that. If a packager is not capable of reviewing everything that goes through for his package then something is definitely wrong. Either the packager should orphan the package or ask for co-maintainership but should never let something happen without noticing.
Well, with the CTRL+C bug you might not get a mail if someone changed something.
And if we like it or not, I bet we have packagers that just delete CVS commit mails to their packages when they come home after a three weeks holiday and find > 20.000 mails in their inbox. I think that's bad, but that's how some humans are sometimes afaics.
It is different, not the same workflow. It seems to me that, for example, it is very time saving to have someone change the spec, ask a mail for rebuild, without going through bugzilla. Still the package maintainer has to understand enough every patch (or trust the other contributor enough after review).
+1
(As a side note I personally think that rebuilds/publishing should not be open while cvs should be.) It is more or less the case given that there is bodhi for stable, but for rawhide it is not the case.
Yes and no. With the current CTRL+C bug someone else might commit something bad to a package owned by someone else. Sooner or later the real owner might do a fresh checkout (something some people do regularly instead of having a local checkout), do another change, build and push.
Cu knurd
On Mi Dezember 5 2007, Thorsten Leemhuis wrote:
Yes and no. With the current CTRL+C bug someone else might commit something bad to a package owned by someone else. Sooner or later the real owner might do a fresh checkout (something some people do regularly instead of having a local checkout), do another change, build and push.
An scm that supports signing commits / repository contens would help here, because one could easily check whether the checked out contents are trusted. Or this there an easy way with cvs to show the last author of every source file? Looking through "cvs log" is not an easy solution here.
Regards, Till
On Dec 5, 2007 5:29 AM, John Dennis jdennis@redhat.com wrote:
Do we need a better mechanism for accepting contributions from the community, probably. Are open commit lists the answer, no.
I floated a mentor status idea for new contributors. Something equivalent to me bringing in a contributor such that they get commit access to an explicit set of packages that I watch over so that I am on the hook for their commiting behavior. They don't get to push to builds to repositories (they can do scratch builds) and I vouch for them until such time they have a track record of right action to obtain full sponsorship.
My understanding was that our acl's are setup to allow this sort of thing yet. And it help if I could make sure forced re-tagging was disabled for them as well.
-jef
On Wed, Dec 05, 2007 at 01:59:16PM +0100, Lubomir Kundrak wrote:
I'd say all sponsored people are "experienced maintainers". Those who are not experienced do post their work in bugzilla. At least I think of sponsorship should serve exactly this purpose, if you believe it is not, then it is unuseful and have to be dealt with somehow. If we solved that by separating the group further, we may end up with something like "extra most super experienced maintainers" groups.
That already exists, see (especially at the end) http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModify...
-- Pat