55436 - Implement list of duplicate bug numbers on show_bug.cgi (easy way to find dupes of the bug you're viewing)

Status: RESOLVED FIXED

(Bugzilla :: Creating/Changing Bugs, enhancement, P2)

Description

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

It would be great if show_bug.cgi could provide a link to easily find all bugs 
currenly marked as dups of the bug. This would be great when verifying bugs to 
make sure that all testcases in all dups works. It would also be good to go 
though all dups to make sure that they actually are dups.

I know that this infromation can be got useing a bugzilla query, but I still 
think it would be a good way to increase quality of verifications. (The link on 
the page could be just a link to a bugzilla query)

Comment 1

[Jesse Ruderman]

This depends on or is a duplicate of bug 25693.

Comment 2

[Andreas Franke (gone)]

-> Bugzilla product, Creating/Changing/Viewing Bugs component, reassigning.

Comment 3

[Dave Miller [:justdave]]

We are currently trying to wrap up Bugzilla 2.16.  We are now close enough to
release time that anything that wasn't already ranked at P1 isn't going to make
the cut.  Thus this is being retargetted at 2.18.  If you strongly disagree with
this retargetting, please comment, however, be aware that we only have about 2
weeks left to review and test anything at this point, and we intend to devote
this time to the remaining bugs that were designated as release blockers.

Comment 4

[Asa Dotzler [:asa]]

It needs to do more than just list the dupes that are mentioned in the bug. It
needs to trace the dupechains and list all of those.

Comment 5

[Dave Miller [:justdave]]

Enhancements which don't currently have patches on them which are targetted at
2.18 are being retargetted to 2.20 because we're about to freeze for 2.18. 
Consideration will be taken for moving items back to 2.18 on a case-by-case
basis (but is unlikely for enhancements)

Comment 6

[Dave Miller [:justdave]]

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004.  Anything flagged
enhancement that hasn't already landed is being pushed out.  If this bug is
otherwise ready to land, we'll handle it on a case-by-case basis, please set the
blocking2.20 flag to '?' if you think it qualifies.

Comment 8

[Dave Miller [:justdave]]

The bug I just duped to this suggests just listing the duplicate bugs in the bug info at the top, similar to how the dependencies are currently displayed.

Comment 9

[Thomas D. (:thomas8)]

My vote for this one, and please don't let it rot another 9 yrs before we can all benefit from this. And the benefit is VERY obvious, if you ask me (and even if you don't). This doesn't look as if it would need a huge change to implement.

(In reply to comment #8)
> The bug I just duped to this suggests just listing the duplicate bugs in the
> bug info at the top, similar to how the dependencies are currently displayed.

Exactly. Please show short list of duplicates below the dependencies, like this:

Depends on:  bug 123, bug 345, bug 555
Blocks:      bug 789, bug 980
Duplicates:  bug 901, bug 904, bug 910

Comment 10

[Thomas D. (:thomas8)]

Attachment: ASCII mockup for Duplicates field on show_bug.cgi

Whom can I ask for ui-review of simple solution proposed in duplicate bug 431682 and comment 9: Just have a list of "Duplicates" on show_bug.cgi as we know show lists for "Depends on" and "Blocks"?

Comment 11

[Frédéric Buclin]

This is a read-only list, right?

Comment 12

[Thomas D. (:thomas8)]

Good catch! I'd think yes, the display list of duplicates is read-only.

It's unlikely someone would add multiple duplicates at a time without looking at the duplicate bugs. And when you're looking at them anyway, you can also set the duplicate flag there for each bug as do now.

Frédéric, is it difficult to display the list and make it read-only?

Comment 13

[Max Kanat-Alexander]

Comment on attachment 429690 [details]
ASCII mockup for Duplicates field on show_bug.cgi

Yeah, that looks reasonable, although I'd put it above the other two fields, and it should only appear when there actually are duplicates. And it shouldn't be editable.

Comment 14

[Thomas D. (:thomas8)]

Max, thanks for your time to look into this.
Do you think someone from bugzilla developers might find the time to implement this?

Comment 15

[Max Kanat-Alexander]

(In reply to comment #14)
> Max, thanks for your time to look into this.
> Do you think someone from bugzilla developers might find the time to implement
> this?

  We might! It's not one of our highest-priority items, though, right now. Definitely something we want to see done, though. So if somebody comes along and contributes a patch, we'd review it.

Comment 16

[Thomas D. (:thomas8)]

Attachment: V2.ASCII mockup for Duplicates field on show_bug.cgi

Max, you think you could set a target milestone for this bug? This would be a really useful enhancement of great benefit for everyday use of bugzilla.

Max, here's a new ASCII mockup for review, which incorporates the changes you requested in your comment 13 (show dupes *above* dependencies, don't show dupes row when there are none).

In addition, I propose to include the total dupecount (bug 469018), like this:

Duplicates (2):  678901, 789012

Consequently, we'll then have to decide what we consider dupes of the current bug:
a) only direct (immediate) dupes of the current bug
b) both direct and indirect dupes (include dupes of duplicate bugs)

On the existing chart of "Most frequently reported bugs" (https://bugzilla.mozilla.org/duplicates.cgi), we are doing b) for a reason, quote:

> counting the number of *direct and indirect duplicates* of bugs. This
> information is provided in order to assist in minimizing the amount of
> duplicate bugs entered into Bugzilla, which saves time for Quality Assurance
> engineers who have to triage the bugs.

So it's probably a good idea to do the same on show_bug.cgi, i. e. the total dupecount should include indirect dupes. However, we probably don't want to waste space by showing too many indirect dupes in the dupes list. Therefore, I propose that we hide indirect dupes by default, with a toggle link to show them, like this:

Duplicates (5):  678901, 789012,
                 and 3 indirect duplicates (_show_)
Depends on:      123456, 234567, 345678
Blocks:          456789, 567890

User can then click _show_ to toggle view of indirect dupes:

Duplicates (5):  678901, 789012,
                 and 3 indirect duplicates (_hide_):
                 456789, 490459, 134569
Depends on:      123456, 234567, 345678
Blocks:          456789, 567890

Please find the full concept in the attached v2.ASCII draft, which is hereby up for review.

Comment 17

[Max Kanat-Alexander]

Hey Thomas! That mockup looks great.

For the first draft of the feature, we wouldn't display indirect duplicates (even a count of them), because doing that in a performant way requires some backend re-architecture.

If you're going to hide the row when it's not displayed, it should be underneath the Blocks/DependsOn fields, so that the UI doesn't move around.

I can only set the Target Milestone if somebody actually takes this bug. If there's nobody working on it, there's no reason to set the TM.

Comment 18

[Thomas D. (:thomas8)]

(In reply to comment #17)
> Hey Thomas! That mockup looks great.

Thanks! Does that mean it should have review+ flag? :)

> For the first draft of the feature, we wouldn't display indirect duplicates
> (even a count of them), because doing that in a performant way requires some
> backend re-architecture.

Which means whoever takes this should start with mockup.v1
 
> If you're going to hide the row when it's not displayed, it should be
> underneath the Blocks/DependsOn fields, so that the UI doesn't move around.

Oh, I just pushed it up because you wanted it up, and we're hiding the whole duplicates row because you wanted it hidden if it's empty. I don't think we'll ever see much movement, as this can only change when the bug page is reloaded (unless you have some ajax magic at work). The other problem is that we don't show duplicates on the dependency tree yet, so if we have dupes below depends/blocks, we'll have probs where to place the dependency tree row.
-> So maybe it should stay above depends and blocks rows, as you initially proposed.

Second thoughts on hiding the row: We are showing both depends/blocks rows even if they are empty. Which is a good way of showing that we haven't skipped the field, but it actually has no values attached.
-> So maybe we should also show the "Duplicates" caption even if there are no duplicates? What do you think?

> I can only set the Target Milestone if somebody actually takes this bug. If
> there's nobody working on it, there's no reason to set the TM.

Unfortunately I can't do it myself. But I'm still hoping that someone with more time and code knowledge than me will have mercy on this value-adding enhancement bug before it'll turn 10 years old in October this year.

Comment 19

[Max Kanat-Alexander]

Comment on attachment 449438 [details]
V2.ASCII mockup for Duplicates field on show_bug.cgi

This is r-, because adding indirect duplicates won't be a part of this bug.

Comment 20

[Thomas D. (:thomas8)]

Having a target milestone for this highly beneficial feature would help.

Comment 21

[Max Kanat-Alexander]

(In reply to comment #20)
> Having a target milestone for this highly beneficial feature would help.

  Bugs get target milestones when they have an assignee who is working on them and commits to completing them by a certain time.

Comment 22

[Frédéric Buclin]

Attachment: patch, v1

This patch leaves comments about duplicates alone. We will stop generating them in bug 200202.

Comment 23

[Max Kanat-Alexander]

Comment on attachment 548621 [details] [diff] [review]
patch, v1

Review of attachment 548621 [details] [diff] [review]:
-----------------------------------------------------------------

I love it. I haven't tested it, but the code looks great.

One other thing that's not in the comments below, though, is that we need to add duplicates to preload() so that we pre-run visible_bugs on them and we don't regress performance.

::: template/en/default/bug/edit.html.tmpl
@@ +633,5 @@
> +[% BLOCK section_duplicates %]
> +  [% RETURN UNLESS bug.duplicates.size %]
> +  <tr>
> +    <td class="field_label">
> +      <label for="duplicates"><b>Duplicates</b></label>:

You shouldn't need that <b> around the label, field_label should handle that for you.

Comment 24

[Max Kanat-Alexander]

Pyrzak should also take a look at this patch to make sure the UI's okay with him.

Comment 25

[Max Kanat-Alexander]

(A screenshot would make Pyrzak's life easier.)

Comment 26

[miketosh]

This would fix bug 125888, so I think that should be closed as a dup, unless I'm misunderstanding that bug.

Comment 27

[Frédéric Buclin]

Attachment: patch, v2

Now preloaded. Screenshot coming.

Comment 28

[Frédéric Buclin]

Attachment: screenshot

Here is how it looks like.

Comment 29

[Guy Pyrzak]

I'm not sure if i like the word "Duplicates" is right, or that we need to take up so much room on the screen taken up by the list of the duplicates. Remember if there are a lot of duplicates that list could get huge. 

I think the relevant information is just the number of bugs that are marked as duplicates of the bug and (view as bug list). Let me know if this is not correct. So having a long list of bugs isn't helping anyone and also requires someone to count the number of bugs.

something like:

N bugs have been marked as duplicates (view as bug list)

where N is the number of bugs marked as duplicates seems a lot more helpful. I'm not gonna say R-, cause the design isn't horrible and it is consistant with the depends on and blocks, but I think from a usability perspective, a list of duplicates isn't what people are looking for, they're looking for a magnitude. 

Another interesting thing might be the last time something was marked as a duplicate. I would want to talk to a mozilla QA person to be sure, but I get the feeling that if a bug has a lot of dups but it has been duped recently or not for a long time makes a difference. But I'm less sure about this one. I'm not sure how easy this capability would be to add so I would leave it out for now.

Comment 30

[Guy Pyrzak]

LpSolit and I chatted and we both thought the relevant info is a few things. 

1. Are there dups
2. How long ago were they filed

This lead Lp to point out that bug numbers could be used to determine dates, which is true, but in that case we should not show aliases. He also pointed out that showing N isn't helpful because 8 vs 2 vs 5, no one cares about. But QA does care about when they were filed.  We then discussed grouping. 

Something like what i discussed in the previous comment: 5 bugs were filed as dups, 3 were filed less than a week ago.

This lead to a new problem. How do we determine grouping? This is a harder problem since it is based on the product life cycle. 2 products might care about different thresholds for when they want to see the grouping. We could try to use milestones? 

However there is another option, sparklines! If the reader is not familiar with them background can be found here: http://en.wikipedia.org/wiki/Sparkline. X would represent the time and Y would be the number of dups. This could be accomplished via canvas pretty easily.

Again, this might be much ado about nothing in which case, LpSolit's original screenshot is fine. But I wanted this discussion to happen. There are alternatives to having a list of bug ID, which is not super informative unless a user has a mental mapping of bug IDs to dates and can do that in their head quickly, vs a sparkline which can show the increase of duplicates over time. Here is a page that uses sparklines with jquery, i'm not sure if one exists for YUI but maybe I could look into writing it: http://omnipotent.net/jquery.sparkline/

Lastly, we could just have something that says: 

View Duplicates (5)

And that's it. Simple.

Comment 31

[Guy Pyrzak]

http://webkist.wordpress.com/2009/06/30/yui-sparkline-widget/ has a version implemented for YUI if we want to go down this path.

Comment 32

[Frédéric Buclin]

(In reply to Guy Pyrzak from comment #30)
> their head quickly, vs a sparkline which can show the increase of duplicates
> over time.

I'm personally not sure a sparkline makes sense with such low numbers. On average, a bug has 1-2 dupes max.

Comment 33

[Max Kanat-Alexander]

Comment on attachment 551069 [details] [diff] [review]
patch, v2

Review of attachment 551069 [details] [diff] [review]:
-----------------------------------------------------------------

Looks great! I'm fine with you checking in with that UI and taking pyrzak's comments afterward.

Comment 34

[Max Kanat-Alexander]

Oh, I didn't see pyrzak's comments. :-) I like a lot of those ideas, but I think at this point what we'll want to do is refine the UI for this after Pretty happens, since anything too fancy we do right now will disappear anyhow with Pretty.

Comment 35

[Frédéric Buclin]

Committing to: bzr+ssh://[e-mail]/bugzilla/trunk/
modified Bugzilla/Bug.pm
modified template/en/default/bug/edit.html.tmpl
Committed revision 7897.

Comment 36

[Thomas D. (:thomas8)]

A big, big, thank you for finally fixing this bug.
It's so incredibly helpful, and it's just right as it is (list of linkified bug numbers, as for Depends/Blocks). Pls keep it that way!

Comment 16 / Comment 17 might still be interesting (needs a followup bug).

Comment 37

[Frédéric Buclin]

Added to relnotes for 4.4.