Re: proposal for branch patches after first release

[Eli Zaretskii <eliz at gnu dot org>]

> Date: Thu, 29 Nov 2012 22:04:40 +0100
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, gdb-patches@sourceware.org
> 
> > > 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 post all patches here, most of them undergo a review before being
pushed, so we could keep an eye on that.  CVS allows one to change the
commit message, so we could do that retrospectively if someone forgets
(unless the git conversion will become confused by such changes).

If we keep these records on  ChangeLog, the fix is even simpler: just
make another commit with a proper description.

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

This is an argument in favor of ChangeLog.

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

This, too, would be fine with me.