Re: proposal for branch patches after first release

[Pedro Alves <palves@redhat.com>]

On 11/29/2012 04:14 PM, Eli Zaretskii wrote:
>> Date: Thu, 29 Nov 2012 15:14:15 +0100
>> From: Joel Brobecker <brobecker@adacore.com>
>>
>> The proposal:
>>
>>     Once a release has been published off a branch, any patch merged
>>     on the release branch requires a corresponding update in the
>>     NEWS file.
> 
> That'd be a nuisance, IMO, because some of them might be
> NEWS-unworthy.

I agree.  And this results in a bit awkward NEWS file, in that we don't
normally document bug fixes there, but point releases are usually
only about bug fixes.

> An alternative would be to require some predictably formatted string
> in the log entry or the commit message, which you then could grep for.

A one line at the head would be quite standard, given people have come
used to mail subject == git commit summary.  This might be the easiest,
though making this a "branch-only" requirement is very error prone.

I wouldn't mind at all enforcing better and more self-contained commit
log style, FWIW.

> Yet another alternative would be to have a separate file, which
> doesn't get into the tarball, with the relevant info, and request each
> commit to the branch be accompanied with an entry for that file.

We could also make better use of bugzilla for this.  I had stated my opinion
on this <http://sourceware.org/ml/gdb-patches/2012-11/msg00395.html>:

"(...) I'm thinking more and more that we could get better
release notes if all bugfixes had PRs filed for the correspondent bugs.
At release time, we could find them in bugzilla, and say "this is the list
of bugs that has been fixed".  Other projects do this in their release
announcements (glibc even maintains a lists of fixed PRs in their NEWS, but
I'm not suggesting that), and I personally find it useful and interesting."

But I don't think this one is mutually exclusive with the commit log idea.

If people think the PR idea is too process burden for mainline, we could
require this only for fixes that go into a release branch.  E.g., tag
the PRs with a special tag, e.g. "in-7.6.1".

-- 
Pedro Alves