Interim New Package Process

[Warren Togami]

(Until we can agree on a better process with better tools, I propose 
this simple process to operate Extras at least during the next 2 weeks. 
  I really think this process is horrible, but we need SOMETHING to work 
from rather than unwritten rules for the short-term.  We will be arguing 
about details for the final process between now and FUDCON.)


Contibutor Levels (jargon needed to understand the process below)
=================
(Highest) "Trusted" or RH FC Engineer
	These people can sponsor "Contributor" membership, where they take 
responsibility for the new member to have full CVS access.  These 
members can veto (or stall) "Contributor" nominations or new package 
additions and force a discussion, vote, or something.  (Currently 
everyone with CVS access is also "Trusted", but that may quickly change 
as we accept many more members in the coming weeks.)

(Middle) "Contributor"
	These members can sponsor new package additions and act as 
intermediaries for those who do not yet have CVS access.  Contributors 
have full CVS access but are expected to respect package ownership. 
These members can veto (or stall) new package additions if there is good 
technical reason.

(Lowest) "Packager"
	These members own packages in Extras but are not sponsored.  They can 
get CVS access to their own packages.  Their goal is to show competency 
and hard work in order earn trust so someone will sponsor them.  (We may 
not be able to create Packager status accounts until the database driven 
account management system goes into production.)


Interim Extras Package Process
------------------------------
I. NEW PACKAGES
---------------
You can add a new package if it meets these requirements:
* Another Extras Contributor or RH engineer (but not yourself) to 
sponsor your package.
* No known legal/licensing problems.
* Nobody vetos it.

II. IMPORT TO CVS
==================
Use cvs-import.sh from the common module.  If you do not have CVS 
access, then convince a package sponsor to checkin for you.  That 
package sponsor is probably the same person who does the package review.

III. PACKAGE REVIEW
====================
Package should comply with most of the packaging best practices (yet to 
be rewritten) so it is of reasonably good quality.  This is FAR LESS 
than strict QA requirements of fedora.us.  Judgement of the reviewer of 
"good enough".  Package quality can be fixed AFTER import but before build.

In most cases it would be safe to push a less than certain package, and 
use resulting testing to fix it quickly and push again.  However if it 
would endanger existing users, or other packages, then don't do this. 
Again up to the judgement of the reviewer.

IV. ANNOUNCE
-------------
After a package has been reviewed, post to
fedora-extras-commits at redhat.com with
Subject "APPROVED: packagefoo, packagebar, packagebaz..."
Body should contain package names, short descriptions, who reviewed, and 
who will maintain those packages.

(This is so we can easily search where a package came from, and who
reviewed it.)

V. CREATE BUGZILLA COMPONENT
=============================
http://fedoraproject.org/wiki/Extras_2fFC3Status
Edit this page and add a request for a new Bugzilla component.  Include
1) Package name
2) Description (from Summary field)
3) Bugzilla account e-mail address of package owner

For example:
foommoorpg:Totally Awesome and Free 3D Online RPG Game:bob at somewhere.net
foommoorpg-data:9GB of Data for Foo MMORPG:bob at somewhere.net
footrainer:Cheating Program for Foo MMORPG:bob at somewhere.net

VI. REQUEST BUILD
=================
http://fedoraproject.org/wiki/Extras_2fFC3Status
Edit this page and add your package to the "build needed" section.

For example:
* foommoorpg (i386, x86_64)
   * foommoorpg-data (noarch)
* footrainer (i386, x86_64)
* fooutil (i386 only)

VII. UPDATES
==========
Just do it, or funnel it through the package sponsor if you don't have 
CVS access yet.

Warren Togami
wtogami at redhat.com