Re: [maint] The GDB maintenance process

[David Carlton <carlton at math dot stanford dot edu>]

Here is some free-associating that I have about GDB's approval
process.  I'm not sure yet what I think about various concrete
proposals out there; I would like to see more existing models
discussed, because it seems unlikely to me that GDB's current model is
optimal (though, of course, what is?), and because recent history
seems to be full of interesting and potentially effective software
development models, models that I wish I knew more about.

* Overall, I'm quite happy with my experience working with GDB.  On
  the other hand, I suspect that various idiosyncracies in my
  situation make me a bit of an outlier in terms of ability and
  willingness to stick through the process.  It does seem to me that
  there have been other people's patches that would be valuable but
  that have died through lack of timely follow-through (whether by the
  approvers, by the submitters, or both, not to mention issues like
  copyright approval that we're unlikely to change).  The more people
  who are willing and allowed to help newcomers through this process,
  the better GDB will be.

* Sometimes the division of responsibility seems to me a bit strange.
  If I were a C++ maintainer, for example, it might drive me a bit
  bonkers having to wait for other people's approval for patches that
  only affect C++ but that are located in code that is in somebody
  else's domain.  (I was impressed with the way Daniel got the
  'demangling partial symbols' patch through.)

* The most serious strangeness of division of responsibility is having
  separate maintainers for the testsuite whose approval is required.
  We should do whatever we can to encourage people to write tests,
  whether to test new features or to fill in gaps in existing
  features; the more people who can approve tests, the better.  (I
  might be imagining things, but it seems to me like people have been
  frequently adding tests without waiting for approval recently; this
  seems like a good thing to me.)  It seems to me that, at the very
  least, anybody who can approve patches in a specific area should
  also be able to commit patches for tests in that area.  (Though of
  course it's good to, in addition, allow people to approve testsuite
  patches even if they can't approve non-testsuite patches: like I
  said, the more tests, the better.)

* Speaking of tests, the better the testsuite is, the less likely that
  patches will break things.  (Some currently popular development
  methodologies are rooted on this idea.)  On the other hand, there
  are good reasons (the history of GDB, its architecture, the test
  suite's architecture, and the nature of debuggers) that the
  testsuite's coverage will never be perfect, setting aside the issue
  that "not breaking behavior" isn't the same as "good".

* I have been impressed with GDB's stability.  Of course, it doesn't
  hurt that I'm using GDB on i686-pc-gnu-linux.  (Or that, frankly,
  I'm not a very heavy GDB user.)

* By temperament and programming style, I prefer to break up my
  patches into lots of small changes whose correctness should be
  relatively easy to verify.  Unfortunately, this means that it takes
  a long time for the sum of my changes to be approved.  For example,
  it's been more than 3 months since I posted a version of linespec.c
  that I think most people would agree was a significant improvement
  to its predecessor; I've submitted 14 patches to that file so far,
  with approximately an equal number to come.  I actually rather enjoy
  that process when it's going well - I log in each day, read my
  email, get an approval message for my latest patch, take a bit of
  time to generate and test my next patch, and then move on to
  something else - but it gets annoying when I have to wait for
  approval for simple, obviously correct patches.

  I've had a similar experience with cleaning up lookup_symbol_aux:
  there are bugs in that code, and I have patches to fix them, but I'm
  not sure when they'll make it into GDB.  I sigh with envy as I watch
  Andrew committing simple frame patch after simple frame patch
  without needing anybody else's approval.  A series of small patches
  like that can be a wonderful way to cleanse code.

* Continuing my last bullet point, however, it's not obvious to me
  that the changes in the approval process that Daniel suggests would
  help.  After all, there are already 3 people who can approve patches
  to linespec.c (so I'm certainly not mad at Elena - she's the only
  one taking time to actually approve the patches in question!), and I
  don't see why increasing that number would decrease the approval
  time.  So the obvious place to look for improvement is for me to
  change my behavior; I have some thoughts along those lines that I'm
  going to try to implement over the next few weeks.

* Having patches in the bug database is probably a good idea, but it
  means that somebody has to take the effort to put patches in the bug
  database.  It was great when Andrew cleaned out his mailbox and
  dumped it into the bug database; I'm not optimistic about the bug
  database working well for this in the longer term.

* Increasing the number of people who are familiar with a given
  segment of GDB's code can only improve GDB's health.  The current
  approval process seems to me to work against this, to some extent.

David Carlton
carlton@math.stanford.edu