[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: DEP1: Non Maintainer Uploads (final call for review)



* Lucas Nussbaum [Mon, 11 Aug 2008 19:28:53 -0300]:

Hi, these are some other, mostly minor bits:

>    The version must be the version of the last upload, plus +nmuX,
>    where X is a counter starting at 1. If the last upload was also
>    an NMU, the counter should be increased. For example, if the
>    current version is 1.5-1, then an NMU would get version
>    1.5-1+nmu1. If the current version is 1.5+nmu3 (a native package
>    which has already been NMUd), the NMU would get version
                            ^^^^
                            NMUed?

>    Just like any other (source) upload, NMUs must add an entry to
>    debian/changelog, telling what has changed with this upload. The
>    first line of this entry is special, it must be:

>    * Non-maintainer upload

Add trailing dot?

>    If you upload a package to testing or stable, you sometimes need
>    to "fork" the version number tree. This is the case for security
>    uploads, for example. For this, a version of the form +debXYuZ
>    should be used, where X is the current stable major release
>    number, and Y is the current minor release number for a stable
>    upload, or one higher than that for a testing upload. Z is a
>    counter starting at 1. For example, while Etch (Debian 4.0) is
>    stable, a security NMU to stable for a package at version 1.5-3
>    would have version 1.5-3+deb40u1, while a security NMU to Lenny
>    would get version 1.5-3+deb41u1. This is the case even when it
>    is already known that the next release will be a new major
>    version ; for instance, Lenny will be released as Debian 5.0.

Hm, this paragraph *really* feels out of place in this documment, even
if they are uploads done by other people than the maintainer.

>   5.11.3. Using the DELAYED/ queue

>    After asking the maintainer for the permission to upload your

s/the// (or s/the/their/, see below).

>    BinNMUs are usually done by porters. They add an entry to
>    debian/changelog, explaining why the upload was needed and

"BinNMUs are usually triggered on the buildds via wanna-build. [An entry
is added to debian/changelog, ...]" would be more accurate.

>   5.11.6. NMUs vs QA uploads

>    NMUs are uploads of packages which are owned by another
>    maintainer.

Can I has something else than "owned", please? Maybe "NMUs are uploads
of packages by somebody else than their assigned maintainer."?

>   * QA upload.

>    If you want to do an NMU, and it seems that the maintainer is
>    not active, it is wise to check if the package is orphaned. When
>    doing the first QA upload to an orphaned package, the maintainer
>    should be set to Debian QA Group <packages@qa.debian.org>.
>    Orphaned packages which did not have a QA upload yet still have
>    their old maintainer set. There is a list of them at
>    http://qa.debian.org/orphaned.html.

AFAIK, their PTS page will say they are orphaned, which may be handier
than searching over then long list.

Also, there are a couple places in the document where language it's not
gender-neutral. If you care about that, I have a diff to move the
document to use the singular they, please let me know if you're
interested.

Finally, let's hope this is the latest time in history we have to
regulate NMUs, because we've ended up with something better. (FWIW I
have the feeling NMUs are much more tolerated nowadays, so this document
sounds a bit on the other side on the fence to me, but it's probably
good after all since an environment where they are much tolerated may
lead to the impression they can be taken lightly and prepared with less
care, so thanks for pushing this DEP.)

-- 
Adeodato Simó                                     dato at net.com.org.es
Debian Developer                                  adeodato at debian.org
 
                         Listening to: Javier Álvarez - Top of the world


Reply to: