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

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

On Wednesday 20 August 2008 10:06, Lucas Nussbaum wrote:
> 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.

That has the drawback of not notifying the maintainer explicitly directly 
after (or even before) the upload.

But perhaps we need another mechanism to signal this. Consecutive uploads to 
the same distribution should not cause previously present version entries to 
disappear from the changelog. Maybe the archive can reject an upload that 
misses a changelog entry that was previously present in the uploads to this 

The NMU changelog entry should always be there, else the BTS will start to 
display incorrect information. Say the NMU'ed fix migrated to testing and the 
maintainer uploads another fix to unstable, leaving out the changelog entry, 
testing is marked as affected again which it isn't.

> > 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".

Clean is of course subjective, I find the codename scheme cleaner than a 
scheme where 41 means 5.0. The situation you name has as far as I know not 
occured in any recent times so it seems you're trying to solve an 
hypothetical problem. And if it occurs we can deal with it in that rare case 
individually rather than devising a more complex scheme around a situation 
that hardly happens, right?

> 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.

Is there a reason why we couldn't decide on that version number of n+1 before 
the release of n? Then we can always use the right number right from the 
start and the scheme gets quite less convoluted to me.


Attachment: pgpMX47NTXgMH.pgp
Description: PGP signature

Reply to: