Bug#517973: unfinalized changelog entries imply unparseable debian/changelog files

[David Bremner <bremner@debian.org>]

Stefano Zacchiroli <zack@debian.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
calls "unfinalized".

>> >> - 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
DEBCHANGE_RELEASE_HEURISTIC=changelog).

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.

d