Re: GCC 3.1 Release

[Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>]

Toon Moene wrote:

>>>I have a proposal before the SC to slip the GCC 3.2 schedule even
>>>further; so that the first phase of GCC 3.2 development will now end
>>>one month  beyond the release of GCC 3.1 -- June 1st -- pushing the
>>>GCC 3.2  release date back to October 1st so as to give people time to
>>>work on major changes for GCC 3.2 *after* GCC 3.1 is released.
>>>
>>IMO this is still too short; I think there should be two months after
>>the previous release for the first phase, giving us an 8-month cycle
>>instead of a 6-month one.
>>

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

For GCJ, having more than 6 months between major releases is (IMO) an 
uncomfortably long time, given the rate at which it is moving. We find 
that a lot of bugs only get discovered after releases, but it becomes 
impractical to continue applying fixes to release branches because the 
mainline diverges quickly. Perhaps we should try to keep applying GCJ 
changes to release branches for longer, but to be always committing 
patches to two trees is quite time-consuming.

>Because then a whole group of "new" testers comes along and finds new
>bugs that we (and our "regular" testers) haven't found.  For 3.0 this
>effect was so bad that basically only the 3.0.4 release can be described
>as "generally useful".
>
>I do not have a good solution to that problem.
>

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

regards

Bryce.