Re: [maint] The GDB maintenance process

Michael Elizabeth Chastain
2003-02-24T05:29:48Z

Oh, man, what a thread.

I think it's hopeless to argue about the nature of gdb on a mailing list.
We all have opinions and are unlikely to change them. I think the best
we can actually do is craft proposals that are good in some people's
views, neutral in other people's, and aren't horrible in anybody's eyes.

My opinions:

. We need two or three test suite maintainers. I think we should
add some co-maintainers for the test suite right now, just as we
did for the gdb.c++ subdirectory.

. We have a problem integrating new contributors. This is tangled up
with the bigger problem that the doco for new contributors is
spread out over several places. I would like to tackle this
problem after the 5.4/6.0 release.

. The basic issue with patches is that they flow into our mailboxes
faster than they flow out. No patch management system can solve
this problem directly; it simply introduces new and fancier buffer
mechanisms. The only ways to solve it are to devote more resources
to patch review or find ways to review patches more quickly
(for example, flat out reject patches with the note "we don't have
the resources to review this").

. I am comfortable with a low degree of pre-commit testing as long as
we have healthy regression coverage AND people prioritize the
regression bugs in front of committing their next patch. For example,
I'd like someone to investigate pr gdb/1039. I don't want this kind
of stuff to build up. It's very easy for a developer to have a
never-ending stream of new stuff and never fix the problems introduced
by last week's stuff.

. My estimate of gdb regressions is that in the area I cover
(native i686-pc-linux-gnu) there is roughly 0.2 to 0.5 regressions
per week. See the gdb-testers archive and count "New Bugs Detected".

Michael C