Re: [maint] The GDB maintenance process

["Eli Zaretskii" <eliz at is dot elta dot co dot il>]

> Date: Thu, 20 Feb 2003 10:16:46 -0500
> From: Daniel Berlin <dberlin at dberlin dot org>
> >
> > 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?

I think we have too many bugs already.  How about computing some
statistics about how many changes repair breakage made by previous
changes?

Committing unreviewed changes will necessarily make the situation
worse.

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

I didn't say that.  But breaking even a single important feature
could make someone out there totally helpless to find some bug.

> > 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?

Yes, it does.  A simple reading of the ChangeLog will show you.

> This isn't grade school anymore, we all know how to write good code.

Yes, we do.  But GDB's internals being as complex and not too
documented as they are, it doesn't surprise me that excellent
programmers still break things.

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

That was was simply broken.  But even the latest 3.2.x series are too
buggy for serious production-quality code, at least in systems where
reliability is a requirement.  People are still using 2.95.x for that
reason.

> And we *knew* it was going to be like this, because of the new ABI.  
> You couldn't do much about it.

Yes, you could.  You could refrain from releasing it.