Re: [Gdbheads] Let's resolve this quickly

[Elena Zannoni]

Ian Lance Taylor writes:
 > 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 found the article:
http://www.codesourcery.com/publications_folder/a_maintenance_programmers_view_of_gcc

And the data:
http://gcc.gnu.org/ml/gcc/2001-03/msg01319.html

It is not that recent, it would be interesting to see how things are
going now.

 > > 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.

They were talking about bootstrapping, turns out.

 > 
 > 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
 > 

Yes, there is a compensating mechanism in the sense that if more
entropy is introduced all at once, then you need some time exclusively
devoted to stabilize that. Definitely it would not be acceptable to
have gcc always be in stage 1. 

Just for discussions sake, if the 3 stages are each 1 month long, you
need a total of 3 months to get something significant in and stabilize
it.  Maybe it would be worth doing some case studies about whether a
more incremental approach to include the same feature, like we do in
gdb, would have taken also 3 months.

I.e. there are two approaches, either you are more restrictive and
careful when you check stuff in, or you need to stabilize later on.
Either way, there is a cost associated with change. Whether you are
putting the cost upfront when you check stuff in, or later on when you
stabilize it, the cost is there.

This tradeoff is not only about when the work is done, but potentially
also about who does it.  If you put the effort upfront, the persons to
do the work are very likely going to be the contributor and the
reviewer. If you do the work later, it will be also left to others to
do.

I am probably pointing out the obvious, but I haven't seen anybody
esplicitly talking about this.  The impression I have is that the gcc
model is felt to be a silver bullet to solve all of gdb's problems.
If we go that way, we need to be clear that the grass is not that
green there either, and I'd like to think we chose with our eyes open.

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

Vice versa, of course, if you have too much instability you still end
up with slow development because more time would be required to
recover.

elena