Re: DEP1: Non Maintainer Uploads (final call for review)
On Tue, 19 Aug 2008, Thijs Kinkhorst wrote:
> The past weeks I had several encounters with the situation that a maintainer
> completely overlooked and NMU and uploaded a newer version without
> acknowledging the previous NMU, thereby reintroducing the problem the NMU
> addressed. This happened to active maintainers.
At least the BTS automatically reopens the bugs so the problem doesn't
stay unnotified and untracked.
> I was wondering why we version NMU's differently from MU's. If they used the
> same scheme, in these cases the subsequent upload from the MU would have been
> rejected. That would have flagged a problem for them and they had discovered
> the NMU they forgot to integrate. Of course it wouldn't help in any situation
> but it would have helped these.
The maintainer is still king and if he decides that the NMU was not a good
idea, he would have no other choice than skipping a revision in the
changelog. That would be confusing.
Furthermore, as we encourage usage of the delayed queue, it seems natural
to avoid collision between the NMU upload and a maintainer upload
integrating the NMU done before the end of the delay.
> I do not really buy the "stealing" argument since maintainers do not "own"
> version numbers. It indeed interferes with their work but it *needs* to. A
> completely ignored NMU has been rendered ineffective.
IMO you're trying to abuse the version numbering to avoid a problem. The
problem can be detected automatically (the BTS does it!) and it should be
possible to have an infrastructure to inform the maintainer if what's
existing is not enough.
I'd like to remind that if the maintainer had given a look to the PTS they
would have seen the NMU. The PTS displays a prominent notice in the TODO
section "you should integrate the NMU".
A look at the BTS also gives you hints about the existence of the NMU.
Those hints would be even more visible once version numbers include "nmu"
in them. Then the maintainer also received several mails about the NMU
upload.
> > 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.
>
> I am not very happy with this paragraph. The proposed scheme is in my opinion
> hard to read, and it gets especially confusing when 40 means 4.1 and 41 means
> 5.0.
>
> We already have a scheme in the security team that prevents this numbering
> confusion, and that is to use release codenames. It makes it clear at a
> glance whether a package is intended for stable or testing, and the codenames
> do not change.
>
> The current convention is to add +etch1 or +lenny1 respectively. This scheme
> works well.
It works well except when the same package version is in two consecutive
release.
1.0-1+sarge1 > 1.0-1+etch1 when we really want the opposite. That's why
this scheme was invented. I agree that it's not very nice though but i
couldn't find anything "cleaner".
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Reply to: