From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3751 invoked by alias); 3 Feb 2003 21:31:52 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 3744 invoked from network); 3 Feb 2003 21:31:52 -0000 Received: from unknown (HELO igw2.watson.ibm.com) (129.34.20.6) by 172.16.49.205 with SMTP; 3 Feb 2003 21:31:52 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h13LVDo42848; Mon, 3 Feb 2003 16:31:13 -0500 Received: from makai.watson.ibm.com (makai.watson.ibm.com [9.2.216.144]) by sp1n293en1.watson.ibm.com (8.11.4/8.11.4) with ESMTP id h13LVA653988; Mon, 3 Feb 2003 16:31:11 -0500 Received: from watson.ibm.com (localhost [127.0.0.1]) by makai.watson.ibm.com (AIX4.3/8.9.3/8.9.3/09-18-2002) with ESMTP id QAA24988; Mon, 3 Feb 2003 16:31:10 -0500 Message-Id: <200302032131.QAA24988@makai.watson.ibm.com> To: Mark Mitchell cc: Benjamin Kosnik , "tromey@redhat.com" , "jbuck@synopsys.com" , "gcc@gcc.gnu.org" Subject: Re: GCC 3.3, GCC 3.4 In-Reply-To: Message from Mark Mitchell of "Mon, 03 Feb 2003 13:06:36 PST." <63230000.1044306396@warlock.codesourcery.com> Date: Mon, 03 Feb 2003 21:31:00 -0000 From: David Edelsohn X-SW-Source: 2003-02/txt/msg00131.txt.bz2 >>>>> Mark Mitchell writes: Mark> --On Monday, February 03, 2003 03:01:51 PM -0600 Benjamin Kosnik Mark> wrote: >> On 03 Feb 2003 13:32:38 -0700 >> Tom Tromey wrote: >> >>> This sounds good to me. What's the next step? Maybe suggest a patch >>> to the development plan? >> >> Sounds good to me. Mark> It doesn't sound that good to me. Mark> That's basically a feature-driven approach -- "we want these new Mark> features". The problem with that is that we have no way of knowing Mark> whether people will actually do the work to implement the features Mark> or not. To a large extent, this is where we were way-back-when Mark> before 3.0; we tried to wait until stuff got done, it always took Mark> longer than anyone expected, while we were waiting other people Mark> wanted to add in more stuff, that other stuff was buggy, etc. Mark, redefining a proposal and then arguing against it is fallacious reasoning. That is exactly what you are doing. I never suggested extending the schedule indefinitely. Either extreme of schedule driven or feature driven development causes grief. We need to find a flexible middle ground. I think our current schedule places developers in a catch-22 situation that is discouraging and demoralizing. Again, accomodating developers both frees up more developers to fix bugs in the current release branches and encourages those developers to fix bugs in the next release branch so that their improvements are available in a release. Currently the development process discourages developers and creates the small pool of people fixing bugs, about which you have complained. The current policy is part of the problem. GCC releases already are delayed because of regressions and PRs, so allowing a longer window for integrating recommended goal features will not make it worse if the same developers are able to help with bug fixes. David