From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32075 invoked by alias); 20 Feb 2003 16:39:38 -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 32067 invoked from network); 20 Feb 2003 16:39:38 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 20 Feb 2003 16:39:38 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 475352ED1; Thu, 20 Feb 2003 11:44:20 -0500 (EST) Message-ID: <3E5505E4.10805@redhat.com> Date: Thu, 20 Feb 2003 16:39:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD i386; en-US; rv:1.0.2) Gecko/20030217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew Cagney Cc: Daniel Jacobowitz , Zaretskii Eli , Daniel Berlin , Elena Zannoni , gdb@sources.redhat.com Subject: Re: [maint] The GDB maintenance process References: <4D19136444628A40840EFE8C5AE04147017A44@ELTIMAIL1.elta.co.il> <20030220145817.GA28816@nevyn.them.org> <3E54FBBF.2030203@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00421.txt.bz2 > Of course, if contributors are frustrated by the slow review rate, let's > try to improve that (see my other mail). But let's not obscure our view > of the problem by discussing abstract issues of ``progress''. An > official release every 3 months is more than enough progress for my > taste. > > > Not if there's nothing much new in it. Which is a bit of an > exaggeration, before anyone calls me on it - but still pretty well > expresses my point. > > It is closer to 6 months. The releases are not tied to specific new features (as that is consistently a schedule derailing disaster). Even with that time frame the releases consistently contain significant new features or fixes. > > The next release, for instance, will contain a significant upgrade to MI. That is critical to the GNU project and GDB. It will also contain objective C. Depending on how long this debate drags out for, it will also contain remote file I/O, remote gprov/gcov, Motorola's SPE and Altivec simulators, .... > > (at a less visible level, it also contains a rewritten frame and register framework) PS: Hmm, this makes me think of `boiled frogs'.