Re: [maint] The GDB maintenance process

[Daniel Berlin <dberlin at dberlin dot org>]

> > From: Daniel Berlin [mailto:dberlin at dberlin dot org]
> > Sent: Wednesday, February 19, 2003 3:24 PM
> >
> > > I guess I just don't see this to be as much of a problem as  others
> do.
> > > For one thing, with the higher entropy level, more development
> actually
> > > happens.
> > Bingo.
> > I don't think we should stall development (and in the
> > extreme,  even if
> > it means we can't make quality releases any day of the year) because
> > mistakes occasionally happen in patches, or because not every
> > maintainer in existence has said something about a patch.  That's a
> > recipe for no progress.
>
> For some definition of ``progress''.
>
> Who said that adding code at a faster rate at the price of having more
> bugs is more ``progress'' than what we have now?

Who said we'd necessarily have more bugs?
Can you back this up?

> There are people out
> there who need GDB to actually do something _useful_, not just to debug
> and/or develop GDB itself, you know.
You've assumed that it would make GDB completely unusable.
You know, it's funny you mention "people out there", since *every* GDB 
user i know not on the gdb mailing list is a desktop developer, working 
with C++ (KDE friends) or Java (Weirdo friends :P) , and yet these are 
*exactly* the portions of GDB that work least well.  It's almost as if 
our focus on what features are important is wrong.  But anyway, that's 
a rant for another time.
> What about frustration of those
> GDB users when their favorite feature is broken by some
> committed-before-review patch that adds a hot new feature?
> Does that
> ever count?

Does it ever happen?
I mean, seriously.
Ever?
I doubt it would have been suggested if anyone seriously though it was 
going to happen.
This isn't grade school anymore, we all know how to write good code.

> Does anyone remember that latest GCC releases are practically unusable
> for any production-quality work due to bugs?  Does anyone even care?
Latest?
There was *one* release that was like this, GCC 3.0.
And we *knew* it was going to be like this, because of the new ABI.  
You couldn't do much about it.
That's why 3.1 was planned as a completely "make it faster, fix bugs", 
not "add new features" release.


> I say thanks God for slower development of GDB.  At least I can _debug_
> buggy code produced by buggy development tools ;-)
>
> Of course, if contributors are frustrated by the slow review rate, 
> let's
> try to improve that (see my other mail).  But let's not obscure our 
> view
> of the problem by discussing abstract issues of ``progress''.  An
> official release every 3 months is more than enough progress for my
> taste.
Only if they contain some useful feature.