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.
