From: Nick Roberts <nickrob@snap.net.nz>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb@sourceware.org
Subject: Re: DELAYED: GDB 6.7 branch creation scheduled June 25th
Date: Fri, 22 Jun 2007 07:23:00 -0000 [thread overview]
Message-ID: <18043.30976.871935.736190@kahikatea.snap.net.nz> (raw)
In-Reply-To: <20070622014101.GC18706@adacore.com>
> > These facts suggest to me that it's best to delay the branch, possibly by a
> > month or two, not backdate it.
>
> As far as I am concerned, the fact that we use backdating is unrelated
> to where we decide the branchpoint to be. I like backdating, because
> it allows me to put the head in maintenance mode for a couple of days
> while I work on the branch.
You've lost me. I thought the branchpoint is where the branch was cut.
>
> But what I do NOT want to do, is to delay the
> branch because we're waiting for the next fix, enhancement, etc, unless
> there is a compeling reason to.
The next enhancement can always wait for the next release but if there's a bug
that needs fixing, that needs to be done before the release. If you're saying
branch and then fix before the release, there doesn't seem much point in
testing until all the fixes are in. So where's the gain in branching early?
> In this particular case, I think we have more than enough material
> to start a new release. Just to verify my impression, I had a look
> at the NEWS file, and the "since 6.6" section is actually very long!
> And the great thing is that I know more are coming for the release
> following that one (which I hope we'll be able to call it GDB 7 :-).
Sure. I don't think anyone is saying that there haven't been enough changes.
--
Nick http://www.inet.net.nz/~nickrob
next prev parent reply other threads:[~2007-06-22 7:23 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-06-08 6:18 GDB 6.7 branch creation scheduled June 10th Joel Brobecker
2007-06-08 6:39 ` Nick Roberts
2007-06-11 1:23 ` Daniel Jacobowitz
2007-06-14 18:54 ` Thiago Jung Bauermann
2007-06-14 18:58 ` Daniel Jacobowitz
2007-06-14 23:42 ` Joseph S. Myers
2007-06-21 18:13 ` DELAYED: GDB 6.7 branch creation scheduled June 25th Joel Brobecker
2007-06-21 18:22 ` H. J. Lu
2007-06-21 21:47 ` Nick Roberts
2007-06-22 1:39 ` Joel Brobecker
2007-06-22 7:23 ` Nick Roberts [this message]
2007-06-22 16:16 ` Joel Brobecker
2007-06-23 0:08 ` Nick Roberts
2007-06-23 0:34 ` Joel Brobecker
2007-06-23 0:58 ` Nick Roberts
2007-06-23 1:22 ` Joel Brobecker
2007-06-23 1:43 ` Nick Roberts
2007-06-23 4:44 ` Joel Brobecker
2007-06-24 0:44 ` Nick Roberts
2007-06-24 1:57 ` Daniel Jacobowitz
2007-06-25 23:54 ` Joel Brobecker
2007-06-26 19:00 ` Joel Brobecker
2007-06-26 19:15 ` Markus Deuling
2007-06-23 12:33 ` Daniel Jacobowitz
2007-06-22 20:14 ` Stan Shebs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=18043.30976.871935.736190@kahikatea.snap.net.nz \
--to=nickrob@snap.net.nz \
--cc=brobecker@adacore.com \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox