Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Doug Evans <dje@google.com>
To: Pedro Alves <palves@redhat.com>
Cc: gdb <gdb@sourceware.org>
Subject: Re: Bugzilla spring cleaning
Date: Fri, 28 Feb 2014 17:15:00 -0000	[thread overview]
Message-ID: <CADPb22SJ1hUhESN5qP6TEAOYK0EUSEz0na7SPTaW9Wzfu5J8MQ@mail.gmail.com> (raw)
In-Reply-To: <53107055.5020000@redhat.com>

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
>


  reply	other threads:[~2014-02-28 17:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-27 18:11 Doug Evans
2014-02-28 11:17 ` Pedro Alves
2014-02-28 17:15   ` Doug Evans [this message]
2014-02-28 19:57     ` Pedro Alves
2014-02-28 11:45 ` Jan Kratochvil
2014-02-28 17:31   ` Doug Evans

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CADPb22SJ1hUhESN5qP6TEAOYK0EUSEz0na7SPTaW9Wzfu5J8MQ@mail.gmail.com \
    --to=dje@google.com \
    --cc=gdb@sourceware.org \
    --cc=palves@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox