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.
Peter Stefano Zacchiroli <[email protected]> wrote: > Package: dpkg-dev-el > Version: 29.5-1 > Severity: normal > > Hi, I've a proposal for a (supposedly) better convention about > finalized/unfinalized debian/changelog entries. > > Currently: > > - finalized entries have real distribution names (e.g., "unstable"), > and maintainer / timestamp after "--" at the entry end > > - unfinalized entries have real distribution names too, but no > maintainer / timestamp after "--" > > The problems I see with that: > > 1) finalized entries are not distinguishable from valid, yet not > uploaded entries in VCSs (the equivalent of "UNRELEASED" entries > implemented by dch in devscripts) > > 2) unfinalized entries are not properly parseable by > dpkg-parsechangelog (which indeed complains) and strictly speacking > do not adhere to the debian/changelog syntax > > 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 > > - packages are not properly buildable by automatic tools which > checkout packages from VCS and build them, a la > svnbuildstat.debian.net > > > 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) > > - upon finalization: fix UNRELEASED and update the timestamp > > > 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. > > > What do you think of this? > Cheers. > -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
