From Fedora Project Wiki

m (remove top headers to make TOC fit better on page, switch comments page to talk page like it should be, add category)
(this policy got updated on docs.fp.o, so I removed the old content)
 
(22 intermediate revisions by 15 users not shown)
Line 1: Line 1:
In the past, every regular Fedora packager having more than 5 packages (as maintainer) was able to request and get uberpackager, the later called provenpackager. This automagic way later got changed into manual FAS requests which can be approved by provenpackager (sponsors).
{{admon/important|This page is deprecated| FESCo docs have moved to [https://docs.fedoraproject.org/en-US/fesco/ docs.fp.o] with source hosted in a [https://pagure.io/fesco/fesco-docs pagure repo]. This page is now at https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/.}}
 
Currently only a single provenpackager (sponsor) is required in order to successfully sponsor a FAS request of a "regular" packager. This makes very easily slipping people in, that don't have that much experience and knowledge, a provenpackager (sponsor) should have.
 
Normally, the provenpackager sponsor verifies whether it is clever to sponsor the FAS request or not, but if two people know each other on personal base, it is very easy, that a not advanced or less knowledged person maybe gets a provenpackager - a think, which shouldn't happen.
 
Fedora currently has around 800 packagers, around 150 are provenpackagers - that's a lot. I can't imagine for myself, that we really have so many advanced and knowledged packagers, when having a look how some package reviews are done, how packages are maintained or some package touchings are performed. Of course I'm referring here to individual cases I'm aware about, maybe some partiality of myself.
 
== Solution Overview ==
Not just a single approval by a provenpackager (sponsor) should be required, but the approval of multiple ones.
 
== Scope ==
Not just a single approval by a provenpackager (sponsor) should be required, but the approval of multiple ones; maybe a voting or collecting karma points. What I definately don't like to see is a voting where provenpackagers are bothered e.g. via e-mail or similar in order to vote for a new FAS request.
 
What I'm imaging is more or less the following scenario: A regular packager wants to get a provenpackager, thus he performs a FAS request for that. The provenpackagers maybe then notified, that a new provenpackager request went in as it currently is also the case, but that's optional. Provenpackagers now have a list in FAS with the person requesting provenpackager and can set a karma of -1/0/+1.
 
The scheme is similar to Bodhi, +15 karma points are required to get provenpackager. If a provenpackager doesn't vote or abstains, it's +/- 0, the default. And if a provenpackager is against the request, he can set -1. Provenpackagers are only allowed to give one vote/karma point in total, but should be able to change their mind later. If somebody makes to early a provenpackager request, it can be denied by setting -1, but if the person gets more and more involved by time, more knowledged and so on, it can be changed +1 afterwards.
 
Maybe it's a clever thing here, to use the karma points as well to downgrade a person easily, if something goes horrible wrong. As minds and thinkings of provenpackagers (sponsors) can change, people can change as well and it would be inacceptable, if we can't revert a provenpackager same easy as we got one. So if the karma goes down below +15 karma points again, the person is degraded to a "regular" packager and loosing all provenpackager permissions. That idea/possibility should prevent us from getting harmed very easy.
 
This proposal makes necessary, that the current uberpackager/provenpackager list is completely reset and we're starting with an empty one having no legacy entries as we currently have.
 
Asking or requiring more than a single person for a new provenpackager (and keeping that status) also ensures, that the person is somehow known to the Fedora community or at least to the packagers, is showing there up and is involved into processes already and knows how the wind blows. But the current situation is, that all of this is only "verified" by a single person (sponsor) and can't be reverted afterwards same easily without making much noise.
 
= Discussion Points =
The number of karma points/votings which has to be required by provenpackager sponsors in order to get a provenpackager: Personally, I'm tending to 15 or even more positive points, but if really needed we can lower that to 10 positive points. That means, 10 provenpackager (sponsors) would have to accept the request of the "regular" packager using +1, and this seems to be a reasonable amount for me.
 
== Comments? ==
Please place your comments, ideas and suggestions on [[Talk:PackageMaintainers/ProvenpackagerProposal|the talk page]].
 
[[Category:Package Maintainers]]

Latest revision as of 23:31, 1 May 2019

This page is deprecated
FESCo docs have moved to docs.fp.o with source hosted in a pagure repo. This page is now at https://docs.fedoraproject.org/en-US/fesco/Provenpackager_policy/.