Re: proposal for branch patches after first release

[Pedro Alves <palves at redhat dot com>]

On 11/29/2012 09:04 PM, Joel Brobecker wrote:
>>> 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.

This would be about the equivalent of providing a git short log
on release announcements.  I guess we'll get there when we someday
switch away from cvs.

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

The idea is that you don't process the PRs at all.  You'd just give out
the numbers/summary, and perhaps an url.

Taking the e.g., of gcc's point release announcements, you'd get
something like:

GDB version 7.5.1 has been released.

GDB 7.5.1 is a bug-fix release containing fixes for regressions and serious
bugs in GDB 7.5.0, with over 20 bugs fixed since the previous release.  This
release is available from the FTP servers listed at:

  http://www.gnu.org/order/ftp.html

The list of bugs that have been fixed is:

    19745 - summary of PR (as recorded in bugzilla, and found by a simple search)
    22344 - gdb does foo when it should do bar

Or simply give a url to a search in bugzilla (or both).

(gcc release announcements don't list the bugs)

I've much ratter have more frequent and speedier point releases, than
worry about digesting the info too much.

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

People that have been affected by some bug supposedly should have
gone to bugzilla and filed a bug, or added themselves to the CC list
of an existing bug.  That's what makes me believe that taking the
effort of writing a distilled summary might be more effort than necessary.

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

If we go this path, I'd like to say my comment against using NEWS might
have come out stronger than I intended.  In the end, you're doing
the releases and the announcements.  Myself, I'll do whatever you
prefer.

-- 
Pedro Alves