Guidelines for reviewing new packages.

[Stefan Potyra]

Hi,

Am Samstag 17 November 2007 05:57:18 schrieb Emmet Hikory:
> On Nov 17, 2007 5:52 AM, Stefan Potyra <sistpoty at ubuntu.com> 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
> the entirety of activity consists of people asking questions and
> reporting problems, with no visible input from the developers, I'd
> class it "unresponsive", but don't tend to be more agressive about
> this.  Further, most packagers are interacting with upstream, and can
> readily say whether there is someone on the other end.  

hm... I'm not entirely sure if packagers always interact with upstream or just 
grab software from someplace and package it...

However phrasing it as "Packager should interact with upstream" is a difficult 
criteria for reviewing, which cannot get applied for just one upload. 
(Although I'm trying to force this sometimes by adding comments like "please 
report this to upstream").


>
> > >     4.  Packaged version should be latest upstream
> >
> > [... with the exception of a good reason to not use latest upstream]
>
>     Perhaps, although I'd argue that this requires documentation as to
> the reason, to avoid many "mypony should be upgraded to verison 17.2"
> bugs.  With such documentation, I would be happy to override this
> guideline as a reviewer.  Without the documentation, even if I agreed,
> I wouldn't think it responsible to advocate the package for inclusion.

Agreed, maybe add s.th. "or have the reasons documented if the latest version 
is not applicable"?

>
> > >     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).
>
>     Actually, we often vary from upstream in many different ways.
> Upstream usually references /usr/local/* where we install to /usr/*.

That should *not* lead to different behaviour, it's indeed the right thing 
(both for upstream installing to /usr/local and for packages to vary on 
this). I'd prefer to not see *this* documented ;).

> We regularly create default configurations that differ from upstream,
> and not infrequenty provide various launcher scripts.  (remainder of
> list omitted)
>
>     All of these tasks are part of integration into the distribution,
> and should not count against the package: similarly, if any of these
> changes causes a behavioral difference, it should be documented.

Agreed, maybe we could make this more clear?

"Differences in behaviour (like varied default settings, ...) should be 
documented in README.Debian".

>
> > >     6.  Non-native packages must have verifiable cryptographic path to
> > > upstream source
> >
> > Does this mean that the orig.tar.gz shouldn't differ [1]?
> > [1]: https://wiki.ubuntu.com/PackagingGuide/Basic#ChangingOrigTarball
>
>     When upstream provides an orig.tar.gz, yes.  When upstream does
> not, it means that there is a means by which a reviewer can 1) compare
> a known upstream to a known hash value, and 2) use an automated
> procedure to generate the orig.tar.gz from the verified upstream file.

Hm... this overlaps with the get-orig-source thingy above? Also, maybe you 
could add this explanation besides it, to make it more clear? ;).

>
> > >     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.
>
>     Ah.  I misunderstood the current policy then.  I think that they
> should be obligated, as I know I make mistakes, and I expect everyone
> else to as well, but don't mean to be changing policy by the
> presentation of the reviewing guidelines.

(off-topic: because everyone makes mistakes, it's still encouraged to go 
through reviews. I hope that any MOTU who isn't sure about s.th. will ask for 
help and/or go through reviews. Also this results in a weakened review 
process: "Fix this, and that, and then I'm happy, so just upload it").

Thanks again!
    Stefan.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : https://lists.ubuntu.com/archives/ubuntu-motu/attachments/20071118/432d25d6/attachment.pgp