Re: proposal for branch patches after first release

[Joel Brobecker <brobecker at adacore dot com>]

> > 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.

I agree it'd be pushing it for some commits (but I thought it'd
still be OK). Let's put that idea aside for now.

> > 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.

While I agree it's a good idea to move towards this principle,
and for both head & branch, I think there is too much of a chance
for oversights.

> 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>:
[...]
> 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".

Some of the commits in this release in fact did have a PR number,
and I was sometimes able to use that. But I noticed two issues:

  1. It takes time to process each commit, and then go through
     the various messages in the PR.

  2. Often, I will still have to look into the code itself to really
     figure out what the problem is. Take for instance PR gdb/14494
     (http://sourceware.org/bugzilla/show_bug.cgi?id=14494).  How
     do I quickly write up a description of the problem actually fixed?

I also think that having the information spread out, be it in
the revision logs, or in a bugs database, makes it hard for anyone
who wants to figure out what changes exactly a minor release
contains and for what purpose.

For all these reasons, I think that having the developer write up
the description himself, with approval from Eli, and put it somewhere
in a file, would be best. If we want to call it known-problems or
anything else, instead of putting that info in the NEWS files,
that would be fine as well.

-- 
Joel