groff
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: What is our ChangeLog management policy?


From: Ingo Schwarze
Subject: Re: What is our ChangeLog management policy?
Date: Sun, 5 Sep 2021 19:34:05 +0200
User-agent: Mutt/1.12.2 (2019-09-21)

Hello Keith,

Keith Marshall wrote on Sun, Sep 05, 2021 at 04:49:41PM +0100:

> If you would like my proposal, then it would be that we make one final
> commit, for each extant ChangeLog file, in which we add a log message to
> the effect that free-standing ChangeLog files are deprecated, and that
> the details of future commits will be found _exclusively_ in the Git
> log.  Then, we insert the entire content of what we would have added to
> the ChangeLog file as the Git log message.  IMO, it is anathema that the
> log message content should be redundantly duplicated in a free-standing
> ChangeLog file -- there are perfectly adequate tools, for generation of
> such a free-standing file, in GNU ChangeLog format if desired, directly
> from the Git log, for any user who wishes to extract it in that form.

I like this proposal very much, and more than anything else proposed in
this thread so far.

While i do see the point in the three-tier system outlined by Branden,
let me note that it causes more work for developers, which is not ideal
for a small development team with little time to spare.  Also, Branden
himself pointed out that is is not easy to implement consistently even
when developers apply great diligence.

I think having full details in one place is important, and guessing
from what Keith, Branden, and myself said, it might be possible to
reach consensus that git commit messages are a good place for that.
The uppermost layer described by Branden, the release notes in the
NEWS file, provided for users at large, also matter.  But having
an intermediate layer between the two for "packagers/expert users"
seems less important to me.  I suspect good commit messages can
serve the needs of "packagers/expert users" just as well as the
needs of groff developers.

If we decide to implement Keiths proposal, making the change at the
same time as the next GNU troff release would seem ideal to me.
That would make communication simple and straightforward:
"The ChangeLog goes up to groff X.Y.Z; after that, look at the git
commit messages."

Yours,
  Ingo



reply via email to

[Prev in Thread] Current Thread [Next in Thread]