Re: GCC 3.1 Release

[Bryce McKinlay <bryce@waitaki.otago.ac.nz>]

David O'Brien wrote:

>>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.
>>
>
>IMHO more things should be committed to the release branch.
>Everything is "time-consuming", there isn't much one can do about it when
>making releases of software.  Only toy, personal hacks are
>"time-consuming" and require effort.
>

I am speaking from a maintainer perspective. As long as we are 
maintaining a branch I have to maintain a separate branch tree and 
apply, build, test, and commit each patch independently. This is partly 
CVS's fault for not making it easier to merge changesets between branch 
sets. It also doesn't help that CVS runs so slow when working with the 
branch (btw why does it take < 30 sec to do a full "cvs update" on the 
mainline, but sometimes up to half an hour on the branch?)

But, I totally agree with you that more stuff should go on the branch 
and this is something I think us GCJ developers are going to try and do 
this time around, despite the hassle involved.

>>Perhaps we could go by a stable/unstable release cycle, similar to 
>>Linux.
>>
>
>Please no.  I really feel this will make it harder for those producing
>products that need to include a compiler.
>

Why? Presumably, BSD and Linux distributions would stick with the stable 
releases for their default compilers. The unstable releases would be for 
people who want to try out new features and optimizations without having 
to deal with CVS trees and snapshots which may not work at any given 
moment. It would be very nice to point people who are looking for new 
Java features (for example) at something that is known to at least 
somewhat work.

regards

Bryce.