Bug#474878: dpkg-dev: new dpkg-genchanges -si heuristic could (should?) look further in changelog history
On Fri, 15 May 2009, Raphael Hertzog wrote: Don, what do you consider best-practice in terms of changelogs merging? In the BTS's view of versioning, a version is based on exactly one preceeding version. This version is currently the version immediately preceeding the uploaded version according to the changelog file. In the case of experimental uploads merged into unstable packages, the changelog generally shouldn't include the changelog entries from experimental, as the package only contains the changes merged from experimental (not other changes in the upstream version, for example). [But specific changelog sub-items from the experimental changelog that correspond to bugs fixed in the stable package should of course be there.] You'd basically have the following (u=unstable, e=experimental): u:1--u:1.1-u:1.2-u:1.3-u:2.4 ^ ^ ^ | | | e:2 | | ^ e:2.2 | |e:2.3 e:2.1 with the order of the changelogs following the arrows. In the future, it'd be nice to be able to come up with some sane way of representing that the e:2.3 upload actually had the changes made in e:2.2, e:2.1 and e:2. Unfortunatly, while I've thought about this for a while, I haven't been able to come up with a method that is easy to implement, understand, and is actually an improvement over the status quo. Don Armstrong -- If you find it impossible to believe that the universe didn't have a creator, why don't you find it impossible that your creator didn't have one either? -- Anonymous Coward http://slashdot.org/comments.pl?sid=167556cid=13970629 http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#474878: dpkg-dev: new dpkg-genchanges -si heuristic could (should?) look further in changelog history
On Sun, 18 Jan 2009, Adeodato Simó wrote: * Raphael Hertzog [Sun, 27 Apr 2008 22:09:18 +0200]: On Mon, 07 Apr 2008, Adeodato Simó wrote: The new dpkg-genchanges -si heuristic of looking at the version number of the previous entry in the changelog breaks for (long-lived) experimental packages that merge changelog entries from unstable in chronological order. That is, you end up with a changelog like: Is this really a good practice? Doesn't it cause troubles to the BTS version tracking since it use changelog to creates trees of versions? It seems like, indeed, it's not good practice with the current BTS code. I'll ask Don one of these days if the BTS could get smarter about it. However, I can't see anything wrong in having dpkg-genchanges look further in changelog history (a tiny performance penalty, I guess). I'll understand that you may not want to do that if it's not a supported or recommended workflow anyway, so let's leave this bug open until I get an authoritative answer from Don. CCing Don and ow...@bugs.d.o. Don, what do you consider best-practice in terms of changelogs merging? Do you have any opinion on this bug? Cheers, -- Raphaël Hertzog Contribuez à Debian et gagnez un cahier de l'admin Debian Lenny : http://www.ouaza.com/wp/2009/03/02/contribuer-a-debian-gagner-un-livre/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#474878: dpkg-dev: new dpkg-genchanges -si heuristic could (should?) look further in changelog history
* Raphael Hertzog [Sun, 27 Apr 2008 22:09:18 +0200]: On Mon, 07 Apr 2008, Adeodato Simó wrote: The new dpkg-genchanges -si heuristic of looking at the version number of the previous entry in the changelog breaks for (long-lived) experimental packages that merge changelog entries from unstable in chronological order. That is, you end up with a changelog like: Is this really a good practice? Doesn't it cause troubles to the BTS version tracking since it use changelog to creates trees of versions? It seems like, indeed, it's not good practice with the current BTS code. I'll ask Don one of these days if the BTS could get smarter about it. However, I can't see anything wrong in having dpkg-genchanges look further in changelog history (a tiny performance penalty, I guess). I'll understand that you may not want to do that if it's not a supported or recommended workflow anyway, so let's leave this bug open until I get an authoritative answer from Don. Thanks, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org Listening to: Radiohead - House Of Cards -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#474878: dpkg-dev: new dpkg-genchanges -si heuristic could (should?) look further in changelog history
On Mon, 07 Apr 2008, Adeodato Simó wrote: The new dpkg-genchanges -si heuristic of looking at the version number of the previous entry in the changelog breaks for (long-lived) experimental packages that merge changelog entries from unstable in chronological order. That is, you end up with a changelog like: Is this really a good practice? Doesn't it cause troubles to the BTS version tracking since it use changelog to creates trees of versions? It would be nice to standardize (idea for a DEP maybe?) the procedure to follow when one uses experimental to prepare new upstream version of packages in parallel to continued maintenance in sid. I know for example that the glibc team accumulates changes in a single changelog entry and they increment the version of that entry in each experimental upload. And in the end, they use that changelog entry for the first unstable upload as well. It's a simple way to make sure that you have all bug closures where they have to be. On the other hand, the BTS version tracking starts a new branch for each experimental upload since the previous experimental version number disappeared. And if you check the version graph, you'll see all those dead branches. Let's come back to our problem however. The ordering based by date renders the -voption difficult to understand... do we want all the entries appearing after the given version or all entries that have a version higher than the one given ? (cf #477638) If we require/assume that entries are ordered by version, then the two solutions have the same result. :) The chronological order might be the order which represents best the reality but it's also counter-intuitive in the sense that it doesn't match the upstream evolution of the software. 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]
Bug#474878: dpkg-dev: new dpkg-genchanges -si heuristic could (should?) look further in changelog history
Package: dpkg-dev Version: 1.14.16 The new dpkg-genchanges -si heuristic of looking at the version number of the previous entry in the changelog breaks for (long-lived) experimental packages that merge changelog entries from unstable in chronological order. That is, you end up with a changelog like: package (2.0~rc1-2) experimental; * Merge 1.5-2 upload. * Do some other stuff. package (1.5-2) unstable; * Fix bug #123. package (2.0~rc1-1) experimental; * Upload first release candidate of 2.0 to experimental. package (1.5-1) unstable; * New upstream release. Cheers, -- Adeodato Simó dato at net.com.org.es Debian Developer adeodato at debian.org As an adolescent I aspired to lasting fame, I craved factual certainty, and I thirsted for a meaningful vision of human life -- so I became a scientist. This is like becoming an archbishop so you can meet girls. -- Matt Cartmill
