Re: Beyond GCC 3.0

[Joern Rennecke <amylaar at redhat dot com>]

> What kind of a shared testing environment does the GCC project have?
> I think a lot of the problems you describe would be resolved by running
> the regression suite on lots of platforms more frequently.  If the GCC
> project had 10 different boxes and ran the regression tests on all of them
> as fast as the boxes could turn it around, we would know about new bugs
> very quickly and they would not linger until the release crunch.  The boxes
> don't need to be in one place.  There must be lots of machines out there
> that are fairly idle and their administrators would be willing to add a cron
> job that pulls down the latest GCC, runs all the tests, and automatically
> reports the results back.

You can't run this as a background job on a hand-me-down.  The cycle
time on a fairly new machine is in the ballpark of one day.
Heavily multilibbed platforms can need a week or two to get through all
the tests.

> My second suggestion is for the source code control system (CVS).
> While at Bell Labs, we had a great source code control system called
> ECMS (it is now commercially available as Sablime).  It has a concept
> called an MR which is an ECMS object that keeps track of a group of
> changes that are logically related.  (For example, all the changes for a new
> register allocator would be on one MR.)  One file can be changed more
> than once on the same MR.  The second great featue was given MRs A,
> B, C, and D have been created (in that order), ECMS would let users extract
> a copy of the code that included any combination of these changes (MRs).
> For example, someone could get all changes for MR C, without getting
> changes for MRs A, B, or D.  This is very useful because you can run the
> regression tests on each MR independently, and not "approve" an MR until
> the tests pass.  ECMS is used by major software projects within Bell Labs,
> including some with more than 1000 developers.

I don't see how this differs from CVS branches.
To get all the changes from a branch into your local checkedout copy of
the source tree, you can use cvs update -j<branchpoint> -j<branchname> .

Of course, in gcc development you tend to see so many conflicts that
this becomes quickly unworkable.