Emmet Hikory wrote: > Reviewers and Packagers, > > At the recent MOTU Meeting, a set of guidelines for new package > review was reviewed. This list is meant to supplement reviewers base > opinions when reviewing packages, and provide for a relatively stable > set of criteria when packagers are deciding if their packages should > be uploaded to REVU. Please keep these guidelines in mind when either > packaging new software or reviewing candidates for upload. The > guidelines are broken into three separated goal-oriented sections, as > follows: > > 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
While I find there guidelines really appropriate, I would like to propose
another point:
4b. Contents of diff.gz should be in debian/. i.e. no inline patching.
I say this because I looked yesterday at wxwidgets2.6 merge. And it was really
difficult for me, since a) patches were applied inline in the source and b) it
was a native package, so I didn't have a diff.gz to look for our patches. So I
would propose that inline patching is only allowed for SRUs and Security
updates. Of course if the package isn't native it will have the changes in the
diff.gz, but anyway that's not ideal.
What do you guys think about it?
Cheers,
Emilio
> 5. Package must build, install, run, remove, and purge cleanly
> 6. Changelog should close a "needs-packaging" bug
> 7. Package should follow [WWW]
> 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)
> (Packagers 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 and use
> 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.
>
> These guidelines are subject to change, as Ubuntu packaging
> practices develop. The current set of recommended guidelines is
> available from https://wiki.ubuntu.com/UbuntuDevelopment/CodeReviews
>
signature.asc
Description: OpenPGP digital signature
-- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
