From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24256 invoked by alias); 22 Jun 2007 01:39:20 -0000 Received: (qmail 24246 invoked by uid 22791); 22 Jun 2007 01:39:19 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 22 Jun 2007 01:39:17 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id AE8C62AA5DF; Thu, 21 Jun 2007 21:39:15 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id PY0tfuGdgiaS; Thu, 21 Jun 2007 21:39:15 -0400 (EDT) Received: from joel.gnat.com (unknown [70.71.0.212]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTP id 712012AA5DB; Thu, 21 Jun 2007 21:39:15 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id EF932E7B51; Thu, 21 Jun 2007 18:41:01 -0700 (PDT) Date: Fri, 22 Jun 2007 01:39:00 -0000 From: Joel Brobecker To: Nick Roberts Cc: gdb@sourceware.org Subject: Re: DELAYED: GDB 6.7 branch creation scheduled June 25th Message-ID: <20070622014101.GC18706@adacore.com> References: <20070608061902.GP3761@adacore.com> <20070621181530.GC12173@adacore.com> <18042.61938.458913.398215@kahikatea.snap.net.nz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18042.61938.458913.398215@kahikatea.snap.net.nz> User-Agent: Mutt/1.4.2.2i 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/msg00183.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. > I guess I'm used to Emacs where the freeze alone lasted for three > years (which _is_ ridiculous) but where does the pressure come from > for such a prompt release? There is no hard pressure; actually, no pressure at all, as far as I am concerned. But having a rough schedule helps us have structure. The sense of promptness is relative. I personally like releasing often. In my sense, GDB has enough material to be released twice a year, others mentioned that they would like more frequent releases. In any case, if it turns out that at one point we feel that we haven't done enough when comes the time to start preparing the next planned release, then for sure we'll just delay it. 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. 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 :-). -- Joel