Bugzilla spring cleaning

Bugzilla spring cleaning

[Doug Evans]

Hi.

There's a few cleanups I've wanted to see happen on our Bugzilla site.

The ones that are currently on my mind are these:

1) Remove old entries from the "Versions" list.

Do we really need 3.x and 4.x here?
Personally, I can see deleting 5.x too, and replacing all of them with
a "catch-all" field for old releases.
[I can also see deleting 6.x, but "baby steps" ...]

I can imagine their appearance in some old bug making it
hard/impossible to accomplish this, but I won't know unless I ask.

1b) IWBN to reverse-sort the Versions list.

2) The "Target Milestone" list could also use some trimming.

Comments?

Re: Bugzilla spring cleaning

[Pedro Alves]

On 02/27/2014 06:11 PM, Doug Evans wrote:
> Hi.
> 
> There's a few cleanups I've wanted to see happen on our Bugzilla site.
> 
> The ones that are currently on my mind are these:
> 
> 1) Remove old entries from the "Versions" list.
> 
> Do we really need 3.x and 4.x here?
> Personally, I can see deleting 5.x too, and replacing all of them with
> a "catch-all" field for old releases.
> [I can also see deleting 6.x, but "baby steps" ...]

What's the actual problem this is trying to solve?

> 
> I can imagine their appearance in some old bug making it
> hard/impossible to accomplish this, but I won't know unless I ask.

If there are bugs filed against those versions, then I don't
see the point in removing them.  My first reaction would be to
object.  I see no upside in simply dropping history of old GDBs.

But I don't really know what is the oldest GDB that does have
bugs filed against.  If indeed there's no bug filed for
those old versions, then I'll definitely agree with removing them.

Closing bugs filed against old releases that have had no
input for quite a long time would be a different discussion.
But it's not clear to me whether that's what you're proposing.

> 1b) IWBN to reverse-sort the Versions list.

I agree this is one would indeed be very nice.  It's quite
likely we have bugs erroneously reported against old versions
simply because of this issue.  Bugs converted from the old
gnats (which I believe is the majority of filed bugs) fortunately
have the "Release" field in the description text, so we
could fix any in that situation.  Furthermore, it seems to me
that doing this pretty much would make the issue of eliminating
old versions practically moot?

> 2) The "Target Milestone" list could also use some trimming.

Offhand, same as above.

-- 
Pedro Alves

Re: Bugzilla spring cleaning

[Doug Evans]

On Fri, Feb 28, 2014 at 3:17 AM, Pedro Alves <palves@redhat.com> wrote:
> On 02/27/2014 06:11 PM, Doug Evans wrote:
>> Hi.
>>
>> There's a few cleanups I've wanted to see happen on our Bugzilla site.
>>
>> The ones that are currently on my mind are these:
>>
>> 1) Remove old entries from the "Versions" list.
>>
>> Do we really need 3.x and 4.x here?
>> Personally, I can see deleting 5.x too, and replacing all of them with
>> a "catch-all" field for old releases.
>> [I can also see deleting 6.x, but "baby steps" ...]
>
> What's the actual problem this is trying to solve?

Improve the S/N ratio for users entering bugs.

>> I can imagine their appearance in some old bug making it
>> hard/impossible to accomplish this, but I won't know unless I ask.
>
> If there are bugs filed against those versions, then I don't
> see the point in removing them.

Neither do I! [What words did I used to convey such a significant
probability that that is what I wanted?  Let me know so I won't use
them again.  :-)]

That is why I raised the possibility that what I want to achieve is
not achievable (*1).
OTOH, *if* we can remove entries from the Versions list, *and* it
doesn't affect existing bugs, then I'd like to do so.

> My first reaction would be to
> object.  I see no upside in simply dropping history of old GDBs.
>
> But I don't really know what is the oldest GDB that does have
> bugs filed against.  If indeed there's no bug filed for
> those old versions, then I'll definitely agree with removing them.
>
> Closing bugs filed against old releases that have had no
> input for quite a long time would be a different discussion.
> But it's not clear to me whether that's what you're proposing.

I have a separate proposal for that, to follow in a separate thread.

>> 1b) IWBN to reverse-sort the Versions list.
>
> I agree this is one would indeed be very nice.  It's quite
> likely we have bugs erroneously reported against old versions
> simply because of this issue.  Bugs converted from the old
> gnats (which I believe is the majority of filed bugs) fortunately
> have the "Release" field in the description text, so we
> could fix any in that situation.  Furthermore, it seems to me
> that doing this pretty much would make the issue of eliminating
> old versions practically moot?

The older versions in the list are still clutter and noise.
Plus even with a reverse-sorted list it's still possible for users to
accidentally file a bug for the wrong version.  Do we actually intend
to put any time into such old versions?  I don't.  So let's turn it
around, what's the justification (setting aside caveat (*1) above),
for keeping them?

>> 2) The "Target Milestone" list could also use some trimming.
>
> Offhand, same as above.
>
> --
> Pedro Alves
>

Re: Bugzilla spring cleaning

[Pedro Alves]

On 02/28/2014 05:15 PM, Doug Evans wrote:
> On Fri, Feb 28, 2014 at 3:17 AM, Pedro Alves <palves@redhat.com> wrote:
>> On 02/27/2014 06:11 PM, Doug Evans wrote:
>>> Hi.
>>>
>>> There's a few cleanups I've wanted to see happen on our Bugzilla site.
>>>
>>> The ones that are currently on my mind are these:
>>>
>>> 1) Remove old entries from the "Versions" list.
>>>
>>> Do we really need 3.x and 4.x here?
>>> Personally, I can see deleting 5.x too, and replacing all of them with
>>> a "catch-all" field for old releases.
>>> [I can also see deleting 6.x, but "baby steps" ...]
>>
>> What's the actual problem this is trying to solve?
> 
> Improve the S/N ratio for users entering bugs.

OK, that's more focused.  You just said the "Versions" list,
and that to me implied bug search as well, not just the new
bug form.

>>> I can imagine their appearance in some old bug making it
>>> hard/impossible to accomplish this, but I won't know unless I ask.
>>
>> If there are bugs filed against those versions, then I don't
>> see the point in removing them.
> 
> Neither do I! [What words did I used to convey such a significant
> probability that that is what I wanted?  Let me know so I won't use
> them again.  :-)]

- "spring cleaning" in the subject makes me go into "delete cruft"
  mode.

- You hinted at "deleting 6.x" too.  As surely you'll know there are
bugs filed against those versions, I was led me to believe
you wanted to just delete the bugs along with the versions, if
possible.  But I see now that you meant instead to merge those
into the "catch-all" for old versions.

> That is why I raised the possibility that what I want to achieve is
> not achievable (*1).
> OTOH, *if* we can remove entries from the Versions list, *and* it
> doesn't affect existing bugs, then I'd like to do so.

OK.

>>> 1b) IWBN to reverse-sort the Versions list.
>>
>> I agree this is one would indeed be very nice.  It's quite
>> likely we have bugs erroneously reported against old versions
>> simply because of this issue.  Bugs converted from the old
>> gnats (which I believe is the majority of filed bugs) fortunately
>> have the "Release" field in the description text, so we
>> could fix any in that situation.  Furthermore, it seems to me
>> that doing this pretty much would make the issue of eliminating
>> old versions practically moot?
> 
> The older versions in the list are still clutter and noise.

Alright, now we're focusing only on the version list in the
new bug form.  Here I agree there's no need to allow reporting
bugs against older versions.

> Plus even with a reverse-sorted list it's still possible for users to
> accidentally file a bug for the wrong version.  Do we actually intend
> to put any time into such old versions?  I don't.  

Nor do I.

> So let's turn it
> around, what's the justification (setting aside caveat (*1) above),
> for keeping them?

Well, if you were talking about bug search, knowing which gdb
version a bug was filed against.  So I see no real good upside
to merging old versions into a single catch-all for old releases,
at some arbitrary moving cut off date -- I'd rather preserve history.

For the new bug form, none that I'd insist on myself
(discounting possible Bugzilla technical limitations).

So the real question should be IMO:

 Should we allow users to report new bugs against old versions of
 GDB the community no longer supports?

And here we agree.  In my opinion, no, we shouldn't.

Thanks,
-- 
Pedro Alves

Re: Bugzilla spring cleaning

[Jan Kratochvil]

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.

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).

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.

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


Jan

Re: Bugzilla spring cleaning

[Doug Evans]

On Fri, Feb 28, 2014 at 3:45 AM, Jan Kratochvil
<jan.kratochvil@redhat.com> 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