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 distribution. 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. Thijs
Attachment:
pgpaz3_nRAKN0.pgp
Description: PGP signature