From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4503 invoked by alias); 22 Jun 2007 07:23:55 -0000 Received: (qmail 4491 invoked by uid 22791); 22 Jun 2007 07:23:54 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 22 Jun 2007 07:23:52 +0000 Received: from kahikatea.snap.net.nz (191.63.255.123.dynamic.snap.net.nz [123.255.63.191]) by viper.snap.net.nz (Postfix) with ESMTP id 431AB3D98E4; Fri, 22 Jun 2007 19:23:50 +1200 (NZST) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id A86548FBF6; Fri, 22 Jun 2007 19:23:45 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18043.30976.871935.736190@kahikatea.snap.net.nz> Date: Fri, 22 Jun 2007 07:23:00 -0000 To: Joel Brobecker Cc: gdb@sourceware.org Subject: Re: DELAYED: GDB 6.7 branch creation scheduled June 25th In-Reply-To: <20070622014101.GC18706@adacore.com> References: <20070608061902.GP3761@adacore.com> <20070621181530.GC12173@adacore.com> <18042.61938.458913.398215@kahikatea.snap.net.nz> <20070622014101.GC18706@adacore.com> X-Mailer: VM 7.19 under Emacs 22.1.50.4 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-06/txt/msg00187.txt.bz2 > > 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