FYI: GDB 7.10.1 release still planned end of Nov

FYI: GDB 7.10.1 release still planned end of Nov

[Joel Brobecker]

Hello everyone,

Just a quick message to say that we're still planning a 7.10.1
release by end of next month. For now, there have been only
2 fixes pushed to the branch:

    * PR remote/18965
      (new vforkdone stop reply should indicate parent process ID)
    * PR gdb/18957
      (build failure in linux-namespaces.c due to setns static declaration)

If there are other fixes you'd like to be made on the branch for that
release, it's time to let us know by updating the wiki page used to
track the releases off that branch:

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

Please remember that *all* fixes pushed to the gdb-7.10-branch
require a corresponding bugzilla PR where we fill information on
the fix being made, and the wiki page above also needs to be updated
to reference that PR. This helps me quite a bit when I compose
the release announcement (thank you!).

Next reminder will be a couple of weeks ahead of the planned release.

Cheers :)
-- 
Joel

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

[Pedro Alves]

On 10/28/2015 04:47 PM, Joel Brobecker wrote:
> Hello everyone,
> 
> Just a quick message to say that we're still planning a 7.10.1
> release by end of next month. For now, there have been only
> 2 fixes pushed to the branch:
> 
>     * PR remote/18965
>       (new vforkdone stop reply should indicate parent process ID)
>     * PR gdb/18957
>       (build failure in linux-namespaces.c due to setns static declaration)
> 
> If there are other fixes you'd like to be made on the branch for that
> release, it's time to let us know by updating the wiki page used to
> track the releases off that branch:
> 
>     https://sourceware.org/gdb/wiki/GDB_7.10_Release

I think we should have this one in too:

  [patch] fix misparsing in remote_parse_stop_reply
  https://sourceware.org/ml/gdb-patches/2015-08/msg00413.html

Sandra, could you handle that one?

Thanks,
Pedro Alves

> 
> Please remember that *all* fixes pushed to the gdb-7.10-branch
> require a corresponding bugzilla PR where we fill information on
> the fix being made, and the wiki page above also needs to be updated
> to reference that PR. This helps me quite a bit when I compose
> the release announcement (thank you!).
> 
> Next reminder will be a couple of weeks ahead of the planned release.
> 
> Cheers :)
> 

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

[Joel Brobecker]

Hello,

Just a quick reminder - we are now 2 weeks away from our planned
date for 7.10.1.

> I think we should have this one in too:
> 
>   [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...

Thank you!
-- 
Joel

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

[Sandra Loosemore]

On 11/12/2015 11:44 AM, Joel Brobecker wrote:
> Hello,
>
> Just a quick reminder - we are now 2 weeks away from our planned
> date for 7.10.1.
>
>> I think we should have this one in too:
>>
>>    [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?

-Sandra

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

[Joel Brobecker]

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

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

[Sandra Loosemore]

On 11/12/2015 12:38 PM, Joel Brobecker wrote:

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

OK, I have created PR 19245 for this.

> 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

I'm really confused.  At this point, "git log" shows that my patch is 
already present in the checkout as commit 
e13cbb569965ee3baca2ad4801eeb910c2b2f03f, dated Tue Aug 18.

>          % git cherry-pick 26d56a939e9e54e09d46ea6e9678463ac344fa33
>          [you will probably need to fix ChangeLog conflicts]

...and "git diff" after this step only shows ChangeLog conflicts and no 
code changes.

>       And once all is ready, then just push to the FSF repo:
>
>          % git push origin gdb-7.10-branch

Is there something different I need to do here, did I screw up something 
in the recipe above, or is the patch really already present on the 
branch and you and Pedro just lost track of it?

-Sandra

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

[Andreas Schwab]

Sandra Loosemore <sandra@codesourcery.com> writes:

> I'm really confused.  At this point, "git log" shows that my patch is
> already present in the checkout as commit
> e13cbb569965ee3baca2ad4801eeb910c2b2f03f, dated Tue Aug 18.

That means you already backported it, back then.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Joel Brobecker]

> >   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
> 
> I'm really confused.  At this point, "git log" shows that my patch is
> already present in the checkout as commit
> e13cbb569965ee3baca2ad4801eeb910c2b2f03f, dated Tue Aug 18.
> 
> >         % git cherry-pick 26d56a939e9e54e09d46ea6e9678463ac344fa33
> >         [you will probably need to fix ChangeLog conflicts]
> 
> ...and "git diff" after this step only shows ChangeLog conflicts and no code
> changes.
> 
> >      And once all is ready, then just push to the FSF repo:
> >
> >         % git push origin gdb-7.10-branch
> 
> Is there something different I need to do here, did I screw up something in
> the recipe above, or is the patch really already present on the branch and
> you and Pedro just lost track of it?

You did good! What happens is that you backported the patch in time
for it to be part of GDB 7.10. I'll update the release wiki page, and
close the PR you opened.

Sorry about the confusion, and thanks for following up.

-- 
Joel