This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: GDB PR categories
- From: David Carlton <carlton at math dot stanford dot edu>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: 26 Sep 2002 12:48:31 -0700
- Subject: Re: GDB PR categories
- References: <3D934F11.6050809@redhat.com>
On Thu, 26 Sep 2002 14:16:49 -0400, Andrew Cagney <ac131313@redhat.com> 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