At the FESCo meeting that took place on 3/6/2009, it was decided that on Monday, 3/9/2009, the 'provenpackager' group would be emptied and repopulated with only sponsors in the 'packager' group, who would be given user status in the provenpackager group. This was done for a few reasons:
1) The initial method of seeding the provenpackager group was seen by some to be arbitrary - any packager who owned 8 or more packages was admitted to the group without question. 2) Due to 1, the provenpackager group did not have the desired effect - the removal of ACL's on all but maybe a few packages.
In order for anyone else that is not currently a sponsor to be admitted to the group, a process very similar to new sponsor acceptance (however a distinct process) will be put into effect:
1) The user makes their desire to be a member of provenpackager known to FESCo (they can do this in really any way - mailing list, IRC, file a ticket, etc) 2) Much as is the process for new sponsors, a discussion will take place for 1 week on the sponsors list. 3) Based on the input from step 2, FESCo will vote on the individual in their regular meeting.
Also, any user that becomes a sponsor will also be added to the 'provenpackager' group.
It is anticipated that the volume of requests at first will be moderately large. This is expected and will be dealt with in the normal course of business.
_______________________________________________ Fedora-devel-announce mailing list Fedora-devel-announce@redhat.com https://www.redhat.com/mailman/listinfo/fedora-devel-announce
Jon Stanley wrote:
At the FESCo meeting that took place on 3/6/2009, it was decided that on Monday, 3/9/2009, the 'provenpackager' group would be emptied and repopulated with only sponsors in the 'packager' group, who would be given user status in the provenpackager group. This was done for a few reasons:
- The initial method of seeding the provenpackager group was seen by
some to be arbitrary - any packager who owned 8 or more packages was admitted to the group without question. 2) Due to 1, the provenpackager group did not have the desired effect
- the removal of ACL's on all but maybe a few packages.
In order for anyone else that is not currently a sponsor to be admitted to the group, a process very similar to new sponsor acceptance (however a distinct process) will be put into effect:
- The user makes their desire to be a member of provenpackager known
to FESCo (they can do this in really any way - mailing list, IRC, file a ticket, etc) 2) Much as is the process for new sponsors, a discussion will take place for 1 week on the sponsors list. 3) Based on the input from step 2, FESCo will vote on the individual in their regular meeting.
Also, any user that becomes a sponsor will also be added to the 'provenpackager' group.
It is anticipated that the volume of requests at first will be moderately large. This is expected and will be dealt with in the normal course of business.
Well. Here's my mail. As secondary arch maintainer (alpha), I'd like to be added to the provenpackager group - of course...
Merci, Oliver
Oliver Falk (oliver@linux-kernel.at) said:
Well. Here's my mail. As secondary arch maintainer (alpha), I'd like to be added to the provenpackager group - of course...
Assuming the alpha team has a full normal secondary arch group (and you're in it), you shouldn't need provenpackager access.
Bill
On Tue, Mar 10, 2009 at 10:47:08AM -0400, Bill Nottingham wrote:
Oliver Falk (oliver@linux-kernel.at) said:
Well. Here's my mail. As secondary arch maintainer (alpha), I'd like to be added to the provenpackager group - of course...
Assuming the alpha team has a full normal secondary arch group (and you're in it), you shouldn't need provenpackager access.
Wouldn't it be better if secondary arch group member gained their rights through the provenpackager process, instead of through another process?
And same for releng, security, and QA members?
-- Pat
On Tue, Mar 10, 2009 at 04:22:53PM +0100, Patrice Dumas wrote:
On Tue, Mar 10, 2009 at 10:47:08AM -0400, Bill Nottingham wrote:
Oliver Falk (oliver@linux-kernel.at) said:
Well. Here's my mail. As secondary arch maintainer (alpha), I'd like to be added to the provenpackager group - of course...
Assuming the alpha team has a full normal secondary arch group (and you're in it), you shouldn't need provenpackager access.
Wouldn't it be better if secondary arch group member gained their rights through the provenpackager process, instead of through another process?
And same for releng, security, and QA members?
No, because provenpackager is not at the same permission level as those.
josh
On Tue, Mar 10, 2009 at 11:34:53AM -0400, Josh Boyer wrote:
Wouldn't it be better if secondary arch group member gained their rights through the provenpackager process, instead of through another process?
And same for releng, security, and QA members?
No, because provenpackager is not at the same permission level as those.
Do you mean that they can also change packages with ACL on? Or are you referring to something else?
-- Pat
On Tue, Mar 10, 2009 at 04:46:04PM +0100, Patrice Dumas wrote:
On Tue, Mar 10, 2009 at 11:34:53AM -0400, Josh Boyer wrote:
Wouldn't it be better if secondary arch group member gained their rights through the provenpackager process, instead of through another process?
And same for releng, security, and QA members?
No, because provenpackager is not at the same permission level as those.
Do you mean that they can also change packages with ACL on? Or are you referring to something else?
None of those groups are CVS ACL groups from what I remember.
The members of some of those groups have cvsadmin, which is higher than provenpackager. Being a part of those groups does not immediately grant you cvsadmin priviledges though.
josh
On Tue, Mar 10, 2009 at 12:42:10PM -0400, Josh Boyer wrote:
None of those groups are CVS ACL groups from what I remember.
The members of some of those groups have cvsadmin, which is higher than provenpackager. Being a part of those groups does not immediately grant you cvsadmin priviledges though.
So, what I am more or less proposing is that people in these groups first try to become provenpackager and then can be in the cvsadmin group based on another process. This would certainly add more transparency, and allow to know who wants to do QA and help with security and releng. Of course there are other processes, because access in cvs is only part of the privileges needed by people in, say, releng, but access in cvs is one of the required access.
It doesn't necessarily mean that people in these groups have to be packagers, but that they follow roughly the same trust system and go through the same gates when it makes sense, as is the case for the cvs access.
-- Pat
On Tue, Mar 10, 2009 at 05:55:47PM +0100, Patrice Dumas wrote:
On Tue, Mar 10, 2009 at 12:42:10PM -0400, Josh Boyer wrote:
None of those groups are CVS ACL groups from what I remember.
The members of some of those groups have cvsadmin, which is higher than provenpackager. Being a part of those groups does not immediately grant you cvsadmin priviledges though.
So, what I am more or less proposing is that people in these groups first try to become provenpackager and then can be in the cvsadmin group based on another process. This would certainly add more transparency, and allow to know who wants to do QA and help with security and releng. Of course there are other processes, because access in cvs is only part of the privileges needed by people in, say, releng, but access in cvs is one of the required access.
That sounds somewhat reasonable.
It doesn't necessarily mean that people in these groups have to be packagers, but that they follow roughly the same trust system and go through the same gates when it makes sense, as is the case for the cvs access.
My only issue with your proposal is that it seems to imply people have magically been granted access to cvsadmin just because they are in a particular group. I haven't seen that to be the case at all.
There are only 15 people in the cvsadmin group, and each one of them has been added because they actually do cvsadmin work (as in the CVSAdmin requests for packages).
There is nobody from the QA team or Security teams in cvsadmin that I can tell.
josh
On Tue, Mar 10, 2009 at 01:13:48PM -0400, Josh Boyer wrote:
So, what I am more or less proposing is that people in these groups first try to become provenpackager and then can be in the cvsadmin group based on another process. This would certainly add more transparency, and allow to know who wants to do QA and help with security and releng. Of course there are other processes, because access in cvs is only part of the privileges needed by people in, say, releng, but access in cvs is one of the required access.
That sounds somewhat reasonable.
I am not sure, in fact. I think that the infras policies are better. It is in fact quite reasonable that I know nothing about this group, that it is not documented in the packagers part, it is for infras.
It doesn't necessarily mean that people in these groups have to be packagers, but that they follow roughly the same trust system and go through the same gates when it makes sense, as is the case for the cvs access.
My only issue with your proposal is that it seems to imply people have magically been granted access to cvsadmin just because they are in a particular group. I haven't seen that to be the case at all.
In fact I am not implying much. I thought that I missed a packager group, but in fact it is not the case.
There are only 15 people in the cvsadmin group, and each one of them has been added because they actually do cvsadmin work (as in the CVSAdmin requests for packages).
Ok. So this is very different from what I had in mind. It is more an infra issue, not necessarily relevant to go through provenpackager. But it is also clearly not the kind of group I was referring to. This is a good group for established infras people and packagers, but not for people interested in helping releng, but not already in the inner circles. People in that case should also go through the infra/releng procedures, sure, but also going through provenpackager to be able to do some releng stuff without being in the inner releng circle is what I had in mind.
There is nobody from the QA team or Security teams in cvsadmin that I can tell.
So where are they, and isn't provenpackager a good place for most of them, and maybe even higher for some (in the security group for closed ACLs)?
-- Pat
On Tue, Mar 10, 2009 at 11:34:53AM -0400, Josh Boyer wrote:
Wouldn't it be better if secondary arch group member gained their rights through the provenpackager process, instead of through another process?
And same for releng, security, and QA members?
No, because provenpackager is not at the same permission level as those.
Ok, coming back at that level of the thread, because I was lost afterwards.
What I am saying is that people interested in releng, in secondary arch, in QA, in security may want to become provenpackager even if they have not gained the trust of the inner infras/releng circles. That way they can help for stuff relevant for one of these fields without being fully involved with infras/releng. For example, fix broken deps, FTBFS, specs for build on secondary arches, do security stuff, without being formally in one of those groups.
-- Pat
Patrice Dumas wrote:
On Tue, Mar 10, 2009 at 10:47:08AM -0400, Bill Nottingham wrote:
Oliver Falk (oliver@linux-kernel.at) said:
Well. Here's my mail. As secondary arch maintainer (alpha), I'd like to be added to the provenpackager group - of course...
Assuming the alpha team has a full normal secondary arch group (and you're in it), you shouldn't need provenpackager access.
Wouldn't it be better if secondary arch group member gained their rights through the provenpackager process, instead of through another process?
And same for releng, security, and QA members?
There was a meeting at one point (I think FESCo but I could be wrong) where the cvsadmin groups was given responsibility for putting new members in cvsadmin. I believe that this technically covers all the groups except secondary arches -- who have the same powers but different groups and different responsibilities.
Just pointing out the history; not necessarily what should be.
-Toshio
On Tue, Mar 10, 2009 at 08:37:29AM -0700, Toshio Kuratomi wrote:
There was a meeting at one point (I think FESCo but I could be wrong) where the cvsadmin groups was given responsibility for putting new members in cvsadmin. I believe that this technically covers all the groups except secondary arches -- who have the same powers but different groups and different responsibilities.
Just pointing out the history; not necessarily what should be.
It is somehow odd to have a complex trust system with many levels of control (roughly packager -> provenpackager -> sponsor) for contributors that have less power, while there is no apparent control/procedure for the cvsadmin group. At least people having cvsadmin powers granted should be provenpackagers, and maybe cvsadmin members could be identified and something about them could be added in the policies pages, be it only a mention to an informal process to become cvsadmin.
-- Pat
On Tue, Mar 10, 2009 at 06:04:38PM +0100, Patrice Dumas wrote:
On Tue, Mar 10, 2009 at 08:37:29AM -0700, Toshio Kuratomi wrote:
There was a meeting at one point (I think FESCo but I could be wrong) where the cvsadmin groups was given responsibility for putting new members in cvsadmin. I believe that this technically covers all the groups except secondary arches -- who have the same powers but different groups and different responsibilities.
Just pointing out the history; not necessarily what should be.
It is somehow odd to have a complex trust system with many levels of control (roughly packager -> provenpackager -> sponsor) for contributors that have less power, while there is no apparent control/procedure for the cvsadmin group. At least people having cvsadmin powers granted should be provenpackagers, and maybe cvsadmin members could be identified and something about them could be added in the policies pages, be it only a mention to an informal process to become cvsadmin.
To answer to myself, now that I stand corrected, cvsadmin is outside of the packager trust system, and in the infras trust system, so it is right as is (more precisely I don't have an opinion on it).
-- Pat
Jon Stanley wrote:
At the FESCo meeting that took place on 3/6/2009, it was decided that on Monday, 3/9/2009, the 'provenpackager' group would be emptied and repopulated with only sponsors in the 'packager' group, who would be given user status in the provenpackager group.
Is there some definition of what a "provenpackager role" is supposed to mean and how it is different from a "sponsor role"?
Ralf
On Tue, Mar 10, 2009 at 09:36:01AM +0100, Ralf Corsepius wrote:
Jon Stanley wrote:
At the FESCo meeting that took place on 3/6/2009, it was decided that on Monday, 3/9/2009, the 'provenpackager' group would be emptied and repopulated with only sponsors in the 'packager' group, who would be given user status in the provenpackager group.
Is there some definition of what a "provenpackager role" is supposed to mean and how it is different from a "sponsor role"?
provenpackagers are people who can change all the packages with opened ACLs. Sponsors are the people who can accept new contributors in fedora.
-- Pat
Patrice Dumas wrote:
On Tue, Mar 10, 2009 at 09:36:01AM +0100, Ralf Corsepius wrote:
Jon Stanley wrote:
At the FESCo meeting that took place on 3/6/2009, it was decided that on Monday, 3/9/2009, the 'provenpackager' group would be emptied and repopulated with only sponsors in the 'packager' group, who would be given user status in the provenpackager group.
Is there some definition of what a "provenpackager role" is supposed to mean and how it is different from a "sponsor role"?
provenpackagers are people who can change all the packages with opened ACLs. Sponsors are the people who can accept new contributors in fedora.
<devil's advocate>
Well, with this definition, "provenpackager" is an acknowledgment of "technical skills", while "sponsors" is a "social/political role".
It also doesn't have any connection to the role "sponsors" once used to have: To guide and educate new-comer packagers.
<devil's advocate>
Ralf
On Tue, 10 Mar 2009 11:19:13 +0100, Ralf wrote:
<devil's advocate>
Well, with this definition, "provenpackager" is an acknowledgment of "technical skills",
This isn't clear to me yet. Package rebuilds in Rawhide don't need "technical skills". It's trivial to bump Release and submit build requests. Unless the person who does that also creates patches and modifies packages beyond ordinary rebuild attempts. In that case, however, I wonder where the maintainers of such packages are? Or perhaps the task of rebuilding is considered as grunt work, and the maintainers explicitly give their okay in private mail (or on IRC)?
What I'd like to avoid is that some people step in and hide non-responsive maintainers by updating and upgrading packages without being an official co-maintainer (or by rebuilding packages in Rawhide without taking care of open bugzilla tickets).
Understanding what exactly the "provenpackager" membership is used for would be helpful.
while "sponsors" is a "social/political role".
Sounds questionable. In particular since sponsors must review packages of a contributor they want to sponsor.
On Tue, Mar 10, 2009 at 11:41:50AM +0100, Michael Schwendt wrote:
On Tue, 10 Mar 2009 11:19:13 +0100, Ralf wrote:
Understanding what exactly the "provenpackager" membership is used for would be helpful.
Maybe things have changed, but my understanding was that provenpackager would be the "Experienced packagers" referred to on:
http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModify...
which also lays out what provenpackagers are allowed to do.
-- Pat
On Tue, 10 Mar 2009 11:57:31 +0100, Patrice wrote:
Maybe things have changed, but my understanding was that provenpackager would be the "Experienced packagers" referred to on:
http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModify...
which also lays out what provenpackagers are allowed to do.
=:-o 1st of April is still weeks away.
Why is there an exception for "Red Hat packagers"?
| Definition of the term "Experienced packagers" | | [...] | | Red Hat packagers that have been through a number of reviews and | have been packagers for more than 4 months.
On Tue, Mar 10, 2009 at 12:03:00PM +0100, Michael Schwendt wrote:
On Tue, 10 Mar 2009 11:57:31 +0100, Patrice wrote:
Maybe things have changed, but my understanding was that provenpackager would be the "Experienced packagers" referred to on:
http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModify...
which also lays out what provenpackagers are allowed to do.
=:-o 1st of April is still weeks away.
Why is there an exception for "Red Hat packagers"?
| Definition of the term "Experienced packagers" | | [...] | | Red Hat packagers that have been through a number of reviews and | have been packagers for more than 4 months.
It was added at that time to include experienced Red Hat packagers coming from core who weren't sponsors. Now Red Hat packagers in that position should be provenpackagers.
-- Pat
Michael Schwendt wrote:
What I'd like to avoid is that some people step in and hide non-responsive maintainers by updating and upgrading packages without being an official co-maintainer (or by rebuilding packages in Rawhide without taking care of open bugzilla tickets).
I think the important part is that someone does the work, whether officially the maintainer or not.
If Bugzilla tickets are being ignored, the non-responsive maintainer process should be started for those, independently of whether some rebuilds for broken dependencies by non-maintainers happened or not. If the broken dependencies were the only issue, then having anyone, no matter whom, fix them solves the problem.
Kevin Kofler
On Tue, Mar 10, 2009 at 11:19:13AM +0100, Ralf Corsepius wrote:
Patrice Dumas wrote:
provenpackagers are people who can change all the packages with opened ACLs. Sponsors are the people who can accept new contributors in fedora.
<devil's advocate>
Well, with this definition, "provenpackager" is an acknowledgment of "technical skills", while "sponsors" is a "social/political role".
That's not that clear, since sponsors also have to help their sponsoree on a technical level, and have to evaluate the technical skills of potential contributors which also imply some level of technical skill. But indeed, the sponsor evaluates potential new contributors, while the provenpackager fixes other people packages.
It also doesn't have any connection to the role "sponsors" once used to have: To guide and educate new-comer packagers.
It is in the definition of sponsors, but I wanted to make it short. In more length they are the people who can accept new contributors in fedora and guide and educate them.
-- Pat
On Tue, 10 Mar 2009 11:42:12 +0100, Patrice wrote:
On Tue, Mar 10, 2009 at 11:19:13AM +0100, Ralf Corsepius wrote:
Patrice Dumas wrote:
provenpackagers are people who can change all the packages with opened ACLs. Sponsors are the people who can accept new contributors in fedora.
<devil's advocate>
Well, with this definition, "provenpackager" is an acknowledgment of "technical skills", while "sponsors" is a "social/political role".
That's not that clear, since sponsors also have to help their sponsoree on a technical level, and have to evaluate the technical skills of potential contributors which also imply some level of technical skill. But indeed, the sponsor evaluates potential new contributors, while the provenpackager fixes other people packages.
?? "some level of technical skill"? As every sponsor becomes a member of the provenpackager group, what capabilities are provenpackagers missing, that they don't simply become sponsors?
On Tue, Mar 10, 2009 at 12:17:50PM +0100, Michael Schwendt wrote:
?? "some level of technical skill"? As every sponsor becomes a member of the provenpackager group, what capabilities are provenpackagers missing, that they don't simply become sponsors?
People interested in security, release engineering, other arches are typically suited for provenpackager role, and not necessarily for sponsor role. Also people who likes to fix others packages, but don't want to be sponsor... Though this should be quite rare.
-- Pat
On Tue, 10 Mar 2009 12:24:29 +0100, Patrice wrote:
On Tue, Mar 10, 2009 at 12:17:50PM +0100, Michael Schwendt wrote:
?? "some level of technical skill"? As every sponsor becomes a member of the provenpackager group, what capabilities are provenpackagers missing, that they don't simply become sponsors?
People interested in security, release engineering, other arches are typically suited for provenpackager role, and not necessarily for sponsor role. Also people who likes to fix others packages, but don't want to be sponsor... Though this should be quite rare.
You've misunderstood my question. With the current process, sponsors need not demonstrate anything beyond technical skills (= packaging skills in form of a couple of package reviews).
On Tue, Mar 10, 2009 at 12:57:05PM +0100, Michael Schwendt wrote:
You've misunderstood my question. With the current process, sponsors need not demonstrate anything beyond technical skills (= packaging skills in form of a couple of package reviews).
I don't think so. The process of sponsor selection is mostly ad-hoc. It is FESCo choice, in the end, and technical skill doesn't have to be the sole motivation of FESCo: http://fedoraproject.org/wiki/How_to_sponsor_a_new_contributor#Becoming_a_Fe...
Quoting:
When someone within the project has developed a "good reputation" (and this is admittedly a somewhat fuzzy definition!) then someone else will generally nominate them for sponsor status. .... A discussion and vote will then occur during the next Fedora Engineering Steering Committee meeting.
-- Pat
Hi,
a) I'd like to self-nominate myself as a Fedora Packager Sponsor.
b) I'd like to become member of provenpackager group.
The application under b) is redundant, unless the processing of b) takes significantly less time than the processing of a).
<ramblings>
- The user makes their desire to be a member of provenpackager known
to FESCo (they can do this in really any way - mailing list, IRC, file a ticket, etc)
What list, what IRC, where to file the ticket?
All I found was an information on wiki that sponsors nominations can be sent to fedora-devel-list. (Allegedly, one can also send mail to FESCo, but I were not able to find out the address.) </rambligs>
<apology> I'm really sorry to bother all the readers of fedora-devel-list, but I felt I should re-gain my provenpackager status and was not able to find a better async method. </apology>
Have a nice day, Stepan
On Tue, Mar 10, 2009 at 10:49:26AM +0100, Stepan Kasal wrote:
Hi,
a) I'd like to self-nominate myself as a Fedora Packager Sponsor.
b) I'd like to become member of provenpackager group.
The application under b) is redundant, unless the processing of b) takes significantly less time than the processing of a).
<ramblings> > 1) The user makes their desire to be a member of provenpackager known > to FESCo (they can do this in really any way - mailing list, IRC, file > a ticket, etc)
What list, what IRC, where to file the ticket?
All I found was an information on wiki that sponsors nominations can be sent to fedora-devel-list. (Allegedly, one can also send mail to FESCo, but I were not able to find out the address.)
</rambligs>
The address is fedora-extras-steering <at> redhat.com
There is a FESCo trac instance with tickets at:
https://fedorahosted.org/fesco/
josh
On Tue, 10 Mar 2009, Josh Boyer wrote:
What list, what IRC, where to file the ticket?
All I found was an information on wiki that sponsors nominations can be sent to fedora-devel-list. (Allegedly, one can also send mail to FESCo, but I were not able to find out the address.)
</rambligs>
The address is fedora-extras-steering <at> redhat.com
There is a FESCo trac instance with tickets at:
Does the apply button on the provenpackager group page on admin.fedoraproject.org go to the right place? That'd be another good off-list method if it does
https://admin.fedoraproject.org/accounts/group/view/provenpackager
later, chris
On Tue, Mar 10, 2009 at 9:36 AM, Chris Ricker kaboom@oobleck.net wrote:
Does the apply button on the provenpackager group page on admin.fedoraproject.org go to the right place? That'd be another good off-list method if it does
It goes to all of the FESCo members, so yeah. I've forwarded your request on already :)
Jon Stanley wrote:
On Tue, Mar 10, 2009 at 9:36 AM, Chris Ricker kaboom@oobleck.net wrote:
Does the apply button on the provenpackager group page on admin.fedoraproject.org go to the right place? That'd be another good off-list method if it does
It goes to all of the FESCo members, so yeah.
Is this the right thing to do?
Why isn't the community of sponsors`involved?
Ralf
On Tue, Mar 10, 2009 at 11:08:22PM +0100, Kevin Kofler wrote:
Josh Boyer wrote:
The address is fedora-extras-steering <at> redhat.com
Note that there's one annoyance: the list is moderated, so everything you send there gets held for moderation before it's actually sent out to FESCo.
This is true. The trac instance is not (and sends email to the list).
josh
-
Bill Nottingham -
Chris Ricker -
Jon Stanley -
Josh Boyer -
Kevin Kofler -
Michael Schwendt -
Oliver Falk -
Patrice Dumas -
Ralf Corsepius -
Stepan Kasal -
Toshio Kuratomi