From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12026 invoked by alias); 10 Jan 2004 00:11:38 -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 12019 invoked from network); 10 Jan 2004 00:11:37 -0000 Received: from unknown (HELO mail-out4.apple.com) (17.254.13.23) by sources.redhat.com with SMTP; 10 Jan 2004 00:11:37 -0000 Received: from mailgate3.apple.com (a17-128-100-68.apple.com [17.128.100.68]) by mail-out4.apple.com (8.12.10/8.12.9) with ESMTP id i0A0Bbhc011653 for ; Fri, 9 Jan 2004 16:11:37 -0800 (PST) Received: from relay3.apple.com (relay3.apple.com) by mailgate3.apple.com (Content Technologies SMTPRS 4.3.6) with ESMTP id for ; Fri, 9 Jan 2004 16:11:36 -0800 Received: from [17.219.197.129] ([17.219.197.129]) by relay3.apple.com (8.12.10/8.12.9) with ESMTP id i0A0BaIE020581; Sat, 10 Jan 2004 00:11:37 GMT Mime-Version: 1.0 (Apple Message framework v609) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <90200277-4301-11D8-BDBD-000A95B1F520@apple.com> Content-Transfer-Encoding: 7bit Cc: Caroline Tice From: Geoffrey Keating Subject: gcc 3.5 integration branch proposal Date: Sat, 10 Jan 2004 00:11:00 -0000 To: "'gcc@gcc.gnu.org'" X-SW-Source: 2004-01/txt/msg00578.txt.bz2 It looks like it's going to be quite some time before 3.4 branches and the mainline is opened up for general work. There are also a number of projects which are completed, or partially completed, and are waiting in branches and in people's private trees for 3.5 to open up to be committed. This has a number of bad effects: 1. People are having to maintain their own patches and/or branches and keep them up-to-date. 2. These patches and branches are not getting as much testing as they might, because the available testing effort is being spread over many places. 3. These patches and branches are not being tested with each other. I am concerned that this will cause great instability in the initial development of GCC 3.5, and will lead to delays in the release of GCC 3.5. I therefore propose to create a gcc-3.5-integration-branch. It will be similar in some ways to the 'basic-improvement' branch in the GCC 3.4 timeframe, but will have some significant differences. The proposed rules for the branch are: 1. This branch is for fully-tested, approved patches. The rules for committing to it are the same as the rules that apply during Stage 1 of GCC development. Experimental or incomplete work should not be put on the branch. 2. The intention is that immediately after GCC 3.4 branches, this branch will be merged back to mainline. 3. I will be making regular (probably weekly) merges from mainline onto this branch. I will be testing these merges with a powerpc-darwin native bootstrap. Anyone who commits anything to the branch that can't be fully tested with a powerpc-darwin native bootstrap should watch for the mail I send out saying the merge is done, and then run a test on their own platform and send the results to gcc-testresults. 4. Anyone who commits to the branch is still responsible for maintaining the patch on the branch: fixing regressions that it causes, and sometimes updating or reintegrating it after merges. I expect that for most patches, this will be much less work than maintaining the patch on their own. 5. I may back a patch out of the branch if it (a) causes bootstrap failure or significant regressions on any platform and the author doesn't appear to be able to fix it quickly, or (b) don't appear to have followed Rule 1 or Rule 3. Any objections to this proposal? If not, I'll create the branch in the next few days.