---

CategoryMOTURedirect

REVU Requirements Proposal

Overview

The list of conditions which a package should meet prior to receiving advocation for upload does not appear to be documented clearly and publicly. If such a list were available, with documentation of applicable review tests, this should reduce requirements for repeated reviews, as packagers would be able to make standards tests prior to upload, and those interested in becoming reviewers could more easily learn the review process and reject / advocate packages without worry as to whether the review was adequate.

Proposed Review Goals

1. Review of the packaging of the package
2. Review of packaging maintainability
3. Review suitability of the application for the archive

Proposed Review Guidelines

• Packaging review

  1. Package must meet Ubuntu versioning & Maintainer requirements

  2. Package must match current Ubuntu (and Debian) packaging policies

  3. Package should be linda & lintian clean

  4. Contents of debian/ should be sane
  5. Package must build, install, run, remove, and purge cleanly
  6. Changelog should close a "needs-packaging" bug

  7. Package should follow http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html

• Maintenance review
  1. Package must contain a watch file or get-orig-source rule
     • If upstream is no more, the packager should consider adopting the upstream package somewhere
     • Packages who implement get-orig-source for packages with watch files get extra points
  2. Packaging scripts should be readable and readily comprehensible
  3. Upstream should be responsive, and maintain a bug tracker
  4. Packaged version should be latest upstream
  5. Packaged version must not have any known security or critical bugs
  6. Package should not be native without an approved spec
• Suitability review
  1. Package should work on a standard Ubuntu/Kubuntu/Xubuntu/etc. system
  2. Package must meet copyright / licensing requirements
  3. Package should provide hints to system services (app-install-data, menus, etc.) to ease installation
  4. Package should provide Ubuntu-specific documentation for variances in behaviour from upstream
  5. Package should provide a Homepage: header in debian/control
  6. Non-native packages must have verifiable cryptographic path to upstream source
  7. Package must be advocated by at least two members of ubuntu-dev (the packager may count as one)

must, as used above, indicates that a package not meeting that test is not appropriate for inclusion in the archive.

should, as used above, indicates that the reviewer should explicitly agree to the variance from the condition prior to advocating the package for inclusion in the archive.

Proposed Implementation

The above guidelines change is independent of tools, and does not require any changes to REVU, Launchpad, or any new systems under consideration. Further, the guidelines should support any new system as long as that system can provide 1) a candidate diff.gz, 2) a means by which developers can approve / reject while adding commentary, and 3) a means by which developers can coordinate to reduce wait times for the double advocation requirement. Motivated developers are encouraged to create scripts to automate some of the tests above for possible inclusion in ubuntu-dev-tools.

The above guidelines, if approved, would be published on the Wiki, with links from the following sources:

• The packaging guide
• The reviewing guide
• The MOTU Contributing gateway
• The documentation on new package inclusion

• A posting to ubuntu-motu@l.u.c

Planned Discussion

• The adoption of the above guidelines will be reviewed at the MOTU Meeting for 5th November, 2007. If this page remains considerably after that date, please review the minutes of that meeting to determine if it applies to current reviews.

---

["CategoryMOTURedirect"]

REVU Requirements Proposal

Overview

The list of conditions which a package should meet prior to receiving advocation for upload does not appear to be documented clearly and publicly. If such a list were available, with documentation of applicable review tests, this should reduce requirements for repeated reviews, as packagers would be able to make standards tests prior to upload, and those interested in becoming reviewers could more easily learn the review process and reject / advocate packages without worry as to whether the review was adequate.

Proposed Review Goals

1. Review of the packaging of the package
2. Review of packaging maintainability
3. Review suitability of the application for the archive

Proposed Review Guidelines

• Packaging review

  1. Package must meet Ubuntu versioning & Maintainer requirements

  2. Package must match current Ubuntu (and Debian) packaging policies

  3. Package should be linda & lintian clean

  4. Contents of debian/ should be sane
  5. Package must build, install, run, remove, and purge cleanly
  6. Changelog should close a "needs-packaging" bug

  7. Package should follow http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-practices.en.html

• Maintenance review
  1. Package must contain a watch file or get-orig-source rule
     • If upstream is no more, the packager should consider adopting the upstream package somewhere
     • Packages who implement get-orig-source for packages with watch files get extra points
  2. Packaging scripts should be readable and readily comprehensible
  3. Upstream should be responsive, and maintain a bug tracker
  4. Packaged version should be latest upstream
  5. Packaged version must not have any known security or critical bugs
  6. Package should not be native without an approved spec
• Suitability review
  1. Package should work on a standard Ubuntu/Kubuntu/Xubuntu/etc. system
  2. Package must meet copyright / licensing requirements
  3. Package should provide hints to system services (app-install-data, menus, etc.) to ease installation
  4. Package should provide Ubuntu-specific documentation for variances in behaviour from upstream
  5. Package should provide a Homepage: header in debian/control
  6. Non-native packages must have verifiable cryptographic path to upstream source
  7. Package must be advocated by at least two members of ubuntu-dev (the packager may count as one)

must, as used above, indicates that a package not meeting that test is not appropriate for inclusion in the archive.

should, as used above, indicates that the reviewer should explicitly agree to the variance from the condition prior to advocating the package for inclusion in the archive.

Proposed Implementation

The above guidelines change is independent of tools, and does not require any changes to REVU, Launchpad, or any new systems under consideration. Further, the guidelines should support any new system as long as that system can provide 1) a candidate diff.gz, 2) a means by which developers can approve / reject while adding commentary, and 3) a means by which developers can coordinate to reduce wait times for the double advocation requirement. Motivated developers are encouraged to create scripts to automate some of the tests above for possible inclusion in ubuntu-dev-tools.

The above guidelines, if approved, would be published on the Wiki, with links from the following sources:

• The packaging guide
• The reviewing guide
• The MOTU Contributing gateway
• The documentation on new package inclusion

• A posting to ubuntu-motu@l.u.c

Planned Discussion

• The adoption of the above guidelines will be reviewed at the MOTU Meeting for 5th November, 2007. If this page remains considerably after that date, please review the minutes of that meeting to determine if it applies to current reviews.