Bug#517973: unfinalized changelog entries imply unparseable debian/changelog files
- To: Stefano Zacchiroli <email@example.com>, firstname.lastname@example.org, Luca Capello <email@example.com>
- Subject: Bug#517973: unfinalized changelog entries imply unparseable debian/changelog files
- From: David Bremner <firstname.lastname@example.org>
- Date: Fri, 19 Oct 2018 22:12:21 -0300
- Message-id: <[🔎] email@example.com>
- Reply-to: David Bremner <firstname.lastname@example.org>, email@example.com
- In-reply-to: <20090311184429.GA17484@usha.takhisis.invalid>
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <20090311184429.GA17484@usha.takhisis.invalid> <email@example.com>
Stefano Zacchiroli <firstname.lastname@example.org> writes:
> Hi all, sorry for the late reply.
I see your late reply and raise you 9 years or so.
> On Tue, Mar 03, 2009 at 09:03:22PM +0100, Luca Capello wrote:
>> > 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.
Aside from the terminalogy of "finalization", which seems to be specific
to debian-changelog-mode, I'd say that's now a (the?) standard workflow.
>> >> 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.
> Fair enough, we disagree on that.
I don't ever want a package to be in a state where dpkg-buildpackage
cannot build it. I understand that I could use ./debian/rules build
etc..., but I don't want to be be forced to do it. This means that I
don't ever want my changelogs to be in the state debian-changelog-mode
>> >> - 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.
> Fair enough, I've no strong opinion on this.
> Still, if this gets implemented, it would make sense to have this
> detail customizable.
I tend to agree that the timestamp doesn't need to change with every
tweak to the changelog. What matters is the timestamp in the uploaded
package. But I also think that "unfinalizing" and "finalizing" the
changelog is mostly busywork for me.
>> >> - upon finalization: fix UNRELEASED and update the timestamp
>> IIRC lintian should whine if distributions is UNRELEASED.
> It does, but the proposal still stands.
Lintian no long whines about this. dput-ng does check for uploads to
UNRELEASED. dch creates new entries as UNRELEASED (well, at least with
So I guess I generally support Stefano's proposal, or at least the
meta-proposal to make debian-changelog-mode more like dch.
The idea of finalization is fairly pervasive in
debian-changelog-mode.el, I don't know how easy it would be to maintain
two different ideas of finalized: either the missing-timestamp kind or
the UNRELEASED distribution. For my own use it would be tempting to just
rip out all of the code related to finalization, but I don't know how
many people find it useful, rather than something to be worked around.