This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [maint] The GDB maintenance process

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
For one thing, with the higher entropy level, more development
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.
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?

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
Only if they contain some useful feature.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]