Right now we produce the CHANGES file by someone going through the log and
looking at the individual commits and coming up with the entries for CHANGES.
It's an after the fact process.
The problem with this is that it's not always obvious from commit messages what
the user impact is. I could probably find some examples but I'm not going to
bother to pick on anyone in particular. Ultimately, our commit messages are
for developers and the CHANGES entries are for users. There's a wide gap
sometimes between what goes where.
So I'd like to suggest that we start including a Changes field in the STATUS
file entries. I haven't exactly worked out the details so nobody needs to rush
out right now and start doing it immediately.
Since the people proposing the backport and the people voting for it usually
have the best idea of the impact it should improve the quality of our CHANGES file.
If a STATUS entry doesn't require a CHANGES entry (e.g. improvement to an
already merged change that wasn't released yet) then we can just ommit this
line. I can then simply search through the commit logs (since the backport.pl
includes the STATUS entries in the commit log when it commits) and find all the
CHANGES entries.
It'll still take some editing for consistency and style probably. But it'll be
a lot better in my humble opinion.
This of course does nothing to help producing the CHANGES file for a 1.x.0
release, because there are tons of changes going on trunk that do not ever get
backported. A huge thing that can help there is to start trying to describe
why a user would care about the commit and not just a developer. This is
something that I think we all can put a little bit more effort into on our
trunk commits that'll help us when we produce 1.9.0.
Received on 2013-08-30 00:20:55 CEST