From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24757 invoked by alias); 26 Sep 2002 19:48:45 -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 24750 invoked from network); 26 Sep 2002 19:48:44 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by sources.redhat.com with SMTP; 26 Sep 2002 19:48:44 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id g8QJmWX13648; Thu, 26 Sep 2002 12:48:32 -0700 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: GDB PR categories References: <3D934F11.6050809@redhat.com> From: David Carlton Date: Thu, 26 Sep 2002 12:48:00 -0000 In-Reply-To: <3D934F11.6050809@redhat.com> 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: 2002-09/txt/msg00445.txt.bz2 On Thu, 26 Sep 2002 14:16:49 -0400, Andrew Cagney said: > Following up from what Elena did. What do people think of the > following PR categories. [ one for each architecture, for each OS, for each programming language, and for the following components of GDB: threads, sharedlibs, remote, server, cli, mi, tui, symtab. ] > It kind of reflects the maintainers file. We can, like everything > else, always do this incrementally :-) A few random thoughts: * If you're going to create so many categories, how about one for each debugging format as well? * Another thing to consider kind of reflecting is the testsuite: so arch, asm, base, c++, (chill), disasm, fortran, gdb, hp, java, log, mi, stabs, sum, threads, trace. Maybe that would be a good place to start from; and then, as we noticed that there were, say, a large number of bugs about a specific subcategory of one of those categories, we could fork off a separate PR/testsuite category for it? Though, now that I think about it, the two lists of categories shouldn't be identical: if a bug currently is present only on a particular platform but the command sequence to manifest that bug makes sense on any platform, then the testsuite case shouldn't be placed in a platform-specific location. * I definitely think that doing this incrementally would be a good idea; you've proposed more than 50 categories, and there are only 476 non-closed PR's, so probably some of the categories would be too sparse to bother with for now. Maybe you could follow the 'os' lead and have 'other arch' and 'other language' categories (where, say, pascal/scheme/ada/objc could be in the latter but c++ and java get their own PR categories), forking off a new arch/language/os whenever the appropriate 'other' category gets too large to conveniently browse. David Carlton carlton@math.stanford.edu