Re: Bugzilla spring cleaning

On Fri, Feb 28, 2014 at 3:45 AM, Jan Kratochvil
<[email protected]> wrote:
> On Thu, 27 Feb 2014 19:11:41 +0100, Doug Evans wrote:
>> 1) Remove old entries from the "Versions" list.
>> 1b) IWBN to reverse-sort the Versions list.
>
> As said on IRC at least Fedora Bugzilla has the list of all (incl. old)
> versions present everywhere except when filing new Bugs.

So IIUC Fedora Bugzilla is already doing what I want to do here.

> That has IMO all pros and no cons being discussed.
>
>
> n+1) Components list is suspicious.  It is not used to assign bugs to specific
> people so it is questionable if it should exist at all.  binutils has just
> "binutils" there (and "ld", "gas", but even "bfd" is not an extra item).

I dunno.  gdb is a pretty big program (not as big as some I know of
:-), but big enough).
I like the fact that I have this tool (the component category) for
sorting bugs according to which part of gdb is affected.  For example,
I for one intend to pay attention to the guile category, and I'm sure
others would like the ability to filter them out ...
And I can well imagine this applies to other components.

[Obviously, some bugs cross component lines, and sometimes users don't
know which category to use, and there are probably a few other issues
I could raise if I paused a few more moments to think about it.  In
the end though I've found the component category to be a net win.
Plus if confusion over which component to use is a real problemfor
users, a one-liner in page that said "If you don't know which
category, don't worry, just pick one and we'll change it if
necessary." (or some such) would IMO go a long way to fixing that.  If
bugzilla lets us pick a default component, then set it to "gdb" - the
catch-all for "other" components]

> Otherwise there should be many more Components, at least one for each arch and
> also one for each OS (such as "linux"). There is also missing "readline",
> "dwarf", "stabs", "libiberty" and some others.

There's a balance to be had, sure.
One for each arch would vastly reduce the S/N ratio of the list
(barring, e.g., u/i changes that let one expand/collapse the list of
each arch or some such).  I haven't felt a need for a category for
each arch over the years, but maybe others have.
OTOH, we have already established the convention for having a
component for each language.  I didn't start it, but I don't mind it,
and that is why (for reference sake) I wanted to add a component for
"go".

>
> I do not think it matters much, just when Doug brought up the topic.
>
>
> Jan