We don't currently have guidelines for granting access to proven packager. I took a work item from FESCo to create a draft for this, and here is my first stab at it (words in camelcase exist to be replaced with links to pages concerning them):
Provenpackager is a group of highly skilled package maintainers who are experienced in a wide variety of package types and who are intimately familiar with the PackagingGuidelines and MaintainerPolicies as well as acutely aware of ReleaseSchedules and FreezePolicies. They exist as a group to lend a hand when help is needed, always with a desire to improve the quality of Fedora. By granting membership into provenpackager for a maintainer you are confirming that at least in your mind they meet the above criteria and that you would trust them fully with any of the packages you either maintain or even just use.
On Sat, 24 Jan 2009 07:47:52 -0800 Jesse Keating jkeating@redhat.com wrote:
We don't currently have guidelines for granting access to proven packager. I took a work item from FESCo to create a draft for this, and here is my first stab at it (words in camelcase exist to be replaced with links to pages concerning them):
Thanks for working on this!
Provenpackager is a group of highly skilled package maintainers who are experienced in a wide variety of package types and who are intimately familiar with the PackagingGuidelines and MaintainerPolicies as well as acutely aware of ReleaseSchedules and FreezePolicies. They exist as a group to lend a hand when help is needed, always with a desire to improve the quality of Fedora. By granting membership into provenpackager for a maintainer you are confirming that at least in your mind they meet the above criteria and that you would trust them fully with any of the packages you either maintain or even just use.
That sounds good to me.
We might also want to mention and/or revisit/cleanup: http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModify... now as well.
kevin
2009/1/24 Kevin Fenzi kevin@scrye.com:
We might also want to mention and/or revisit/cleanup: http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModify... now as well.
Keep in mind that we haven't done the actual reseeding yet, IIRC. I'll draft the announcement to f-d-a about it.
"KF" == Kevin Fenzi writes:
KF> On Sat, 24 Jan 2009 07:47:52 -0800 KF> Jesse Keating jkeating@redhat.com wrote:
We don't currently have guidelines for granting access to proven
packager. I took a work item from FESCo to create a draft for this, and here is my first stab at it (words in camelcase exist to be replaced with links to pages concerning them):
KF> Thanks for working on this!
Provenpackager is a group of highly skilled package maintainers who are experienced in a wide variety of package types and who are intimately familiar with the PackagingGuidelines and MaintainerPolicies as well as acutely aware of ReleaseSchedules and FreezePolicies. They exist as a group to lend a hand when help is needed, always with a desire to improve the quality of Fedora. By granting membership into provenpackager for a maintainer you are confirming that at least in your mind they meet the above criteria and that you would trust them fully with any of the packages you either maintain or even just use.
KF> That sounds good to me.
KF> We might also want to mention and/or revisit/cleanup: KF> http://fedoraproject.org/wiki/PackageMaintainers/Policy/WhoIsAllowedToModify... KF> now as well.
So is provenpackager going to be reseeded with sponsors only? If that is so, I'll lose my current ability to fix packages as I am not a sponsor at this time. I have particularly focused on fixing broken deps in rawhide (my pet peeve, especially close to releases) for the last few release cycles and I hope my work has been useful.
I thought the initial way of seeding the list (i.e. maintainers with a large number of packages) was fine, were there any cases where people passed this threshold and then went abused (inadvertantly or otherwise) their ability to commit and build a larger number of packages?
I fear that if the bar for provenpackager is raised too high (i.e. only sponsors) and requires too many hoops to jump through to get in, then my motivation to work on Fedora will be severely curtailed and I suspect there may be others. Please individually consider the work of the maintainers in the current provenpackager list have been doing before removing them en-masse.
Related to this, it seems that there are still maintainers who appear to want to lock up their packages even from "provenpackager". As a concrete example, user "rezso" (I've requested him to re-open them in private e-mail to no avail) locked down several of his packages such as:
http://admin.fedoraproject.org/pkgdb/packages/name/mapserver http://admin.fedoraproject.org/pkgdb/packages/name/mapnik http://admin.fedoraproject.org/pkgdb/packages/name/gdal
These are packages that regularly needs to be rebuilt when sonames are bumped and frequently lies dormant in a "broken deps" state for weeks at a time and would benefit being available to provenpackagers to rebuild. (It's currently broken right now because of the MySQL soname bump and there's no good reason why it shouldn't be available for provenpackager to fix it).
Alex
Alex Lancaster wrote:
So is provenpackager going to be reseeded with sponsors only? If that is so, I'll lose my current ability to fix packages as I am not a sponsor at this time. I have particularly focused on fixing broken deps in rawhide (my pet peeve, especially close to releases) for the last few release cycles and I hope my work has been useful.
I'm a sponsor now, and AFAIK sponsors in packager will also be sponsors in provenpackager, so I'll sponsor you into provenpackager (if somebody else isn't quicker than me ;-) ). You've done great work fixing broken deps, you really deserve being in provenpackager!
Kevin Kofler
Alex Lancaster wrote:
Related to this, it seems that there are still maintainers who appear to want to lock up their packages even from "provenpackager". As a concrete example, user "rezso" (I've requested him to re-open them in private e-mail to no avail) locked down several of his packages such as:
http://admin.fedoraproject.org/pkgdb/packages/name/mapserver http://admin.fedoraproject.org/pkgdb/packages/name/mapnik http://admin.fedoraproject.org/pkgdb/packages/name/gdal
These are packages that regularly needs to be rebuilt when sonames are bumped and frequently lies dormant in a "broken deps" state for weeks at a time and would benefit being available to provenpackagers to rebuild. (It's currently broken right now because of the MySQL soname bump and there's no good reason why it shouldn't be available for provenpackager to fix it).
+1
There's an open ticket at FESCo to look into abuse of provenpackager lockout, I really hope they'll look into this soon.
Kevin Kofler
On Sun, 2009-01-25 at 17:15 +0100, Kevin Kofler wrote:
+1
There's an open ticket at FESCo to look into abuse of provenpackager lockout, I really hope they'll look into this soon.
This reseeding is in fact part of the result of that looking into. The provenpackager group being too big and filled with people who maintain an arbitrary amount of packages was a big reason why some folks didn't open their packages. By rebooting the group with people we've already had a human review of, and then supplying guidelines for those people to bring more into the group, we can keep the group to just those that genuinely want to help, and have had some human trust level applied.
On Sun, 2009-01-25 at 04:37 -0700, Alex Lancaster wrote:
So is provenpackager going to be reseeded with sponsors only? If that is so, I'll lose my current ability to fix packages as I am not a sponsor at this time. I have particularly focused on fixing broken deps in rawhide (my pet peeve, especially close to releases) for the last few release cycles and I hope my work has been useful.
The new plan is to re-seed, however once seeded, the criteria I mentioned will be used by those people to bring more into the group, people who actually want the elevated access rather than getting it by happenstance of having a few packages.
This serves another goal, addressing one of the reasons why people claimed they didn't feel comfortable opening their packages to provenpackager, the group was too haphazardly created.
As Kevin states, there shouldn't be difficulty in getting yourself back into proven packager, you have proven yourself.
On Sat, 24 Jan 2009, Jesse Keating wrote:
We don't currently have guidelines for granting access to proven packager. I took a work item from FESCo to create a draft for this, and here is my first stab at it (words in camelcase exist to be replaced with links to pages concerning them):
Some time ago, I had a discussion with Kevin and Jason - but I'm not really sure currently, as it already was late night. Maybe somebody can correct me here if, I'm wrong.
Well, I was unhappy about the uberpackager/provenpackager situation and that it is too easy to get this status. Ideas resulting of the discussion has been, that uberpackagers/provenpackagers more should be some kind of mentors and to help packagers when needed and requested. Yes, that's more or less currently already case, but I had more the mentor thing in mind.
Uberpackagers/provenpackagers should be persons well known to the community and having some presence at packagers. So a person only having 5 packages gets a uberpackager/provenpackager, something really goes wrong IMHO. Yes, we've changed that, but we should not make the status depend on packages or some time at all, but on presence and knowledge of the person.
The other thing is, which is much more important, that not a single person can sponsor a uberpackager/provenpackager. I was thinking about some kind of "voting". Of course not a voting that kind, that all current sponsors are getting notified via e-mail, but the possibility, that every sponsor can add +1/0/-1 in FAS to a guy wanting to get uberpackager/provenpackager. And if "charma" of that candidate is +5 or +10 in the end, the guy gets uberpackager/provenpackager. If a sponsor is doing nothing, it's just +0/ -0, but the sponsors should not get bothered about each request of a new candidate.
Anyway for that we IMHO must reset the current uberpackager/provenpackager list and restart with an empty one. Otherwise that doesn't make sense to me and it doesn't change nor solve our problems we introduced in the past...
Greetings, Robert
On Sun, 2009-01-25 at 16:23 +0100, Robert Scheck wrote:
Uberpackagers/provenpackagers should be persons well known to the community and having some presence at packagers. So a person only having 5 packages gets a uberpackager/provenpackager, something really goes wrong IMHO. Yes, we've changed that, but we should not make the status depend on packages or some time at all, but on presence and knowledge of the person.
That's who we're starting the group with, the current package sponsors. People whom we trust to bring new contributors into the packager group, we're now also going to trust them to bring new packagers into the provenpackager group.
The other thing is, which is much more important, that not a single person can sponsor a uberpackager/provenpackager. I was thinking about some kind of "voting". Of course not a voting that kind, that all current sponsors are getting notified via e-mail, but the possibility, that every sponsor can add +1/0/-1 in FAS to a guy wanting to get uberpackager/provenpackager. And if "charma" of that candidate is +5 or +10 in the end, the guy gets uberpackager/provenpackager. If a sponsor is doing nothing, it's just +0/ -0, but the sponsors should not get bothered about each request of a new candidate.
Interesting thought, I'd like to see a full proposal brought to FESCo over this matter.
Anyway for that we IMHO must reset the current uberpackager/provenpackager list and restart with an empty one. Otherwise that doesn't make sense to me and it doesn't change nor solve our problems we introduced in the past...
We're starting with the existing group of people who have already been vetted by FESCo, that is the current sponsors.
On Sun, 25 Jan 2009, Jesse Keating wrote:
Interesting thought, I'd like to see a full proposal brought to FESCo over this matter.
Done so far. Can you please add
https://fedoraproject.org/wiki/PackageMaintainers/ProvenpackagerProposal
to the agenda for the next FESCo meeting? Currently it's a proposal which surely needs love until it maybe can get a policy. Thank you.
Greetings, Robert
On Sat, 24 Jan 2009 07:47:52 -0800 Jesse Keating jkeating@redhat.com wrote:
We don't currently have guidelines for granting access to proven packager. I took a work item from FESCo to create a draft for this, and here is my first stab at it (words in camelcase exist to be replaced with links to pages concerning them):
Provenpackager is a group of highly skilled package maintainers who are experienced in a wide variety of package types and who are intimately familiar with the PackagingGuidelines and MaintainerPolicies as well as acutely aware of ReleaseSchedules and FreezePolicies. They exist as a group to lend a hand when help is needed, always with a desire to improve the quality of Fedora. By granting membership into provenpackager for a maintainer you are confirming that at least in your mind they meet the above criteria and that you would trust them fully with any of the packages you either maintain or even just use.
We sort have stalled out on this.
I think the above is great, but the open question is who applies the above guideline to folks requesting membership in provenpackager.
Robert had a proposal for this, but FESCo didn't like it. ;(
I would like to propose several possible options and ask for feedback on them:
A) Provenpackager sponsors are set to FESCo members and RELENG members. They apply the above guideline and approve people into the group. (This would be a smaller pool of people than C below).
B) Provenpackagers submit a request to FESCo and are voted on in meetings and approved by a majority vote. Note that this doesn't scale too well if there are a lot of requests.
C) Provenpackager sponsors are set to the same as Sponsors in the packager group. Anyone in that pool can apply the above guideline and approve someone into the group.
Anyone have other proposals or like/dislike any of these? We need to get this finished.
kevin
Kevin Fenzi wrote:
On Sat, 24 Jan 2009 07:47:52 -0800 Jesse Keating jkeating@redhat.com wrote:
We don't currently have guidelines for granting access to proven packager. I took a work item from FESCo to create a draft for this, and here is my first stab at it (words in camelcase exist to be replaced with links to pages concerning them):
Provenpackager is a group of highly skilled package maintainers who are experienced in a wide variety of package types and who are intimately familiar with the PackagingGuidelines and MaintainerPolicies as well as acutely aware of ReleaseSchedules and FreezePolicies. They exist as a group to lend a hand when help is needed, always with a desire to improve the quality of Fedora. By granting membership into provenpackager for a maintainer you are confirming that at least in your mind they meet the above criteria and that you would trust them fully with any of the packages you either maintain or even just use.
We sort have stalled out on this.
I think the above is great, but the open question is who applies the above guideline to folks requesting membership in provenpackager.
Robert had a proposal for this, but FESCo didn't like it. ;(
I would like to propose several possible options and ask for feedback on them:
A) Provenpackager sponsors are set to FESCo members and RELENG members. They apply the above guideline and approve people into the group. (This would be a smaller pool of people than C below).
B) Provenpackagers submit a request to FESCo and are voted on in meetings and approved by a majority vote. Note that this doesn't scale too well if there are a lot of requests.
C) Provenpackager sponsors are set to the same as Sponsors in the packager group. Anyone in that pool can apply the above guideline and approve someone into the group.
Anyone have other proposals or like/dislike any of these? We need to get this finished.
I like (B) the best. This is with the idea that the number of provenpackagers would be similar to the number of sponsors.
If provenpackagers is supposed to be a larger group then (C) seems like the only one that's going to scale well.
-Toshio
-
Alex Lancaster -
Jesse Keating -
Jon Stanley -
Kevin Fenzi -
Kevin Kofler -
Robert Scheck -
Toshio Kuratomi