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 -- Ubuntu-motu mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
