From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23751 invoked by alias); 17 Oct 2004 09:58:12 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 23744 invoked from network); 17 Oct 2004 09:58:11 -0000 Received: from unknown (HELO x93.infopact.nl) (212.29.160.93) by sourceware.org with SMTP; 17 Oct 2004 09:58:11 -0000 Received: from steven.lr-s.tudelft.nl (70-90.ipact.nl [82.210.90.70]) by x93.infopact.nl (8.12.10/8.12.10) with ESMTP id i9H9vt1A005208; Sun, 17 Oct 2004 11:57:55 +0200 From: Steven Bosscher Organization: SUSE Labs To: Mark Mitchell Subject: Re: [Committed] Use special-purpose hash table to speed up walk_tree Date: Sun, 17 Oct 2004 10:59:00 -0000 User-Agent: KMail/1.5.4 Cc: Jakub Jelinek , Matt Austern , GCC Patches References: <200410161217.43614.stevenb@suse.de> <4172086B.4080106@codesourcery.com> In-Reply-To: <4172086B.4080106@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200410171158.29730.stevenb@suse.de> X-CanItPRO-Stream: NoScan X-Spam-Score: undef - spam-scanning disabled X-Canit-Stats-ID: 1115471 - cfbac6457e67 X-Scanned-By: CanIt (www . canit . ca) X-SW-Source: 2004-10/txt/msg01366.txt.bz2 On Sunday 17 October 2004 07:51, Mark Mitchell wrote: > I don't think there is any such policy one way or the other. Certainly, > there is precedent for patches being approved offline. I know there is, and I think it's wrong. More eyes see more things. > Matt sent me the > patch, and it looked good to me. I didn't see any reason to test it on > other architectures. Well, we've have some pretty serious breakage a few times in the past few weeks. Already three times the cause of this breakage was that some patch wasn't tested on some architecture. So I see lots of reasons to require better testing for patches when the mainlne is in stage3. Can we make it a requirement that larger patches like this should be tested on three platforms when the mainline is in stage3? Gr. Steven Index: develop.html =================================================================== RCS file: /cvs/gcc/wwwdocs/htdocs/develop.html,v retrieving revision 1.52 diff -c -3 -p -r1.52 develop.html *** develop.html 11 Sep 2004 14:55:46 -0000 1.52 --- develop.html 17 Oct 2004 09:53:45 -0000 *************** back-end.

*** 123,140 ****

During this period, the only (non-documentation) changes that may be made are changes that fix bugs or new ports which do not require changes to other parts of the compiler. ! New functionality may not be introduced during this period.

Rationale

In order to produce releases on a regular schedule, we must ensure that the mainline is reasonably stable some time before we make the ! release. Therefore, more radical changes must be made earlier in the ! cycle, so that we have time to fix any problems that result.

In order to reach higher standards of quality, we must focus on ! fixing bugs; by working exclusively on bug-fixing through Stage 3, we ! will have a higher quality source base as we prepare for a release.

Although maintaining a development branch, including merging new changes from the mainline, is somewhat burdensome, the absolute worst --- 123,147 ----

During this period, the only (non-documentation) changes that may be made are changes that fix bugs or new ports which do not require changes to other parts of the compiler. ! ! In principle, new functionality may not be introduced during this period. ! However, the release manager may still allow patches in that add new ! functionality. Such patches should be validated on three different ! targets, each targeting a different microprocessor family, before the ! patch can be commited.

Rationale

In order to produce releases on a regular schedule, we must ensure that the mainline is reasonably stable some time before we make the ! release. Therefore, more radical changes must either be made earlier ! in the cycle, so that we have time to fix any problems that result, or ! very thoroughly tested, to reduce the risk of destabilizing the mainline ! as much as possible.

In order to reach higher standards of quality, we must focus on ! fixing bugs; by working almost exclusively on bug-fixing through Stage 3, ! we will have a higher quality source base as we prepare for a release.

Although maintaining a development branch, including merging new changes from the mainline, is somewhat burdensome, the absolute worst