This is the mail archive of the
mailing list for the GDB project.
Re: FYI: GDB 7.10.1 release still planned end of Nov
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Sandra Loosemore <sandra at codesourcery dot com>
- Cc: Pedro Alves <palves at redhat dot com>, gdb-patches at sourceware dot org
- Date: Thu, 12 Nov 2015 11:38:49 -0800
- Subject: Re: FYI: GDB 7.10.1 release still planned end of Nov
- Authentication-results: sourceware.org; auth=none
- References: <20151028164757 dot GC4009 at adacore dot com> <5631005E dot 9070208 at redhat dot com> <20151112184430 dot GA4646 at adacore dot com> <5644E0A4 dot 8020901 at codesourcery dot 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:
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:
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:
Author: Sandra Loosemore <firstname.lastname@example.org>
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