From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24704 invoked by alias); 23 Jan 2002 20:52:29 -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 24657 invoked from network); 23 Jan 2002 20:52:28 -0000 Received: from unknown (HELO localhost.cygnus.com) (216.138.202.10) by sources.redhat.com with SMTP; 23 Jan 2002 20:52:28 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id 1010D3C81 for ; Wed, 23 Jan 2002 15:52:27 -0500 (EST) Message-ID: <3C4F228A.4010803@cygnus.com> Date: Wed, 23 Jan 2002 12:52:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.7) Gecko/20020103 X-Accept-Language: en-us MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: GDB 5.2 et.al. release schedule Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-01/txt/msg00271.txt.bz2 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. 01 Jan - 5.1.1 02 Feb - branch (5.2) 03 Mar - release (5.2) 04 Apr 05 May - 5.2.x? 06 Jun - branch (5.3) 07 Jul - release (5.3) 08 Aug 09 Sep - 5.3.x? 10 Oct - branch (5.4) 11 Nov - release (5.4) 12 Dec . . . Oh, I'm never going to do a sub-sub release again. As I've now learnt, they end up wasteing everyones time. Instead, respins will always come from the head but may need to occure with little notice. 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. Another is a 3 month schedule, ulgh. comments, thoughts, suggestions etc, Andrew PS: If this is agreed to, I'll add it to cron so that no one can forget :-)