Re: [maint] The GDB maintenance process

[Daniel Jacobowitz <drow@mvista.com>]

On Wed, Feb 19, 2003 at 11:19:07AM -0500, Andrew Cagney wrote:
> >ac131313@redhat.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.
> >
> >>
> >>(ROFL.)
> >>
> >>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
> >>releases.
> >>
> >>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:
> 
> - interps
> - frame
> 
> 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?

Of course not.  If someone breaks that, they (or we) fix it quickly. 
GCC's no different.

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

I don't see where any of this is coming from.  As you point out above,
in a lot of respects GDB isn't all that stable.  What are we risking
here?

It also seems that Jim and I don't agree that the gain outweighs the
pain.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer