Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!DSYS.NCSL.NIST.GOV!rbj
From: rbj@DSYS.NCSL.NIST.GOV (Root Boy Jim)
Newsgroups: gnu.gcc
Subject: Reliability
Message-ID: <8906190427.AA05367@dsys.ncsl.nist.gov>
Date: 19 Jun 89 04:27:48 GMT
Sender: daemon@tut.cis.ohio-state.edu
Distribution: gnu
Organization: National Institute of Standards and Technology
	formerly National Bureau of Standards
Lines: 29

? Already I have been doing longer periods of pre-tests before each
? release, with more pre-testers.  But this doesn't seem to be enough.

? So I am considering separating off GCC version 1, which would be
? maintained for bug fixes only, from a new version 2, in which the new
? features such as instruction scheduling and so on would be added.

Perhaps you could go thru a cycle of features/bug releases. It has
been said that the 4.x BSD releases were feature releases for even x
and bug fix/performance releases for odd x. You could even use a longer
cycle; in the version X.YZ, the Z would be the reliability factor.
Nifty features could be added for say, Z in {0-3}, minor ones in
{4-6}, only fixes in {7-9}.

? This would probably mean a considerable delay in getting those
? features into distribution, but that might be worthwhile if version 1
? becomes more solid.  The final merge with G++ would also be put off
? for version 2.

In that case, wait until the merge happens.

? Meanwhile, I very much need the help of someone who understands the
? X server well enough to find the compilation error if GCC should fail
? to compile it properly.

It ain't me babe.

	Root Boy Jim is what I am
	Are you what you are or what?