Hi, first of big thanks for putting these guidelines together. It will certainly be a good hint at what reviewers can look at when doing reviews.
My fear right now with these guidelines is that these will turn to be the ultimate criteria to +1/-1 a source package and people will not check if a package is in fact good or bad but rather go through this checklist w.o. looking at the bigger picture. Well, what I've been done when reviewing (I'm a bit out of practice I must admit) was to 1) look at the .diff.gz 2) get the .orig.tar.gz in the meantime from upstream sources 3) look at suspicious files as spotted in .diff.gz, usually taking a closer look at debian/rules 4) if sane so far, do a test-build 5) look at lintian warnings of source/binaries 6) look at the actual contents of the resulting binaries and somewhere in between: 7) do a copyright check of files. This usually gave me a good impression in what shape the source package was, and usually I ended up writing comments on what needs to be improved. However I must admit, that I didn't always test the resulting package (besides piuparts), which of course I'm to blame for ;). I'm not too sure if micro-managing individual aspects will lead to better source packages in general. Nonetheless, I've tried to write everything which came to my mind for the given guidelines. Am Sonntag 11 November 2007 23:34:11 schrieb Emmet Hikory: > 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 Unclear: what is the "packaging policy" (debian-policy?) > 3. Package should be linda & lintian clean I'd rather put this to not produce unnecessary linda/lintian warnings (not all lintian warnings are equally sane imho, and I'd pretty much like people to not put in overrides to hide such warnings). > 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 [WWW] > http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-pract >ices.en.html Parts of this is outdated for Debian (Homepage, XS-Vcs), for Ubuntu as well? > > Maintenance review > 1. Package must contain a watch file or get-orig-source rule s/must/should/ > (If upstream is no more, the packager should consider adopting > the upstream package somewhere) What is wrong with using the Ubuntu archive for this? > (Packagers who implement get-orig-source for packages with > watch files get extra points) I've never found using get-orig-source to be very enlightening. For packages, where there is a .tar.gz, it's imho unnecessary (uscan handles this quite well imho), and converting e.g. .zip files to a .tar.gz looks ugly in a Makefile. > 2. Packaging scripts should be readable and readily comprehensible > 3. Upstream should be responsive, and maintain a bug tracker Checking for this adds an extra step to reviewing. Also I'm not entirely sure about the bug tracker (min12xxw, my pet package doesn't have one ;) > 4. Packaged version should be latest upstream [... with the exception of a good reason to not use 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 Erm... usually it shouldn't vary from upstream behaviour (except of course for a good reason). > 5. Package should provide a Homepage: header in debian/control > 6. Non-native packages must have verifiable cryptographic path to > upstream source Does this mean that the orig.tar.gz shouldn't differ [1]? > 7. Package must be advocated by at least two members of > ubuntu-dev (the packager may count as one) This doesn't adhere to the current new packages policy, where a MOTU is only encouraged to go through reviews, but not obliged to. > > "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. That's pretty obvious imho. Also I have a very deep aversions about any guidelines or especially language reference manuals (I'm looking at you, VHDL lrm!) which need to define what words mean. But I guess this is pretty much tied to my personal aversion to the aforementioned language reference manual. Cheers, Stefan. -- [1]: https://wiki.ubuntu.com/PackagingGuide/Basic#ChangingOrigTarball
signature.asc
Description: This is a digitally signed message part.
-- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
