From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4029 invoked by alias); 24 Feb 2003 05:29:48 -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 4022 invoked from network); 24 Feb 2003 05:29:47 -0000 Received: from unknown (HELO duracef.shout.net) (204.253.184.12) by 172.16.49.205 with SMTP; 24 Feb 2003 05:29:47 -0000 Received: (from mec@localhost) by duracef.shout.net (8.11.6/8.11.6) id h1O5Tk107790; Sun, 23 Feb 2003 23:29:46 -0600 Date: Mon, 24 Feb 2003 05:29:00 -0000 From: Michael Elizabeth Chastain Message-Id: <200302240529.h1O5Tk107790@duracef.shout.net> To: drow@mvista.com, gdb@sources.redhat.com Subject: Re: [maint] The GDB maintenance process X-SW-Source: 2003-02/txt/msg00506.txt.bz2 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