This is the mail archive of the
mailing list for the GDB project.
Re: [maint] The GDB maintenance process
- From: David Carlton <carlton at math dot stanford dot edu>
- To: gdb at sources dot redhat dot com
- Date: 18 Feb 2003 22:05:06 -0800
- Subject: Re: [maint] The GDB maintenance process
- References: <20030217180709.GA19866@nevyn.them.org>
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.