[Releasing] [Development] Change file process & improvement proposal

[Edward Welbourne]

On Tue, Jan 24, 2017 at 03:38:11PM +0100, Edward Welbourne wrote:
>>> Proposal: Check for [ChangeLog] entries in a 5.x branch _after 5.x.0
>>> branched_. Is that easy to enable/disable?
>>
>> It should be easy to detect that 5.x.0 "has branched" - check for
>> existence of either origin/5.x.0 branch or v5.x.0 tag. [...]

On 24 January 2017 16:20, Oswald Buddenhagen replied:
> that's answering the wrong question. changes for 5.x.0 may require a
> changelog just as well, as the branch may receive fixes against 5.(x-1).

What the proposal actually asked for was technically feasible; so I said
how to do it.  My impression was that the proposal was motivated by a
claim that stabilisation fixes typically won't want a change-log, as
they're fixes to recent changes.  The reasoning there may in fact be
flawed - a fix to a recent change *with a change-log entry* might well
need to amend/update the change-log entry.  Still, aside from that, I
suppose patch branches (M.m.p) are typically such stabilisation.

However, you seem to be talking about *release* 5.x.0 rather than the
*branch* of that name, so I'm not really clear on what you're talking
about.

> we could suppress the changelog enforcement for example by standardizing
> my "amends <sha1>." lines in the commit messages. if the reference is to
> a commit which has not been tagged yet, we know that users won't find it
> interesting.

I have never heard of these amends <sha1> lines; where are they
explained ?  In any case, users may find a change interesting even if
there is no specific earlier commit that can be pinned down as what this
new change amends - sometimes, the origin of a status quo (being
amended) is murky, its causes are contentious and most of the lines of
prior code involved date from the 190MB commit 38be0d1383 that pulled
most of our code into git in the first place.  Still, maybe your
amends-spec addresses that ...

	Eddy.