Re: Guidelines for reviewing new packages.
Hi, Am Samstag 17 November 2007 05:57:18 schrieb Emmet Hikory: > On Nov 17, 2007 5:52 AM, Stefan Potyra <[EMAIL PROTECTED]> wrote: > > 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. > > That's a good point. My motivations in drafting this was to 1) > make it easier for packagers to pre-review, 2) provide a common set of > tests for packages, as I think we all have slightly different > practices with reviewing. I guess having a different set of practices when reviewing is usually a good thing, as it will lead to different errors being found. Of course there should be some common minimal standard for reviewing, and I think these guidelines will help providing this. Thanks again for getting this started! [..] > > > 2. Package must match current Ubuntu (and Debian) packaging > > > policies > > > > Unclear: what is the "packaging policy" (debian-policy?) > > This is an interesting point. debian-policy often receives > updates after a practice has been supported by all available tools for > some time, and has been adopted by a wide number of packages. Ubuntu > packaging policies seem scattered on the Ubuntu wiki, and some > additional Debian policies (e.g. python, perl, java, etc.) see > likewise scattered (although often on the Debian wiki). I'd welcome > any suggestions on how to rephrase this to indicate that the relevant > policies should be reviewed, and the package checked for compliance. Maybe by giving examples afterwards? S.th. like this: "2. Package must match current Ubuntu (and Debian) packaging policies (i.e. Debian policy, relevant packaging policies like the python, perl or java policy, ubuntu maintainer field spec etc.) > > > > 7. Package should follow [WWW] > > > http://www.debian.org/doc/manuals/developers-reference/ch-best-pkging-p > > >ract ices.en.html > > > > Parts of this is outdated for Debian (Homepage, XS-Vcs), for Ubuntu as > > well? > > True. Perhaps this should be dropped? Not too sure, there are some good bits there as well. *shrug* > > > > (If upstream is no more, the packager should consider adopting > > > the upstream package somewhere) > > > > What is wrong with using the Ubuntu archive for this? > > Many REVU packages seem to be of the upload-and-forget variety, Right, that's what my guess is as well. However if seen counter-examples likewise and I'd right to see a way to get some indication about this (e.g. looking at all packages that made it through revu for upload activity, bug counts or s.th. like it), but that's a different topic... > and the edges of universe don't always receive strong maintenance. My > fear is that we'll have more unmaintained and dead packages on the > fringes. If an upstream project exists (LP may be good for this), a > community of users can be built (perhaps not all using Ubuntu) to keep > the software in shape. If someone finds upstream-dead source, and is > motivated to package it, they may also be willing to provide an > upstream focus. Note that this is for new packages: once in the > archives, if upstream dies, I do not advocate removal if a new > upstream community has yet to form. Ok, however I believe that's rather more a corner issue. My fear is that this rule might backfire so that people unnecessarily adopt projects which aren't dead yet. But as written, I think this is not really a big issue. > > > > (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. > > I find get-orig-source preferable for three reasons: 1) It > provides a standard interface for reviewers to easily get the upstream > source, 2) for cases of content changes (non-free removals, etc.), > it's very handy to have a get-orig-source rule when preparing the next > upstream release (especially as the updater may well not be the > packager), and 3) for cases of repacking, it's nice to have it > automated rather than fussing with different methods of generating > orig.tar.gz Ok, then let's just leave this as is (as it's listed as "get extra points"..) > > > > 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 ;) > > Hmm.. Maybe this should be rephrased. A bug tracker is nice, but > I agree that many upstreams don't have them. For "responsiveness", I > generally take a glance at upstream mailing list archives, etc. If > t
Re: Guidelines for reviewing new packages.
On Nov 17, 2007 5:52 AM, Stefan Potyra <[EMAIL PROTECTED]> wrote: > 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. That's a good point. My motivations in drafting this was to 1) make it easier for packagers to pre-review, 2) provide a common set of tests for packages, as I think we all have slightly different practices with reviewing. I certainly don't mean for these to become the official tests, with reviewers not also checking other things, nor ignoring the focus on distribution-as-a-whole. > I'm not too sure if micro-managing individual aspects will lead to better > source packages in general. I'm certain it won't, but hope that it will lead to fewer packages in REVU that fail to build from source, produce empty binaries, don't have manuals, etc. The intended audience is both packagers and reviewers, in the hopes that packagers will perform some review checks prior to upload. > Nonetheless, I've tried to write everything which came to my mind for the > given guidelines. Thank you for the detailed review. Please find my comments below. Based on the conclusion of this thread, I'll update the wiki (although others are welcome to do so beforehand). > > 2. Package must match current Ubuntu (and Debian) packaging policies > > Unclear: what is the "packaging policy" (debian-policy?) This is an interesting point. debian-policy often receives updates after a practice has been supported by all available tools for some time, and has been adopted by a wide number of packages. Ubuntu packaging policies seem scattered on the Ubuntu wiki, and some additional Debian policies (e.g. python, perl, java, etc.) see likewise scattered (although often on the Debian wiki). I'd welcome any suggestions on how to rephrase this to indicate that the relevant policies should be reviewed, and the package checked for compliance. > > 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). I tend to prefer no output, and look at any present overrides when looking through diff.gz. My experience with REVU is that nearly every package can be made clean, and I'd suggest that if there is a check that is inappropriate, or encourages a behaviour thought incorrect, that lintian be patched to address that, rather than having packages behave in two different ways, depending on whether the reviewer found the warnings of merit. > > 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? True. Perhaps this should be dropped? > > (If upstream is no more, the packager should consider adopting > > the upstream package somewhere) > > What is wrong with using the Ubuntu archive for this? Many REVU packages seem to be of the upload-and-forget variety, and the edges of universe don't always receive strong maintenance. My fear is that we'll have more unmaintained and dead packages on the fringes. If an upstream project exists (LP may be good for this), a community of users can be built (perhaps not all using Ubuntu) to keep the software in shape. If someone finds upstream-dead source, and is motivated to package it, they may also be willing to provide an upstream focus. Note that this is for new packages: once in the archives, if upstream dies, I do not advocate removal if a new upstream community has yet to form. > > (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. I find get-orig-source preferable for three reasons: 1) It provides a standard interface for reviewers to easily get the upstream source, 2) for cases of content changes (non-free removals, etc.), it's very handy to have a get-orig-source rule when preparing the next upstream release (especially as the updater may well not be the packager), and 3) for cases of repacking, it's nice to have it automated rather than fussing with different methods of generating orig.tar.gz > > 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 ;) Hmm.. Maybe this should be rephrased. A bug tracker is nice, but I agree that many
Re: Guidelines for reviewing new packages.
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 t
Re: Guidelines for reviewing new packages.
On Nov 12, 2007 9:33 PM, Scott Kitterman <[EMAIL PROTECTED]> wrote: > On Mon, 12 Nov 2007 20:13:45 -0600 "Justin Dugger" <[EMAIL PROTECTED]> > wrote: > >It sounds like it sort of solves much of both problems. > > I'm not sure what you mean. I think it makes patch systems even more > critical because you don't typically keep the upstream tarball in the VCS. I'm assuming you mean keeping the upstream release in VCS, not some compressed representation. That seems silly. At least, more silly than not keeping upstream code in VCS. It seems like a patch oriented system is the sort of thing that makes it simple for a security team to inspect source with, eliminates "patches on patches" ugliness, make it simple to select and integrate patches, and as a bonus, works with binary files. Joey Hess has more[1] on the subject, but he covers the use git. Having used neither, I'm not prepared to make any advocacy for one over the other, but they both sound like patch systems with advanced history features. Justin Dugger [1] http://kitenet.net/~joey/blog/entry/an_evolutionary_change_to_the_Debian_source_package_format/ -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Guidelines for reviewing new packages.
On Mon, 12 Nov 2007 20:13:45 -0600 "Justin Dugger" <[EMAIL PROTECTED]> wrote: >On Nov 12, 2007 4:34 PM, Emmet Hikory <[EMAIL PROTECTED]> wrote: >> Emmet Hikory wrote: >> 1: http://kitenet.net/~joey/blog/entry/dpatch_dbs_etc_etc_etc_etc_considered_harmful/ > >On a longer term basis, did any progress come out of UDS-Boston on >moving the entire archive in bazaar? No. There was pretty strong opposition from at least myself and no argument for it that I heard. At this point I think it's useful for smaller teams where there is consensus to use it. In MOTU woith 20,000 packages it's just not feasible. >It sounds like it sort of solves much of both problems. I'm not sure what you mean. I think it makes patch systems even more critical because you don't typically keep the upstream tarball in the VCS. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Guidelines for reviewing new packages.
Justin Dugger wrote: > On Nov 12, 2007 4:34 PM, Emmet Hikory <[EMAIL PROTECTED]> wrote: > >> Emmet Hikory wrote: >> 1: >> http://kitenet.net/~joey/blog/entry/dpatch_dbs_etc_etc_etc_etc_considered_harmful/ >> > > On a longer term basis, did any progress come out of UDS-Boston on > moving the entire archive in bazaar? > It sounds like it sort of solves much of both problems. > > Justin Dugger > No it doesn't and bzr is hideous in my worthless opinion... Barry deFreese -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Guidelines for reviewing new packages.
On Mon, 12 Nov 2007 20:30:16 +0100 Emilio Pozuelo Monfort <[EMAIL PROTECTED]> wrote: >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? I'd suggest that we not be to pedantic about it. There are valid reasons not to use patch systems. Additionally, adding a patch system to a traditional dh rules based package can be a dauntingly non-trivial exercise for a new contributor. As an example of a case where I think a patch system would have been inapprpriate, I uploaded a one line change to courier shortly before gutsy released. I did it inline and not as a patch. I did it this way for the following reasons: 1. It was close to release and I felt that monkeying with debian/rules to add a patch represented a risk that there wouldn't be a lot of time to retire. 2. The change was already in the next upstream release and in Debian, so I knew it wouldn't have to be maintained. 3. It was only a single line change. Debian has a hard and fast rule about patch systems (although I still sometimes see inline changes from Debian). Ubuntu has traditionally been more flexible. I would like to see proper patching encouraged, but not required. This policy flexibility has, I think, generally served Ubuntu well. Scott K -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Guidelines for reviewing new packages.
On Nov 12, 2007 4:34 PM, Emmet Hikory <[EMAIL PROTECTED]> wrote: > Emmet Hikory wrote: > 1: > http://kitenet.net/~joey/blog/entry/dpatch_dbs_etc_etc_etc_etc_considered_harmful/ On a longer term basis, did any progress come out of UDS-Boston on moving the entire archive in bazaar? It sounds like it sort of solves much of both problems. Justin Dugger -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Guidelines for reviewing new packages.
Emmet Hikory wrote: > 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. Emilio Pozuelo Monfort wrote: > 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? I'd actually be opposed to enforcing that rule. There are a number of arguments against it (see below), and while I also tend to prefer it, I don't see value in making a fuss if the package uses bare diff.gz. Speaking specifically about wxwidgets2.6: that package is very odd in many ways, of which the patching system is one of the least confusing. Regarding Security / SRU guidelines, I firmly believe that whichever patch system is in use by the package should be followed also for these updates. Mixing pure diff.gz patches with debian/patches patches is a recipe for confusion. Summary arguments against the use of dpatch, etc. A) It can be frustrating to generate the built source for inspection (IRC transcript(1)) B) It prevents the use of complex grep to test for security issues (except after (A)) C) Packages maintained in VCS with full source do not benefit from VCS merging when pulling new upstream. D) Users cannot as easily apply alternate-source patches if wishing to modify source (without learning distribution-specific patch systems). E) Lack of care with foo-edit-patch can cause patches of patches of patches of ... Now, just because I do happen to be a fan of patch systems, despite defending the option of not using them: Summary arguments in favor of a patch system: A) It is much easier to understand each change atomically B) dpatch comments are an excellent way to communicate reasoning for a patch C) It is easier to extract specific patches for sending upstream or to other distributions D) One can easily enable / disable specific patches E) When packaging a new upstream, one doesn't have to dig through patch application failures from zcat ../foo.diff.gz | patch -p1 to get a working debian/ 1: http://kitenet.net/~joey/blog/entry/dpatch_dbs_etc_etc_etc_etc_considered_harmful/ -- Emmet HIKORY -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Guidelines for reviewing new packages.
Hi, Am Montag 12 November 2007 20:38:19 schrieb Jeffrey Ratcliffe: > On 12/11/2007, Emilio Pozuelo Monfort wrote: > > 4b. Contents of diff.gz should be in debian/. i.e. no inline > > patching. > > Absolutely. Especially if there are patches on patches, anything else > makes things really hard for anybody to follow. Personally I don't like patch systems too much. Apart from my personal preference though, there is also the limitation that you cannot change the upstream clean rule with patches without producing really ugly debian/rules. Speaking of patches on patches: you can get these only with a patch system :P. Cheers, Stefan. 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
Re: Guidelines for reviewing new packages.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/11/2007, Emilio Pozuelo Monfort wrote: > 4b. Contents of diff.gz should be in debian/. i.e. no inline patching. Absolutely. Especially if there are patches on patches, anything else makes things really hard for anybody to follow. Regards Jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: http://firegpg.tuxfamily.org iD8DBQFHOKuUVDAgnE3XzJMRAiRuAKD419rxx27FSQLz6/gL8+m0TPPC9QCdG5zv 9Ueu7Ul+phBvkK+K6Hja6PU= =vX4j -END PGP SIGNATURE- -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
Re: Guidelines for reviewing new packages.
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
Guidelines for reviewing new packages.
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 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 -- Emmet HIKORY -- Ubuntu-motu mailing list Ubuntu-motu@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-motu
