* 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.
Yes. Most test cases are generic. The only non-generic directory is
gdb.arch where tests need to verify the exact value of registers. 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.
Yes, that makes sense. If there is an active maintainer create the
category otherwize leave it for ``other'':