On Mon, Jan 30, 2023 at 3:54 PM Andrew Cooper <am...@srcf.net> wrote:
> On 27/01/2023 11:40 am, Henry Wang wrote: > > Hi Andrew, > > > >> -----Original Message----- > >> From: Andrew Cooper <andrew.coop...@citrix.com> > >> Subject: [PATCH] Changelog: Add details about new features for SPR > >> > >> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> > > Thanks for remembering this :) > > > > Acked-by: Henry Wang <henry.w...@arm.com> > > 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
