200202 - Don't add a comments about duplicate bugs, instead display the info at the top of the bug

Status: NEW

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

Description

[Pham]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030329 Phoenix/0.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030329 Phoenix/0.5

Is this a duplicate?

It's so dumb for a bug to have

------- Additional Comment #7 From David Tenser  2003-02-02 11:46 -------

*** Bug 191650 has been marked as a duplicate of this bug. ***


------- Additional Comment #8 From David Tenser 2003-02-02 11:48 -------

*** Bug 191649 has been marked as a duplicate of this bug. ***

This is bad for a little conversation that people are having.
Instead, there should be a little area simliar to 
Bug xxxx depends on
bug xxxx blocks

So I guess you can have 
bug xxxx duplicated bugs.
 

Reproducible: Always

Steps to Reproduce:

Comment 1

[timeless]

i believe that bugzilla currently maintains a duplicate list, and there is an
rfe to suppress useless comments (such as these)...

Comment 2

[Dave Miller [:justdave]]

This would effectively be the opposite of bug 71790...

Comment 3

[Pham]

Here's a suggestion if this does gets fixed. If someone includes a comment while
marking a bugs as DUPL, then it should be added to additional comments. But when
just marking something as a DUPL should only add to a list.

Comment 4

[Wayne Mery (:wsmwk)]

Given no change in 2 years, should this be marked WONTFIX?

Comment 5

[Stephen Lee]

Activity log would need to show a bug number (e.g. "DUPLICATE (12345)" rather
than plain "DUPLICATE"), and something on the target bug too. If that is done,
the auto-generated comment becomes entirely redundant, and would be replaced (in
another form) by Bug 11368.

Right now, it can be misleading when a bug is duped and re-opened, as the former
leaves a comment and the latter doesn't.

Comment 6

[Rolf Leggewie]

(In reply to comment #4)
> Given no change in 2 years, should this be marked WONTFIX?

I agree.

Comment 8

[Frédéric Buclin]

The fact that the bug got no activity in the last 2 years doesn't mean it should be closed. And only modules owners and Bugzilla managers should mark bugs as WONTFIX. Reopening!

Comment 9

[Rolf Leggewie]

(In reply to comment #8)
> The fact that the bug got no activity in the last 2 years doesn't mean it
> should be closed. And only modules owners and Bugzilla managers should mark
> bugs as WONTFIX. Reopening!

Well, then I guess the module owners should find the time to respond to request for closures in a time frame of less than 2 years, me thinks.  This bug has had no real activity for 4+ years.  That is essentially wontfix, even if nobody labels it as such.  Keeping it open clutters up the bug tracker IMNSHO and thus makes it harder to close real bugs.  Just my 2 cents.

Now, go fix this bug ;-)

Comment 10

[Rolf Leggewie]

(In reply to comment #9)
> Well, then I guess the module owners should find the time to respond to 
> request for closures in a time frame of less than 2 years, me thinks.

respond to = reject or confirm the request, some kind of reaction

Comment 11

[Frédéric Buclin]

(In reply to comment #10)
> respond to = reject or confirm the request, some kind of reaction

justdave changed the status of this bug to NEW, so we confirmed the request. Moreover, we are not going to mark all bugs older than 2 years as WONTFIX just to keep a small amount of open bugs. Some take a longer time to be fixed; some others are not our top priority, but this doesn't mean we don't want it. And myk's explanation in bug 317354 perfectly describes what the problem is with the current behavior, so that's definitely something we want. It's just not a top priority for now.

Talking about fixing this bug... A quick search shows that I fixed 672 bugs so far. What about you? ;)

Comment 12

[Rolf Leggewie]

(In reply to comment #11)
> (In reply to comment #10)
> > respond to = reject or confirm the request, some kind of reaction
> 
> justdave changed the status of this bug to NEW, so we confirmed the request.

which was before (!), not after comment 4.

> Talking about fixing this bug... A quick search shows that I fixed 672 bugs so
> far. What about you? ;)

I am not a dev.  But I don't think I have to hide when it comes to long-term contributions to the FOSS community.  I do mostly bug triage work.  

But I think I have since learned here, on the web and in #qa that either I don't understand the bmo philosophy or bmo bug triage is more trouble than it is worth for the one doing the triaging (at least IMO).  I will concentrate my efforts elsewhere (this is just my personal choice, I am not bitter!).

Comment 13

[timeless]

open source doesn't imply anything about timeframe. the idea is that you have the code, you can see the bug, you can write a fix, you can propose it. and lastly having proposed it, if the owner decides they don't like it, you can either cooperate or you can fork.

note all the "you"s. nowhere in this system is there "you can demand" anything.

BTW, I'm aware that you've touched a bit over 60 bugs since April, some of your changes are good, thanks, however you feel new here. Offering a bit of continuous QA isn't sufficient to make demands. I do continuous QA, but beyond that, I don't just file bugs, I also post patches. It takes patience. It also takes diplomacy, if you **** people off, they're less likely to work on them.

If you don't post patches, then you have no position to make demands. by posting patches, I hope that people will be more willing to accept my feedback.

comment 1 and comment 5 are the path that should be taken.

Note that I like seeing duplicate markings, it shows whether a bug has been active or stalled. A crash bug which has a dozen duplicate markings in a row near the end probably means it's recently a more important crasher. A crash bug that has a dozen reports at the beginning some comments from developers saying that they can't figure it out, and no further duplicate markings can indicate the crash bug has been resolved by some other changes (reporters giving up, reporters upgrading, third party products evolving, first party code fixes from other bugs, seasonal variations [DST is fun]).

I'm not really sure what the average user does. I'm pretty sure the average QA or engineer thinking from a QA perspective will think like me. Your average end user shouldn't care either way because the entire bug report is Greek up until "Fixed for release X" or "End user please answer these questions".

I'm currently reviewing requirements for another group (OpenSolaris) and they have some features in their bug tracker, a number of them are probably more useful to end users than collapsing comments (although effectively that's what they are). Basically Steps, Suggested Fix, Workaround, Affected/Fixed version table and a couple of others are all pulled out of the running comments. Which means if you're an end user and all you care about is the Fix/Workaround/How to get the fix, you don't read the comments at all.

Implementing that is considerably more valuable to me than implementing this, because it's the difference between adoption by a significant group @sun and you, some random person who haven't explained why I should care (especially about a feature which is moderately hard and has relatively bad returns/rewards - keeping in mind that by default this hurts the people I care most about).

Comment 14

[timeless]

all that said, I'm pretty sure that this would be one of the bugs I'd need to fix to sell bugzilla to the OpenSolaris community. At least, having the list of duplicates shown near the dependency lists. The hiding stuff isn't related.

Comment 15

[Rolf Leggewie]

thanks, timeless, for completely missing the point.  And verifying once more that my decision that time spent at bmo is not time spent efficiently.  Bug triage is explicitly *not* dev work.  I'd rather keep the lower profile I've had at bmo for years (your analysis was wrong) and keep being productive doing bug triaging elsewhere.  Regards.

Comment 16

[timeless]

Attachment: this is phase one

there are at least 3 phases for a bug like this. first is having enough information to be able to show the field up top (which from my perspective should be sufficient to sell this feature to opensolaris). second is figuring out how to deal with people who do or don't want to see duplicate markings inline. probably third is figuring out how to rebuild the database so that the bits could be hidden. unfortunately there's a complication. i'm guaranteed today to be able to link to any instance where someone marks a bug as a duplicate. all existing comments will have to retain that feature (at the very least because someone might have referenced a comment after that point), and removing it for future duplications bothers me.

e.g. today I can say "comment 7" was misguided duplicate annotation.

there's also another phase floating around /somewhere/ involving getting some ui review from people. I'm not wedded to the placement. and i'm not wedded to adapting the dependency list block to be used for general bug lists.

Comment 17

[Frédéric Buclin]

Don't remove existing comments about dupes. Simply hide them so that the numbering is still correct.

Comment 18

[Frédéric Buclin]

Comment on attachment 273339 [details] [diff] [review]
this is phase one

>Index: bugzilla.dtd

>+<!ELEMENT dupes (#PCDATA)>

Use duplicates, not dupes.



>Index: Bugzilla/Bug.pm

>+           dupes

fields() is only for fields with no method. You defined one.


>+sub dupes {

s/dupes/duplicates/. Also, methods are sorted alphabetically. Move this method *after* dependson().


>+      $dbh->selectcol_arrayref(q{SELECT dupe
>+                                 FROM duplicates
>+                                 WHERE dupe_of = ?},
>+                               undef,
>+                               $self->{'bug_id'});

Use $self->id instead of internal variables. Also (nit): undef and $self->id could be on the same line.


>-# XXX - When Bug::update() will be implemented, we should make this routine
>+# XXX - Bug::update() was implemented, we should make this routine

Unrelated to this bug. And Bug::update() is not fully implemented yet.



>Index: template/en/default/bug/edit.html.tmpl

>+              [% PROCESS dependencies
>+                         dep = { title => "Duplicate reports",
>+                                 fieldname => "dupes",
>+                                 generated => 1 } %]

Instead of hacking the dependencies block so much that it's unmaintainable and has nothing in common with the original one, you should rather define a separate block which does what you want. That's one of my main complains.

Comment 19

[timeless]

Attachment: phase one

classification is in fields. AFAIU fields controls the output for bugs when they want to honor bugzilla.dtd.

Comment 21

[David D. Kilzer (ddk)]

Comment on attachment 274133 [details] [diff] [review]
phase one

NOTE: I am not a reviewer, but I have a couple comments about this patch that I hope will be useful:

>Index: Bugzilla/Bug.pm
>[...]
>@@ -1169,20 +1169,21 @@ sub fields {
>[...]
>            priority bug_severity target_milestone
>+           duplicates
>            dependson blocked votes everconfirmed

This is still in the wrong method (see Comment #18).  What you really want to do is to modify sub _validate_attribute() instead.  See Attachment #280307 [details] [diff] on Bug 395624.

>+sub duplicates {
>[...]
>+      $dbh->selectcol_arrayref(q{SELECT dupe
>+                                 FROM duplicates
>+                                 WHERE dupe_of = ?},
>+                               undef, $self->id);

This query will invoke a full table scan in databases with a large 'duplicates' table since the 'dupe_of' column is not indexed.  I suggest adding an index on that column.  Example code exists in Attachment #280307 [details] [diff] on Bug 395624.

>Index: template/en/default/bug/edit.html.tmpl
>[...]
>+            [%# *** Duplicates *** %]
>+
>+            [% IF bug.duplicates.length %]
>+              <tr class="bz_duplicates">
>+                <th align="right">
>+                  Duplicates
>+                </th>
>+                <td>
>+                  [% FOREACH duplicate = bug.duplicates %]
>+                    [% duplicate FILTER bug_link(duplicate) FILTER none %][% " " %]
>+                  [% END %]
>+                </td>
>+              </tr>
>+            [% END %]

The two dependencies blocks that follow this table row have three columns each: th, td, td.  The <td> tag above needs a colspan="2" attribute to make this table row match up.

Comment 22

[Kevin Benton]

(In reply to comment #21)
> (From update of attachment 274133 [details] [diff] [review])
> NOTE: I am not a reviewer, but I have a couple comments about this patch that I
> hope will be useful:
> 
> >Index: Bugzilla/Bug.pm
> >[...]
> >@@ -1169,20 +1169,21 @@ sub fields {
> >[...]
> >            priority bug_severity target_milestone
> >+           duplicates
> >            dependson blocked votes everconfirmed
> 
> This is still in the wrong method (see Comment #18).  What you really want to
> do is to modify sub _validate_attribute() instead.  See Attachment #280307 [details] [diff] on
> Bug 395624.
> 
> >+sub duplicates {
> >[...]
> >+      $dbh->selectcol_arrayref(q{SELECT dupe
> >+                                 FROM duplicates
> >+                                 WHERE dupe_of = ?},
> >+                               undef, $self->id);
> 
> This query will invoke a full table scan in databases with a large 'duplicates'
> table since the 'dupe_of' column is not indexed.  I suggest adding an index on
> that column.  Example code exists in Attachment #280307 [details] [diff] on Bug 395624.
> 
> >Index: template/en/default/bug/edit.html.tmpl
> >[...]
> >+            [%# *** Duplicates *** %]
> >+
> >+            [% IF bug.duplicates.length %]
> >+              <tr class="bz_duplicates">
> >+                <th align="right">
> >+                  Duplicates
> >+                </th>
> >+                <td>
> >+                  [% FOREACH duplicate = bug.duplicates %]
> >+                    [% duplicate FILTER bug_link(duplicate) FILTER none %][% " " %]
> >+                  [% END %]
> >+                </td>
> >+              </tr>
> >+            [% END %]
> 
> The two dependencies blocks that follow this table row have three columns each:
> th, td, td.  The <td> tag above needs a colspan="2" attribute to make this
> table row match up.
> 

David - Excellent review.  To add...

-            <tr>
+            <tr class="bz_blocks">

Nit:  This needs to be accompanied by a style sheet change.  It's really not related to the bug this patch is submitted against.

Comment 23

[Max Kanat-Alexander]

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set "blocking3.2" tp "?", and either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

Comment 25

[Frédéric Buclin]

We are going to branch for Bugzilla 4.4 next week and this bug is too invasive or too risky to be accepted for 4.4 at this point. The target milestone is set to 5.0 which is our next major release.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else on time for 5.0.

Comment 26

[Mark Côté [:mcote]]

No action on this bug in a while, and it's not necessary for 5.0.

Comment 27

[Peter Jackson]

The minimal implementation of the second half of the summary of this bug ("instead display the info at the top of the bug") was covered by bug 55436 (fixed about 2 weeks after this bug was marked as depending on that one).

Comment 28

[Inforeportage inc]

Thanks for posting this useful and understanding Content.......Read Also Roy Keane reveals worry over Manchester United notwithstanding FA Cup quarter-final win over Fulham

Cat Burns – Live more and love more

Watch Full HIGHLIGHTS: Manchester United vs Fulham | FA Cup

Inter Milan decided on Romelu Lukaku future ahead of next season

Comment 29

[John Ray]

Hello!! There are a webpage https://floraandfaunablog.com/things-you-need-to-know-about-palm-oil/ which contain all the information about Pam Oil. You and know it's health benefits and disadvantages at one place.

Comment 30

[Joe Larson]

Attachment: same problem

Thanks from kinlentbenssen1970.