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/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
