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

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

On 20/08/08 at 09:38 +0200, Raphael Hertzog wrote:
> 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.

It doesn't really reopen the bug. But the BTS version-tracking allows to
find out that the bug is not fixed in the new maintainer 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".

Actually, for lenny, we could just have used +deb41 until the release
team announced that Lenny would be 5.0, and switch to +deb50 at this
point. If the release team doesn't change its mind, it's fine.

Would that work for everybody?
| Lucas Nussbaum
| lucas@lucas-nussbaum.net   http://www.lucas-nussbaum.net/ |
| jabber: lucas@nussbaum.fr             GPG: 1024D/023B3F4F |

Reply to: