Re: [Gdbheads] Let's resolve this quickly

[Ian Lance Taylor]

Elena Zannoni <address@hidden> writes:

> Ok. How often does this occur, i.e. how often does a problematic patch
> get checked in?

Well, you asked about a patch which needed to be reverted.  As I said,
that is probably less than once a month.  That is not the same as a
patch which needs to be fixed and adjusted in some way.

> I remember Zack Weinberg stating that gcc doesn't build about 30% of
> the times, based on doing a checkout on any random day.

I'd say that 30% is an overestimate on my experience, but it's true
that when gcc is in stage 1, it's fairly common that it fails to
bootstrap on some major architecture.

> I can vouch that this doesn't currently happen for gdb. I routinely do
> imports of FSF gdb into the Red Hat rpm and build it on 7 different
> architectures. It always built (at least it has in the past 1.5 year I
> have done so).

First, a gcc bootstrap is much easier to break than a gdb build,
because gcc is compiling itself.  If you only measure whether gcc
itself builds with an existing working compiler, which is the rough
equivalent of your gdb measure, then breakage is much less common,
although probably still non-zero.

Second, I actually don't think it is bad that the gcc bootstrap is
temporarily broken when gcc is in stage 1.  If gcc made it a critical
goal that gcc always bootstrap on major architectures after every
patch, then gcc development would measurably slow down.  It's OK that
gcc is broken temporarily, as long as it gets fixed.

I emphasize that the frequent breakage is only in stage 1, when
patches are generally permitted.  gcc goes through a three-stage
release process, as described on http://gcc.gnu.org/develop.html

There is, of course, a trade-off between stability and development.
If stability is emphasized above all else, then development is
inevitably slow.

Ian