From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23601 invoked by alias); 13 Jan 2004 22:41:43 -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 23593 invoked from network); 13 Jan 2004 22:41:43 -0000 Received: from unknown (HELO igw2.watson.ibm.com) (129.34.20.6) by sources.redhat.com with SMTP; 13 Jan 2004 22:41:43 -0000 Received: from sp1n293en1.watson.ibm.com (sp1n293en1.watson.ibm.com [9.2.112.57]) by igw2.watson.ibm.com (8.11.7-20030924/8.11.4) with ESMTP id i0DMfcA308352; Tue, 13 Jan 2004 17:41:38 -0500 Received: from makai.watson.ibm.com (localhost [127.0.0.1]) by sp1n293en1.watson.ibm.com (8.11.7-20030924/8.11.7) with ESMTP id i0DMfcl89432; Tue, 13 Jan 2004 17:41:38 -0500 Received: from makai.watson.ibm.com (localhost [127.0.0.1]) by makai.watson.ibm.com (AIX5.1/8.11.6p2/8.11.0/03-06-2002) with ESMTP id i0DMfbT28126; Tue, 13 Jan 2004 17:41:37 -0500 Message-Id: <200401132241.i0DMfbT28126@makai.watson.ibm.com> To: Geoff Keating , Mark Mitchell cc: gcc@gcc.gnu.org Subject: Re: gcc 3.5 integration branch proposal References: Date: Tue, 13 Jan 2004 22:41:00 -0000 From: David Edelsohn X-SW-Source: 2004-01/txt/msg00825.txt.bz2 >>>>> Geoff Keating writes: > Apple would like to use FSF releases. Unfortunately, a prerequisite > for this is that the FSF actually makes releases in a timely fashion, > and this is not happening. I want to make sure that we distinguish between timely and frequent. I have received private feedback that vendors would appreciate release dates that coincided better with a development plan schedule, but they do not necessarily want more frequent releases than what we currently are producing -- including the current slippage. It's the inability of vendors to plan any schedules around FSF GCC releases that is one of the problems, IMHO. Most GCC developers work for vendors who have their own schedules and own development priorities. If FSF GCC's development process better took those priorities into account, we might be able to get more help from those vendors to produce timely releases. I previously have suggested defining feature goals for GCC releases in conjunction with developers and vendors. If vendors need a feature in their own release, having that feature accepted and integrated into FSF GCC would motivate them to use FSF GCC and work to have FSF GCC released with that feature. We currently are spending so much time in feature-freeze mode and leaving patches proposing new features unreviewed, that vendors have no choice but to focus on their own source base. FSF GCC also has a very large and diverse user community who provide conflicting feedback about their priorities: * Correct code generation * Fewer ICEs * Standards conformance * Compilation speed * Performance * Features * Release frequency * Release timeliness We need to figure out how to balance those goals better without losing ground in areas where we recently have been improving. David