From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20402 invoked by alias); 24 Jan 2002 00:37:32 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 20363 invoked from network); 24 Jan 2002 00:37:31 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 24 Jan 2002 00:37:31 -0000 Received: from drow by nevyn.them.org with local (Exim 3.33 #1 (Debian)) id 16TXth-00011S-00 for ; Wed, 23 Jan 2002 19:37:45 -0500 Date: Wed, 23 Jan 2002 16:37:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Re: GDB 5.2 et.al. release schedule Message-ID: <20020123193745.B3794@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com References: <3C4F228A.4010803@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3C4F228A.4010803@cygnus.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-01/txt/msg00276.txt.bz2 On Wed, Jan 23, 2002 at 03:52:26PM -0500, Andrew Cagney wrote: > See also: http://gcc.gnu.org/develop.html > > There have been plenty of concerns raised about the unreliability of the > GDB release cycle: 12 months, 18 months, ... I'm looking for more robust > ways of addressing this. (btw the 5.2 release manager role is still > available) (I promise not to break an arm again :-). > > In previous e-mail I've mentioned the intention to branch 5.2 mid Feb > and release it mid March. > > With those two points in mind, and looking across at GCC for idea's, I'd > like to propose that GDB have a more formal release schedule. > > I should note that GDB 5.1 established a new precident - it was released > with several targets (HP/UX, ALPHA) known to be broken. Being willing > to do this greatly simplified the task of the release person as they > should no longer feel guilty when documenting that certain > targets/natives just don't work. > > GCC's cycle is every 6 months. GDB could go for 12, 6, 4, or 3 months. > In the below I've somewhat arbitrarially chosen 4 months. That would > give three major and (possibly) three minor releases a year. I like it. And I agree with your comments about the iterative development process. > Looking at other release cycles, a 6 month schedule would better tie in > with GCC. While I'm open to opinion, my gut feeing is that the GCC > release schedule/model really don't map well onto GDB. GDB is far more > of an iterative development model and as such should encourage more > frequent releases. And we don't need to be tied to GCC. > PS: If this is agreed to, I'll add it to cron so that no one can forget :-) The possibilities are alarming... -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer