From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22851 invoked by alias); 20 Feb 2003 00:16:20 -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 22807 invoked from network); 20 Feb 2003 00:16:19 -0000 Received: from unknown (HELO mx1.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 20 Feb 2003 00:16:19 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h1K0GJK14176 for ; Wed, 19 Feb 2003 19:16:19 -0500 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h1K0GJa14917; Wed, 19 Feb 2003 19:16:19 -0500 Received: from localhost.redhat.com (romulus-int.sfbay.redhat.com [172.16.27.46]) by pobox.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h1K0GHO30355; Wed, 19 Feb 2003 19:16:17 -0500 Received: by localhost.redhat.com (Postfix, from userid 469) id 475A9FF79; Wed, 19 Feb 2003 19:20:24 -0500 (EST) From: Elena Zannoni MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15956.8008.208205.915560@localhost.redhat.com> Date: Thu, 20 Feb 2003 00:16:00 -0000 To: Jason Molenda Cc: Andrew Cagney , Daniel Jacobowitz , Elena Zannoni , gdb@sources.redhat.com Subject: Re: [maint] The GDB maintenance process In-Reply-To: <20030219155956.A83389@molenda.com> References: <20030217180709.GA19866@nevyn.them.org> <20030218023553.2BBB73D02@localhost.redhat.com> <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> <20030219153559.A77442@molenda.com> <3E5419CD.8050203@redhat.com> <20030219155956.A83389@molenda.com> X-SW-Source: 2003-02/txt/msg00389.txt.bz2 Jason Molenda writes: > On Wed, Feb 19, 2003 at 06:57:01PM -0500, Andrew Cagney wrote: > > > > Using GNATS as the infrastructure to track patches is pathetic. > > > > Not as pathetic as `cagney's mailbox sitting on a lapbrick with a > > failing hard disk'. > > Well, yes. :-) I didn't mean "you, the fellow who has put patches > into gnats, are a fool" -- I meant that the overhead over putting > patches in gnats is too high compared with just sending them to > gdb-patches. IMHO this is a method that will fail, which is why > I dragged my feet when Elena originally requested the gdb-patches > gnats database be set up. Ignoring the fact that gnats is a bug It must have been my evil twin, because I don't remember asking for this (I am in favor of something like it, though). To be honest, it was a project that Jim Blandy started but wasn't finished. It was abandoned because there were problems with including a patch preserving spaces, or something like that. > tracker--not a magical patch tracking database--as long as it isn't > at the center of every developer/maintainer's patch workflow, it > will be doomed to irrelevance. > > It's got to be easy, it's got to be relevant, and it's gotta be the > way everything is done. > > > > Using mailing lists to track patches is annoying. > > > > Er, you can't track patches using a mailing list. A mailing list can be > > used to submit/discuss patches. It can't be used to track their state. > > that needs a database. > > I was speaking loosely - I meant the combination of the mailing > list and the web archives of that mailing list. The mailing list > web archives are a being used as the patch repository right > now--people use URLs into the archives to refer to old patches, > they use google or the htdig search engine to find old patches, > and they grope around blindly to figure out what ever happened with > a given patch. > > > Time to install aegis, ay? > > I've never looked at Aegis, so I can't say. First the gdb maintainers > and developers need to decide what they want and will use, then > make it exist; not look at what exists and settle for it. Maybe > Aegis is exactly what we'd all love in a magical patch tracking > database and we can use it as-is, but IMHO it's too early in that > discussion to care one way or another. > > > J