Re: [PATCH] Changelog: Add details about new features for SPR

[George Dunlap <george.dunlap@xxxxxxxxx>]

On Mon, Jan 30, 2023 at 3:54 PM Andrew Cooper <amc96@xxxxxxxx> wrote:

On 27/01/2023 11:40 am, Henry Wang wrote:
> Hi Andrew,
>
>> -----Original Message-----
>> From: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
>> Subject: [PATCH] Changelog: Add details about new features for SPR
>>
>> Signed-off-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> Thanks for remembering this :)
>
> Acked-by: Henry Wang <Henry.Wang@xxxxxxx>

Thanks.

I'll commit this when OSSTest has become unblocked.

>
>> ---
>> A reminder to everyone, write the changelog as it happens, rather than
>> scrambling to remember 8 months of development just as the release is
>> happening.
> I wonder if there is a way to automate this in our CI so we can avoid
> forgetting this. But currently I am not really sure if the solution in my mind
> is simple enough... I will try to keep this issue in my mind so that probably I
> can come back with some solutions.

The automated version is `git log $PREV_RELEASE > changelog.log`, and
this is very deliberately not that.

It needs the maintainers / committers to keep "interesting user visible
changes" in mind at some point after the patches have gone in, are
logically complete, and have been around long enough that major
catastrophes (i.e. those liable to incur a full revert) are likely to
have happened.

But I would like to stress.  While it is the Release Maintainer's job to
make sure this gets done, it is not the Release Maintainers job to write
it.  That is an unreasonable burden.

One approach would be to have someone / something (either the release manager, or an automated script) periodically (monthly?  Bi-weekly?) email each maintainer a list of the commits under their remit, with an encouragement to consider what entries could be added to CHANGELOG.md.  i.e., something like this:

8<---

Dear $MAINTAINER_NAME,

During the last $TIME_PERIOD, the commits below have been checked into the tree which modify code under your maintainership.  Please ensure that necessary changes to CHANGELOG.md have also been comitted.

Thanks,

 $SENDER

$GIT_LOG

---->8

Ideally this would prompt maintainers to get into the habit of always asking for CHANGELOG entries to be added during review (which would also get developers into the habit of always including them); at which point the maintainers could just skim the commits in the email and only add he odd CHANGELOG that they may have forgotten.

Thoughts?

 -George