Julian Foad wrote on Sat, 15 Dec 2018 20:47 +0000:
> Well, simply-scripted, I would say. I have no intention of adding
> another manual step to the backporting process. We already put manual
> effort into writing the backport nominations,
We do? I just run
./n r42 "Hello world"
and it nominates r42 with "Hello world" for its justification. That
uses 'ln -s ../trunk-wc/tools/dist/nominate.pl n'. (It needs so few
manual inputs because it uses the first line of the log message as the
first line of the nomination.)
> and sometimes issues, and eventually changelog entries.
Of these four --- log messages, STATUS entries, jira entries, and
CHANGES --- the latter is the only one that's explicitly written with
end users in mind; the others may use terms that users aren't familiar
with (e.g., "Fix a segfault in the reporter"). That's why I suggested
upthread to design this around CHANGES. (Not to mention the benefits of
reducing the RM's workload of writing CHANGES at release time...)
I assume this could be previewed using 'release.py write-changelog', but
don't have time to look up the exact incantation, sorry.
