From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28481 invoked by alias); 19 Feb 2003 23:36:01 -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 28472 invoked from network); 19 Feb 2003 23:36:00 -0000 Received: from unknown (HELO molenda.com) (192.220.74.81) by 172.16.49.205 with SMTP; 19 Feb 2003 23:36:00 -0000 Received: (qmail 80401 invoked by uid 19025); 19 Feb 2003 23:35:59 -0000 Date: Wed, 19 Feb 2003 23:36:00 -0000 From: Jason Molenda To: Andrew Cagney Cc: Daniel Jacobowitz , Elena Zannoni , gdb@sources.redhat.com Subject: Re: [maint] The GDB maintenance process Message-ID: <20030219153559.A77442@molenda.com> References: <20030217180709.GA19866@nevyn.them.org> <20030218042847.50F2E3CE5@localhost.redhat.com> <20030217180709.GA19866@nevyn.them.org> <20030218023553.2BBB73D02@localhost.redhat.com> <20030217180709.GA19866@nevyn.them.org> <15953.20132.193102.752916@localhost.redhat.com> <20030219014904.GA11446@nevyn.them.org> <3E539FF8.70201@redhat.com> <20030219152123.GA4751@nevyn.them.org> <3E53B0D9.2070009@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <3E53B0D9.2070009@redhat.com>; from ac131313@redhat.com on Wed, Feb 19, 2003 at 11:29:13AM -0500 X-SW-Source: 2003-02/txt/msg00385.txt.bz2 On Wed, Feb 19, 2003 at 11:29:13AM -0500, Andrew Cagney wrote: > > > Which reminds me. We've got two GNATS databases set up for GDB: 'gdb' > > and 'gdb-patches'. Should we use the gdb-patches GNATS database to > > separate them from bug reports? > > No!!!! That gdb-patches database should be deleted. It's dead. > > People already have to track: > > - gdb@ > - gdb-patches@ > - gnats@ > > and that is to complicated for some. At least, by having both patches > and bugs in a single database, we've a one stop-shop. A better change > is to dump gdb-patches@ We've got two separate discussions here: The social conventions and procedures for how patches are discussed/applied, and the infrastructure to support those things. Using GNATS as the infrastructure to track patches is pathetic. Using mailing lists to track patches is annoying. For a minute, though, imagine a magical patch tracking database. It would be at the core of the patch workflow, not something glommed on to the side--anything that says "you send your note to gdb-patches and then you enter it into the patch database" is missing the point. It wouldn't be a bug database, it would be a patch database--it's got to track updates to the patch, it's got to relate groups of patches or patches dependant on other patches. It'll track the discussion about patches. It could track various maintainer's opinions on a patch (I like the -1/+0/+1 Apache scheme); it could track when the patch is blocked on a particular person (submitter, a maintainer), or maybe when the patch is waiting approval by any one of several people. It could even relate GNATS bugs and patches that are attempting to fix those bugs, so when someone sees a bug in the GNATS database that hasn't yet been fixed, they can click over to the magical patch tracking database and see why that patch isn't in yet. All of these transactions are still visible on a gdb-patches list, of course, but the mailing list is a read-only view on to what's happening. All additional comments or follow-ups are routed through the magical patch tracking database, and reflected back out to the gdb-patches list. I've heard Sourceforge has such a tool. JimI was telling me at lunch how they track the tcl patches this way. And there is a separate mechanism that tcl and Python both use for larger-scope proposals ("PEP" for Python, a "Python Enhancement Proposal"). For instance, here's a PEP to add a boolean type to Python: http://www.python.org/peps/pep-0285.html And it has a link into the Patch Tracker sourceforget database for the patch to implement the proposal: http://python.org/sf/528022 Don't fall into the trap of saying "the only two ways patches can be tracked are the gdb-patches mailing list or gnats". Let's start by imagining a patch database designed around our actual workflow, one which would require a minor change in how we work and add a tiny bit of extra patch-management overhead, and yield benefits of not losing track of patches. If such a magical patch tracking database exists, would it be worth changing our workflow to use it? I know that patch submitters would eagerly jump on such a system, but unless all the actual maintainers think it's a net gain it's not going anywhere. Once that's all decided - what we want, and if we'd even use it if we had it - then there's the minor matter of making it exist. :-) Maybe bugzilla or gnats can be adapted, maybe another program can be found from the net or a free bit of code from Sourceforge's PatchTracker can be appropriated, or maybe someone gets the joyus chance to write it from scratch. Before we get bogged down in implementation details and discussions, it's critical to discuss what such a system would do, and if we're all willing to push gdb patch work through it. If we can't dream up such a system, then let's be happy with gdb-patches and URLs for patch references. J