Hi there! First of all, Stefano, thank you to have brought this issue to the BTS. For the record, Stefano and I started discussing it during DebConf8 but then I have failed to find the time to sit down and report it.
On Tue, 03 Mar 2009 13:53:02 +0100, Peter S Galbraith wrote: > It reflects my own use, I guess. > > I unfinalize to add something, but finalize using distribution UNRELEASED > to save the work in CVS. I only set the distribution to unstable when > ready for an actual upload. I do not remember having seen a lot of people having the same workflow as me: I do not finalize anything except before the final version which will be either uploaded to Debian or given out for tests. However, in the latter case the package version will be identified as with both a non-official number (e.g. $OFFICIAL~gismo.1) and distribution UNRELEASED. My main concern against "non-finished" finalization is that I do not want my name on packages I do not release. >> Hi, I've a proposal for a (supposedly) better convention about >> finalized/unfinalized debian/changelog entries. I think that the problem is not strictly-related to dpkg-dev-el, but it is a more general one and AFAIK there is no strong (i.e., a must in the Debian Policy) convention on this matter. >> - unfinalized entries have real distribution names too, but no >> maintainer / timestamp after "--" I do not why, but it seems my memory is fault here, since I somehow remember that C-c C-v (debian-changelog-add-version) would have created a new entry with distribution UNRELEASED. >> 1) finalized entries are not distinguishable from valid, yet not >> uploaded entries in VCSs (the equivalent of "UNRELEASED" entries >> implemented by dch in devscripts) This is indeed a problem. >> 2) unfinalized entries are not properly parseable by >> dpkg-parsechangelog (which indeed complains) and strictly speacking >> do not adhere to the debian/changelog syntax As Stefano already knows, I disagree here: IMHO, since we are talking about a working version, there is no "real" debian/changelog. This is very similar to, for example, having git-dch creating the relevant debian/changelog entries: you do not create it until before the upload (finalization). The last example introduces another problem which does not properly belong to this bug, but it is somehow related: simply reading the debian/changelog present in Git (I do not know about other VCSs), there is no way to distinguish between the last uploaded version and the working one. >> Consequences of (2): >> >> - one cannot know who is the author of the text in a mono-author >> (i.e. with no "[ Name Surname ]" tags) entry Yes, this is a drawback of unfinalized entries. >> - packages are not properly buildable by automatic tools which >> checkout packages from VCS and build them, a la >> svnbuildstat.debian.net As I wrote before, this is why I would not like to finalize entries: I do not want my name on packages which I have not tested and/or released. In this case, a proper solution would be a dch option to finalize the entries, which will then set the author name to something more useful (i.e. the builder name or something similar to the binary-only NMUs). >> My proposal to fix that is basically to implement the current dch >> conventions, namely: >> >> - keep author name / timestamp after -- and use "UNRELEASED" as the >> distribution for unfinalized changelog entries. Also, do not touch >> the timestamp until an entry is finalized (which avoids useless VCS >> commit diffs) I disagree on the second part of this solution: if an entry must be finalized, then the timestamp should reflect it. Yes, this brings useless VCS commit diffs, but I really think that if the timestamp would not be updated, then there is no difference between having an entry finalized or not. >> - upon finalization: fix UNRELEASED and update the timestamp IIRC lintian should whine if distributions is UNRELEASED. >> Also, this would have the additional benefit of shamelessly >> integrating the workflow of people using dch with those of people >> using the Emacs changelog mode. FWIW, I belive the former set of >> people is way larger than the latter. You are right, but if the previous Vim maintainer moved to Emacs, maybe this will change in the future ;-) Thx, bye, Gismo / Luca
pgp0QLj5vJRr9.pgp
Description: PGP signature
