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