Re: Beyond GCC 3.0

["H . J . Lu" <hjl at lucon dot org>]

On Wed, Jun 27, 2001 at 11:11:06PM -0700, Mark Mitchell wrote:
> 
> Lots of things go wrong:
> 

First I have to say the gcc developers have done a great job on gcc
3.0, given its complexity, platforms supported and new features added. 
Like any .0 releases of softwares like gcc, bugs are unavoidable,
including serious ones. In fact, you haven't seen nothing yet. Wait
until some Linux/xxxBSD distributions try to use gcc 3.0 to build a
whole Linux/xxxBSD distribution. I can guarantee that more bugs will
be found then. But I don't see anything wrong with it. Unless they
are reported, we may never know they even exist.

> 
> I think that we need a new method, one that gives better
> predictability for all:
> 
>   - Do a new release every six months.
> 
>   - Do bug fix releases two and four months after the major
>     releases, as required.

Unless I am mistaken, I don't think there should be a time constraint
on the bug fix releases. We know any gcc releaases can't be bug-free
for everyone. Every gcc release has bugs, some of which are critial to
some people. If we can make the bug fix branch relatively stable, what
is wrong to make a bug fix release everytime when there are enough bug
fixes checked in? Sure, it may have new bugs. But it does fix some old
ones. I don't think it is realistic to expect a release doesn't have
some new bugs. The question is how fast we fix them. If we make bug
releases more often, I think it will be much easier to discover/fix
those regressions.

>   - Patches that cause regressions, even on the mainline, must
>     be in the process of being fixed within 48 hours, or else can be
>     reverted by anyone with global write privileges, if they think
>     that's best. The idea is that you musn't check stuff in and then
>     leave problems lying around for a week.  This happenned more
>     than once in our 3.0 development cycle.
> 

I have been doing that on binutils for Linux. Sometimes you have
to trigger a binutils bug by compiling a particular package. I have
been yelling at people when they check in changes which break my Linux
system build. Sorry, folks :-). My Linux binutils is based on the
binutils main trunk and I have been making releases at least once
a month. The ideas are

1. The binutils main trunk won't break on Linux for more than a month.
2. When there is a regression, it is not too hard to track down which
change causes it.

My point is it is ok to make a release with unknown regressions. But
we should make a new bug fix release within a very short time period
after they are reported. I don't think two and four months are short
enough.

H.J.