This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [maint] The GDB maintenance process
- From: Jim Blandy <jimb at redhat dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: 18 Feb 2003 22:42:21 -0500
- Subject: Re: [maint] The GDB maintenance process
- References: <20030218042847.50F2E3CE5@localhost.redhat.com>
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.
Sure, it's nice being able to grab an arbitrary GDB snapshot and
distribute it. But the rules which give us that property also slow
GDB's development into a more capable system. The decision to pay
that particular price for that particular benefit is what we want to
open up for discussion.
Stability needs to be balanced with progress in features; although I'd
hate to see it go too far towards the latter, I think the balance we
have now is tipped too far in favor of the former.