Re: GCC 3.3, GCC 3.4

[Joe Buck <jbuck at synopsys dot com>]

On Thu, Jan 30, 2003 at 06:13:13PM -0600, Benjamin Kosnik wrote:
> Shipping GCC 3.3.0 on March 1 will require enormous effort. 

I would agree; this really seems like a stretch.

The more QA-oriented among us are currently working on making
sure that 3.2.2 is reasonably clean, and I don't see why the public
*needs* another bump less than a month later.  Why not take more
time and do it right?  A March 1 date would probably mean only
three more weeks for bug-fixing.  I wouldn't ask for a big delay,
but I'd prefer a bit more time to do it right.

> Well, me too. However, I expected the SC to show more leadership on this
> issue. I'm disappointed by the current lack of policy. Matt had brought
> up this issue when the quick, "oops" 3.2.0 release was made. Now I
> see the wisdom of his comments.

We're set up at present to have an SC that does as little as possible,
leaving it to the RM for the most part to drive releases, with input from
people on the development list.  About half of the SC is pretty much
inactive, busy with other things.  It's this way on purpose, to minimize
the issue of having a secret cabal.  The idea is that technical decisions
are in the open, on this list, as far as possible, and the SC deals with
the FSF relationship, the people issues if they come up, discussion of
code we have to rewrite because we don't have clear rights to it, things
like that, though occasionally issues with technical content come up.
Sometimes there are no messages on the SC mailing list for weeks at a
time, and things tend to be more interrupt-driven than they should have
been; it was kept too vague for a long time as to whether there would be
a 3.2.2 release.

> I've versioned the runtimes assuming that 3.3 will not break the 3.2
> ABI, and that 3.4 will. Lacking clear guidance on what to do, I think
> this was an ok decision.

No decision is really final until we've made a release, so it's an OK
decision even if we have to revisit it.

> I think the longer gcc, as a project, goes on without an autobuild
> continuous regression checker, the worse off things will get. It was
> nice of Red Hat to initially support this effort, but it is obvious that
> this time is past as the regression checker is long dead. Somebody else
> will have to step up with the bandwidth, time, and machine to do this.

Agreed.  It may be easier to get someone to donate the bandwidth/machine
if we can hand them a relatively-easy-to-setup hunk of software and just
ask them to run it.

> Some of these frustrations are with the development process, and have
> nothing to do with you or the SC. Please keep in mind that I have the
> utmost respect for both you and the SC.

> best,
> benjamin

-- 
Q. What's more of a headache than a bug in a compiler.
A. Bugs in six compilers.  -- Mark Johnson