Re: DEP1: Non Maintainer Uploads (final call for review)
On 12/08/08 at 20:44 +0100, Adeodato Simó wrote:
> * 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?
ACK (was the only occurence)
> > 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?
ACK
> > 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.
I don't mind removing it if the security team objects.
> > 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).
s/the//
> > 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.
ACK
> > 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."?
ACK
> > * 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.
right, added.
> 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.
The whole developers-reference is written in a non-gender-neutral
manner. If there's consensus that it's a good idea, I would prefer if
the whole devref was converted at once, instead of converting only this
part.
> Finally, let's hope this is the latest time in history we have to
> regulate NMUs,
At least I probably won't try again to write a DEP anytime soon :-)
> 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.)
Even if, in general, NMUs are more tolerated nowadays, there are still a
lot of cases where the NMUer gets flamed by someone referring to the
current policy of only allowing NMUs for serious issues, no matter how
much you wait and how neglected the package is. Also, lots of people
probably moderate themselves, and don't fix annoying issues in neglected
packages, simply because they fear that they might get flamed by the
maintainer.
I'm personally satisfied with the content of this proposal. I don't
think that we could have gone further without losing consensus.
--
| Lucas Nussbaum
| lucas@lucas-nussbaum.net http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr GPG: 1024D/023B3F4F |
Reply to: