Re: [maint] The GDB maintenance process

[Daniel Berlin <dberlin at dberlin dot org>]

On Sun, 23 Feb 2003, Eli Zaretskii wrote:

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

Sure, but it'll take me a few days to do so.
It's much harder to sort out fixes that repair breakage than it was to
compute stats on how long it takes to review patches.
>
> 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.
>
I doubt it would break a single important feature.

> > > 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.
Um, no, it doesn't.  I can't find any instances in the changelogs from the
past 2 years  of a non-target specific problem in a feature that was
introduced and then fixed.

Here's all the reversions and fixes caused by previous changes i can
findfrom the past 2 years:
I've annotated what feature each affected.
I've ignored clearly accidental checkins (IE those marked as accidental
and committed right after the accident), and documentation bugs (2
occurred).
>From ChangeLog:
        lost in the previous patch. (extremely small annotation bug)
        compilation error in the previous revision (hpread bug).
        failure introduced in the previous change (alpha gdbarch bug).
>From ChangeLog-2002
        valops.c, value.h: Revert previous change (Reversion of committing
	of objc stuff prematurely, not a feature breakage).
       * sh-tdep.c: Clean up code erroneously reintroduced by previous
	(SH-only bug)
        * kod.c (kod_set_os): Revert previous change.  Is called by ``info
(kod specific problem)
	  Fix last change to use regcache_collect instead of referencing
        registers[] directly (m68k-only bug).


Granted, i  just got new contacts and they are bothering my eyes, so i
only spent 30 minutes going over the changelogs, so it's possible i missed
one or two.

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

Sorry, i simply don't believe this.
Every piece of data we have shows exactly the opposite (that people have
abandonded 2.95 for 3.2.2 because of reliability reasons, and those that
stick to 2.95 are doing it not because of reliability but instead because
of speed).

I'd really like to know where you are getting this from.


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

Actually, that wouldn't help.  You can't forsee every bug, no matter what
you try.  Not releasing it wouldn't enable us to find more bugs, since we
don't have every piece of code in existence that g++ gets run on.
The likelyhood that 3.0 would have more bugs, no matter when we released
it, was very high, simply based on the nature of the changes.
There were numerous pretests, and numerous weeks of people simply doing
only bug fixing and ensuring that it was as bug-free as possible.
The patches that went into 3.0 received *more* review than patches that
went into previous releases received.

Therefore, maybe you'd like to explain exactly what should have been
done while we "refrained from releasing it", given that there were no high
priority  bugs left to fix, no major bugs left to fix that affected a
primary release platform, and no large bases of code that anyone had
access to failing to run properly, since I can't exactly see what more
you wanted done.

We can't fix unknown, unreported bugs, that don't occur for anyone doing
development, on any piece of code they have, until they are reported.
Most aren't reported until you release (even pre-tests  and snapshots
don't receive the same level of use, no matter how long you put them out
for).

--Dan