From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26143 invoked by alias); 19 Feb 2003 06:05:09 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 26136 invoked from network); 19 Feb 2003 06:05:07 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by 172.16.49.205 with SMTP; 19 Feb 2003 06:05:07 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h1J657V26847; Tue, 18 Feb 2003 22:05:07 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: gdb@sources.redhat.com Subject: Re: [maint] The GDB maintenance process References: <20030217180709.GA19866@nevyn.them.org> From: David Carlton Date: Wed, 19 Feb 2003 06:05:00 -0000 In-Reply-To: <20030217180709.GA19866@nevyn.them.org> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-02/txt/msg00332.txt.bz2 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