On Fri, Aug 30, 2013 at 12:26 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Fri, Aug 30, 2013 at 11:48:56AM +0200, Johan Corveleyn wrote:
>> At my workplace, we have a convention (enforced by pre-commit hook) to
>> use a prefix between square brackets ([U] for the user-facing text,
>> [S9] for the developer details (our team is called the "system9" team)
>> -> which also get extracted to another text file for an overview of
>> all the dev-messages of a single release). Here we could use something
>> similar to the contribulyzer syntax (for instance "Change: blablabla
>> (issue #1234)").
>
> I like this. No need for pre-commit enforcements, of course.
>
> We often don't know in advance which changes will be backported
> to a release. I guess we would have to delay updates to CHANGES
> until the moment tarballs are rolled. And instead of updating
> CHANGES manually we'd simply add or change 'Change:' annotations
> in log messages, and the release.py script would update CHANGES
> as necessary before tagging a release.
Why do it only for changes that will be backported? If you try to do
it immediately for every relevant change, you don't necessarily have
to come to it later, and both 1.8.x CHANGES and 1.9.0 CHANGES can be
extracted at any point.
Of course, there is always the difficulty of determining whether a
commit is relevant (and with which granularity you should document
your changes), but that problem is always there. Maybe it's a little
bit easier to answer the relevance question (and the concrete
phrasing) with some retrospect, but perhaps 90% can be done on the
spot, when you make the commit, and the other 10% can be filled in
later by editing the log message.
--
Johan
Received on 2013-08-30 12:45:25 CEST