This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [maint] The GDB maintenance process
> Date: Sat, 22 Feb 2003 20:57:32 -0500 (EST)
> From: Daniel Berlin <dberlin at dberlin dot org>
>
> > > > 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).
Be sure not to miss entries like this:
(dwarf2_build_frame_info): Corrected handling of eh_frame.
or this:
* dwarf2cfi.c (context_cpy): Copy registers correctly.
or this:
* symfile.c (add_filename_language): Fix wrong xrealloc size argument.
It is my personal impression that a very large portion of GDB
development is devoted to fix bugs in existing code. Perhaps my
impression is somehow lopsided, I don't know.
> > 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).
[Who are ``we''?]
> I'd really like to know where you are getting this from.
I'm getting this from my daily work. Perhaps we write different types
of software. I work for a large firm that develops software in C that
needs to be extremely reliable. As long as people can break programs
by recompiling them with latest GCC versions, while it runs fine with
GCC 2.x (I still have 2.7.2.1 around, by the way), GCC 3.2.x will be
suspect as far as I'm concerned. Sorry, can't tell more: I cannot
afford being a GCC hacker in addition to being a GDB hacker, an Emacs
hacker, and a Texinfo hacker (to name just a few).
> > > 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.
Yes, we all know the theory: there's a fine balance to strike between
reliability and development pace. To me, the point where GCC cuts it
is a wrong one.
But I don't want to argue about GCC development too much. We are
discussing GDB, not GCC. I only mentioned GCC because it was used by
others in this thread to compare against GDB.