This is the mail archive of the
mailing list for the GDB project.
Re: [maint] The GDB maintenance process
ac131313 at redhat dot com (Andrew Cagney) writes:
> Some noticeable differences between these two models:
> - In the GCC model, more people are able/likely to check in patches which
> break things.
> - But in the GCC model, more people are able/likely to check in patches to
> fix it afterwards.
The GCC model involves a number of development phases and the above
comments would only relate to one of those phases. At other times
increasingly strict controls are placed on what can be
committed/approved. The GCC group spend a significant (out of
control?) amount of their time trying to re-stablize GCC for their
For GDB, on the other hand, interesting development can and does get
approved/committed at any time. GDB snaps are of such quality that we
can confidently refer someone to current sources for fixes (except
when I have a bad day like today :-). Further, instead of using
official releases (and as you yourself have done) arbitrary snaps can
even make their way into a distro.
The problem is, being that stable has a cost associated with it. GCC
pays that cost at certain parts in their cycle; we pay that cost all
the time, every day.
GDB is less stable then you might think. Right now while both:
are causing problems they are not getting in the way of DavidC's dwarf2
stuff (gee wiz, both my doing :-/). GDB always builds, gdb always
`break main; run'. Is that too much to ask?
The problem with GDB's stability is that allows people to quickly forget:
- what it is like with out it
- how much gain there is from it
- how relatively small the pain
- how much more expensive it is to have to re-do something later
- how, with a bit of peer revew, problematic code could have been done
right the first time (and how much that fallout costs).