Re: Beyond GCC 3.0: Summing Up

[jlarmour at redhat dot com (Jonathan Larmour)]

In article <337540000.994743670@warlock.codesourcery.com> you write:
>
>Certainly, when a new major change goes in, we have to accept
>some medium-term breakage.

Good. Unless there is some tolerance that allows such changes to go
in, you simply won't get any major changes.

>But, we should minimize that by the other
>part of my proposal that required three build/test platforms for
>changes that are big.

This raises the bar for amateur developers. This will effectively
mean that only corps like e.g. Codesourcery, Red Hat or ACT
can contribute major changes. Amateur developers such as those in
universities who rely on resources beyond their control may simply
not *have* three platforms.

It would be bad to make it a matter of *policy* that major changes
can only be contributed by those with access to a wide variety of
platforms.

>The basic problem is that there are tons of changes to GCC, and if
>each them makes the compiler better, but breaks just a couple of
>things, we quickly end up with a research compiler, not a production
>compiler.  In particular, the compiler can do everything, and very
>well, but no actual programs actually work and no actual developers
>can actually use it.  We have to stem the tide before it begins.

That sounds like the difference between a development branch and
a release branch to me. Having more frequent release cycles would
result in less chance of regressions building up. Why not try that
first before taking a further step that may be detrimental to
both the level of contributions and the advancement of the compiler.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine
Come to the Red Hat TechWorld open source conference in Brussels!
Keynotes, techie talks and exhibitions    http://www.redhat-techworld.com/