Attract QA'ers (was: Re: k3b fedora.us reviews or new maintainer wanted!)

[Warren Togami]

Erik LaBianca wrote:
> 
> There may be some benefit to relaxing the 2-review requirement until
> critical mass is achieved. I think it's important not to get too caught
> up in "policy" and "quality" arguments when it's obvious that the rate
> of approval is so low. Here and now is probably the place for the
> discussion.

Lowering the bar to one untrusted reviewer would be extremely dangerous. 
  One aspect of the seemingly tough QA process has been to keep out a 
lot of crap software, or crappily packaged software.  I would be more 
comfortable with people like you who have tried extremely hard, but not 
someone brand new to the project and a complete unknown to me.

NOTE: BELOW IS CURRENTLY ONLY WHAT I PERSONALLY HAVE IN MIND RIGHT NOW. 
  PLEASE COMMENT.

The idea I am thinking now for when fedora.redhat.com runs the Extras 
project is to have the "Trusted" ones who have proven loyalty, 
trustworthiness, and cluefulness who become "lieutenants" who approve 
submissions made by less trusted people.  This bar would be lower in 
pedantic process for update/fixes submissions for existing packages, but 
it MUST be more difficult than this to add a new package.  (Read the 
bottom of this message for more about this.)

The initial set of lieutenants from the community would number in the 
two dozen or higher range, including the existing fedora.us team and 
other high profile packagers & upstream developers.  Individual 
lieutenants would have CVS ACL commit access only to parts of the tree 
that they have proven cluefulness, as determined by the leadership and 
past track record in QA fixes/reviews.  Everyone else who needs to prove 
themselves would submit to a QA queue in Bugzilla, and the lieutenants 
with access to various subsystems must commit these submissions.

Packages may have a single or multiple maintainer(s).  While even more 
people may have commit access to any given package, the package 
maintainer(s) have final say about what they allow within any given 
package.  (Well the leadership can veto things too, but this would 
happen extremely rarely only for legal or technical breakage reasons.)

Contributors would be nominated by the existing set of lieutenants and 
approved by leadership.  Developers heavily involved with upstream 
projects (e.g. ESR and fetchmail) would of course be assigned access to 
that package.  Best judgement will be used to give commit access to 
people who have proven themselves to the community.  (After an Apache 
contributor-like legal form is signed & faxed.)

Yes, this entire idea above is not very different from the existing 
fedora.us process for new unknown contributors.  It will however 
dramatically lower overhead for trusted developers and scale extremely well.

The hierarchy would be something like this:
Leaders
Lieutenants
	- Commit access to a subset of the entire repository.
Package maintainers
	- Commit access to the package that they maintain.
	- Proven track record with that package, or upstream developer
Triage/QA Reviewers/Contributors
	- Untrusted people can do many things that save lieutenant/maintainer 
time by consolidating reports, killing duplicates, and submitting fixes. 
  This is the ONLY WAY other than being a high profile upstream 
developer to gain package maintainer or eventually lieutenant status.

This suggested new package inclusion process will still be a problem for 
experimental/academic programming languages and other stuff that very 
few people other than the packager actually cares about.  In order to 
solve this problem of "nobody else cares", I would suggest a lowered-bar 
set of requirements something like:

1) The package must be in QA (retroactively from fedora.us is OK) for a 
minimum of 2 months.
2) The package exact sources must have been present in Debian testing or 
Mandrake cooker/contrib for at least those 2 months.
3) Spec must pass visual inspection of the QA checklist, and package 
should build on all target Extras architectures.
4) This package must have NO CHANCE of interfering with other installed 
software.
5) Runtime verification by another individual is NOT needed.  The above 
requirements should give us a margin of safety in not importing trojaned 
sources.  Safety should be the priority and we don't care if the 
software actually works at first.
6) Since nobody else reviewed that package, fedora-devel-list must be 
warned one week before inclusion that it is happening.  During this 
period the package can be vetoed for any good reason by anybody.
7) After inclusion, that packager would probably obtain CVS commit 
access to that package.  Subsequent fixes either go through that 
packager, or another lieutenant with comnmit access.