New package review process

[Scott Kitterman]

Late in Feisty it was agreed to move from a wiki page of needed packages to 
the current needs-packaging bugs.  Any unanticipated side effect of this was 
that we ended up trying to status new package reviews in two places: 

1.  In the LP bug
2.  In revu comments

This is inefficient and confusing.  We should have a clear standard work flow 
that has information stored in one and only one place.  Given the tools we 
have today (this is about what to do right now and separate from the UDS 
discussions about longer term strategies with tools/features that do not 
currently exist) I propose we clearly divide the work flow between LP and 
REVU as follows:

STANDARD WORKFLOW:

LP is where needs-packaging bugs are created to document the desire for or 
intent to package something.

Once someone starts working on a new package, they assign the bug to 
themselves and set status to In Progress.

Once an initial draft package is uploaded, the URL to the package on REVU is 
added to the bug in a comment and action switches to REVU. Note:  At UDS 
siretart and sistypoty hacked on REVU so it will no present a stable URL 
based on source package name so there is a stable URL to put in the 
needs-packaging bug.

Review/Comment/Advocacy of the proposed new package will be done on REVU.  
Once the New package is uploaded (and in the New queue), it is archived on 
REVU and action returns to LP.

After upload, the needs-packaging bug is set to Fix Committed and then it will 
automatically get Fix Released is (as it should be) the bug number is in 
debian/changelog.

ALTERNATIVES:

The key policy consideration that all alternatives/experiments MUST support is 
that two MOTUs must agree that the package is ready for upload.

They key workflow considerations are:

1.  There must be a link in the LP bug to where the proposed package can be 
found.
2.  MOTU advocacy must be documented.
3.  The alternative/experimental workflow MUST be clearly described as 
alternative/experimental
4.  The alternative must provide a clear source of data on the status of the 
package revu.

New Upstream Versions:

As long as the policy is that new upstream versions are uploaded to REVU, the 
same process as above (modulo bugs are upgrade bugs, not needs-packaging bugs 
and only one MOTU is required to advocate).  If there is additional 
information that is required for reviewing a new upstream version that REVU 
does not provide, then that information must be attached to the upgrade bug.

Currently desired (need to discuss making these required) are:

Diff of the Debian dirs.
Filterdiff/Interdiff of the .diff.gz of the old and new packages.

Scott K