Re: FYI: GDB 7.10.1 release still planned end of Nov

[Joel Brobecker <brobecker@adacore.com>]

> >>   [patch] fix misparsing in remote_parse_stop_reply
> >>   https://sourceware.org/ml/gdb-patches/2015-08/msg00413.html
> >>
> >>Sandra, could you handle that one?
> >
> >No answer from Sandra, but I've added it to the the Wiki.
> >Sandra - if you want to push it to the branch, remember that
> >we need to recreate a PR for it. For now, I've replaced the PR
> >numbers by ??? in the GDB 7.10 release wiki page...
> 
> I thought I did respond to this.  I'm confused enough by GIT to not know
> what the right way to backport a patch from trunk to a release branch is, or
> how much re-testing is required, and now I'm even more confused by
> "recreating a PR" and the comments about a wiki since I'm not familiar with
> GDB's release management processes either.  :-S  If you can give me more
> specific instructions I will help, but maybe it would be just as easy for
> someone who knows what they're doing to handle it?

I am usually happy doing the grunt work for someone else, but because
it doesn't scale, I usually offer it once to each contributor ;-).

The reason we need a PR is that it makes documentation of the corrective
release a lot easier. Here is how the process works, in a nutshell
(this only applies after a first release has been made on a given
branch - in other words, it only applies to "corrective" releases):

  - For a fix that needs to be put on the branch, there must be
    a PR. If not already existing, then it needs to be created at:

    https://sourceware.org/bugzilla/

    This PR should document in as much details as possible the issue.
    You can also hyper-link discussions on gdb-patches.

    This requires an account, but that's trivial to create.

  - We maintain the list of fixes on the branch via a wiki page.
    There is one page for each release branch, available from
    GDB's wiki main page (https://sourceware.org/gdb/wiki/).
    For the GDB 7.10 release cycle, the wiki page is at:

    https://sourceware.org/gdb/wiki/GDB_7.10_Release

    This also requires an account, as well as write privileges,
    which anyone with write privs (including myself) can give you.

    But in this case, I've already added the entry in the wiki.
    I'm just missing the PR number.

  - Come release time, I copy/paste the list of fixes we pushed
    to the branch in the announcement. For the news entry on the GDB
    website, I provide hyperlinks to each PR, so people only have
    to click on them to access a more comprehensive description of
    each issue being solved by the corrective release. For the email
    sent to gdb-announce, it's pure text, but the PR number makes it
    super easy to locate each PR, and therefore consult it as well.

Regarding backporting a change, it's super easy:

  1. Find the SHA1 of the fix you pushed to master; I usually use
     something like "git log --author=[...] --grep=[...]

     For instance, I did...

     % git log --author=sandra --grep=strprefix

     ... and got:

     commit 26d56a939e9e54e09d46ea6e9678463ac344fa33
     Author: Sandra Loosemore <sandra@codesourcery.com>
     Date:   Tue Aug 18 10:29:54 2015 -0700

         Fix mis-parsing of hex register numbers in 'T' stop replies.

  2. Then, create a gdb-7.10-branch branch in your repository:

        % git branch --track gdb-7.10-branch origin/gdb-7.10-branch

     You can then cherry-pick the change to that branch:

        % git checkout gdb-7.10-branch
        % git cherry-pick 26d56a939e9e54e09d46ea6e9678463ac344fa33
        [you will probably need to fix ChangeLog conflicts]

     And once all is ready, then just push to the FSF repo:

        % git push origin gdb-7.10-branch

-- 
Joel