This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Release 2.24
- From: Joel Brobecker <brobecker at adacore dot com>
- To: "Maciej W. Rozycki" <macro at codesourcery dot com>, Tom Tromey <tromey at redhat dot com>
- Cc: Tristan Gingold <gingold at adacore dot com>, Richard Sandiford <rdsandiford at googlemail dot com>, binutils at sourceware dot org, gdb-patches at sourceware dot org
- Date: Fri, 22 Nov 2013 06:19:04 +0400
- Subject: Re: Release 2.24
- Authentication-results: sourceware.org; auth=none
- References: <2741C968-721F-46E9-A2BA-E4B0F64C444B at adacore dot com> <BB32BE2A-A3CC-494C-9FB2-CFD322F49EA3 at adacore dot com> <alpine dot DEB dot 1 dot 10 dot 1309182134580 dot 4379 at tp dot orcam dot me dot uk> <20130918213245 dot GO3132 at adacore dot com> <alpine dot DEB dot 1 dot 10 dot 1309182238430 dot 4379 at tp dot orcam dot me dot uk> <alpine dot DEB dot 1 dot 10 dot 1311181646080 dot 21686 at tp dot orcam dot me dot uk> <20131118172117 dot GD3481 at adacore dot com> <alpine dot DEB dot 1 dot 10 dot 1311211718410 dot 21686 at tp dot orcam dot me dot uk>
> Although if you expect the delay between binutils 2.24 and GDB 7.7 to
> stay within a couple weeks, e.g. if you think you'll be able to roll the
> latter out by say mid December,
We might be able to achieve that timeframe, but it would be very hard
for me to guaranty it. From past experience, event if we started today,
I don't remember any release cycle that took less than a month so
we are already looking at a Xmas release at best.
Here is what I propose:
. Let's confirm the list of patches needed for the 7.6 branch
(is there just the one in binutils?)
. Get them approved, and pushed to the gdb_7_6-branch
. I will need from you a small description of what this release
is about. It will save me time and make sure I also don't say
something incorrect if I can just copy/paste that text directly
in the web + email announcements.
. Once that's done, I have 2 options:
(1) Create the new relase off the git repository, but create
the release either manually or with the new scripts;
(2) Push the commit to the CVS repo, and re-use the old
scripts to make the release.
If it's only a handful of patches, my preference would be to play it
safe, and go with option (2). Pushing the patches to the CVS repo is
super easy thanks to "git cvsexportcommit", but we will need the help
of someone like Tom to temporary re-open the CVS (or, if Tom prefers,
he can cvsexportcommit the patches himself, and let us know when he
is done).
Thoughts? Tom?
--
Joel