Re: DEP1: Non Maintainer Uploads (final call for review)
On Wed, 20 Aug 2008, Thijs Kinkhorst wrote:
> 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.
Well, it still forces the inclusion of information for a revision whose
changes have been fully reverted.
I can sympathize with it on the basis that it's better to document
in a subsequent changelog entry that the NMU has been fully reverted
and to explain why.
But what about mis-targeted uploads? You upload the experimental version
to unstable by error. When you want to revert that, you upload the
previous package with an epoch and the upload gets rejected because you
dropped the experimental changelog... that would be counter-productive
too.
> 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.
Well, the BTS grabs the changelog from all branches and is able to see
that the testing and unstable version have diverged (AFAIK).
> 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?
It happens a bit more often when you consider not only security updates
but also t-p-u uploads.
Say stable and testing have 1.0-1. Sid has 1.0-2.
stable-security has 1.0-1+etch1
The maintainer wants to upload something to t-p-u. If we had a codename
that sorted before etch we would be screwed.
It doesn't happen often but I've seen it happen a few times already.
And much like we generalized the +nmuX logic for all kinds of nmu (of
native and non-native packages), it would be nice to have an unified
versioning scheme for this case.
> 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.
Agreed. We should just decide to always increment our major version given
that we don't release often. But I'm not sure if we can get an easy
agreement here given that historically we decided on a case by case
depending on how many changes the new version contained.
Cheers,
--
Raphaël Hertzog
Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/
Reply to: