[Debichem-devel] The drawbacks of dummy changelog entries

[Michael Banck]

Hi,

On Tue, Mar 18, 2025 at 11:59:41AM +0100, Santiago Vila wrote:
> El 17/3/25 a las 16:35, Andrius Merkys escribió:
> > For each Salsa repository there will be at most one UNRELEASED
> > ("dummy") debian/changelog entry, which is not meant to be uploaded
> > until someone does s/UNRELEASED/unstable/ and releases the package.
> > I have seen this practice in >2 teams and I think it has some
> > benefits.
> > 
> > First, it shows that new release is in progress. It might be that
> > someone is working actively, made a drive-by change, or hit a
> > roadblock.

It also shows that the last revision was actually uploaded - if you just
see the last changelog entry, you cannot be entirely sure (without
checking the tags or the PTS), but as we switch from UNRELEASED to
unstable upon upload, I guess that point is mostly moot.

> > Second, it documents changes since the last update of
> > debian/changelog. While one might say that 'git log' does the same,
> > 'git log' usually contains much more noise. I personally work in
> > small commits without rebasing them.
> > 
> > Third, it is a convenient place for todo list for the upcoming
> > upload.
> 
> I see your point, but I don't see how any of the above applies
> for the completely empty dummy changelogs I was really talking about.

Personally, I used it to separate the creation of a new (unfinished)
changelog entry from the actual first change for the new revision.

> Maybe it would make sense to create a changelog only when there are
> actual changes? That way the warning about "pending commits, time to
> release?" would only be triggered when it really makes sense.

I think that is reasonable and I will change my personal work-flow to no
longer automatically commit a new UNRELEASED changelog entry upon upload
of a revision.


Michael