Re: [Committed] Use special-purpose hash table to speed up walk_tree

[Steven Bosscher <stevenb at suse dot de>]

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.</p>
*** 123,140 ****
  <p>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.</p>
  
  <p><strong>Rationale</strong></p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>Although maintaining a development branch, including merging new
  changes from the mainline, is somewhat burdensome, the absolute worst
--- 123,147 ----
  <p>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.</p>
  
  <p><strong>Rationale</strong></p>
  
  <p>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.</p>
  
  <p>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.</p>
  
  <p>Although maintaining a development branch, including merging new
  changes from the mainline, is somewhat burdensome, the absolute worst