This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [maint] The GDB maintenance process
On Wed, Feb 19, 2003 at 11:19:07AM -0500, Andrew Cagney wrote:
> >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.
> >
> >>
> >>(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