Re: [maint] The GDB maintenance process

[Michael Elizabeth Chastain <mec at shout dot net>]

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