Re: GCC 3.1 Release

[David Edelsohn <dje at watson dot ibm dot com>]

>>>>> Bryce McKinlay writes:

Bryce> One could argue that the long cycle between 3.0 and 3.1 is partly 
Bryce> responsible for the 3.1 release problems, by allowing a longer period 
Bryce> for bugs to creep in before developer focus shifted to fixing them. I 
Bryce> think we should try for at least one release on the shorter cycle, with 
Bryce> an option to re-evaluate its effectiveness as the 3.2 release approaches
Bryce> or after it is made.

	One can arbitrarily divide the bugs into two categories:
regressions with testcases in the "torture" suite and regressions reported
through Gnats.  For the former, we all need to do better to fix
regressions as they occur.  For the latter, we sometimes do not get
immediate feedback about the failures or the failures are latent bugs not
directly caused by a change.

	Regressions and bugs are a byproduct of invasive changes to the
compiler.  If we are not creating and/or exposing bugs, we probably are
not improving the compiler substantially.

Bryce> Perhaps we could go by a stable/unstable release cycle, similar to 
Bryce> Linux. Unstable releases would follow a shorter period of 
Bryce> stabilization/freezing/testing/branching than is done for a full, stable
Bryce> release. This would give users wanting to test and play with new 
Bryce> features something which is known to be better tested than the average 
Bryce> snapshot, but without the pain and major disruption to development that 
Bryce> full releases seem to require.

	We are working on many different areas of the compiler
simultaneously.  Clearly new languages (such as Java and GCJ) would like
to have the rest of the compiler remain stable while it rapidly pushes
forward with more complete language support and ports to more platforms.
Other users want to see optimization improvements for existing languages.
Another community wants greater standards conformance for existing
languages.  It is hard to strike the right balance.  We need an open,
inclusive, constructive discussion to navigate a reasonable course.

	I conducted a survey about the GCC release schedule.  *NONE* of
the companies (Linux distributors, free software and open source projects,
embedded systems companies) wanted a release on a six month cycle.  No one
wants to have to transition and re-validate their software and repackage a
new distribution with great frequency.  Nine to twelve months is the
soonest that bulk end-users who create the dependence on GCC versions want
to be burdened with updating.

	If we want to remain on a six month cycle, alternating between
"technology preview" releases and "production" releases (e.g., GCC 3.0 and
GCC 3.1) would be a good plan, IMHO.  For that type of approach to work, I
think that we need to make every effort to ensure that radical, invasive
changes are merged into the mainline for even numbered releases so that
odd numbered releases are not substantially destabilized and developers do
not need to wait 18 months for their contributions to be accepted.  We
have a lot of good technology ready on branches and being offered by
developers that we need to figure out how to merge into the trunk for GCC
3.2.

Thanks, David