104652 - Missing dependency tree information

Status: RESOLVED FIXED

(Bugzilla :: Bugzilla-General, defect)

Description

[Gervase Markham [:gerv]]

http://bugzilla.mozilla.org/showdependencytree.cgi?id=103705 
does not correctly show the dependencies of
http://bugzilla.mozilla.org/show_bug.cgi?id=100107 . 

In that tree, bug 100107 appears to have no dependencies when, in fact, it has a
large number. This is somewhat annoying, as it makes it harder to track Mozilla
1.0 bugs.

Gerv

Comment 1

[Christian Reis]

Gerv, how do you think this would hold up to the new dependency tree? We did
change the handling a bit and it is probably better now. Then again, my local
install doesn't have buglists like bmo does :)

Comment 2

[Gervase Markham [:gerv]]

myk is going to sync his development Bugzilla with b.m.o and try and reproduce
this. Then, we'll see ;-)

Gerv

Comment 3

[Andreas Franke (gone)]

Strictly speaking, this bug is INVALID. The behaviour you observe is by design.
While printing a dependency tree, a special hash %seen keeps track of the bugs
that already have been displayed (with their dependency trees). When the bug
occurs again, it is printed, but the dependencies are omitted (to avoid
cluttering up the screen).

It would be easy to not test this condition and always print the dependencies.

Comment 4

[Gervase Markham [:gerv]]

Hmm. It therefore boils down to a question about whether this is a good idea or
not. If there is no check, and we get a dependency loop (despite all our
checking to try and make sure that doesn't happen) then horribleness ensues. On
the other hand, if there is checking, we get this problem.

Could we allow a bug to appear X times, but no more, in the list? A sensible
value might be, say, 5. We could increment the hash value and test for > 5
rather than existence. This could be optional.

Or, we could indicate in some way that the dependencies of the bug are elsewhere
- and even perhaps provide a page-internal link to the master occurrence of that
bug. That might be better.

Gerv

Comment 5

[Gervase Markham [:gerv]]

Attachment: Patch v.1

Comment 6

[Gervase Markham [:gerv]]

This patch replaces the summary of bugs with dependencies which are truncated
because they are already seen with the string "This bug appears elsewhere in
this tree". I think this is all we need to do for the moment, and will tip
people off that they should be looking elsewhere.

Gerv

Comment 7

[Jacob Steenhagen]

Comment on attachment 54287 [details] [diff] [review]
Patch v.1

Looks good to me... I don't have any dependency trees in my test install (and I'm
too lazy to log into landfill and put it on a test install ATM), so I didn't
actually test it, just looked at the code.  Second Review should confirm
functionality :)

Comment 8

[Matthew Tuck [:CodeMachine]]

It would be nice if eventually, a user could choose which policy they want. 
%parent{} would be used instead to prevent recursion.

Comment 9

[Matthew Tuck [:CodeMachine]]

This looks OK, but there seen to be a couple of SendSQL statements that are used
in this situation.  I'm wondering whether they can/should be removed from the
code path in that case.

Comment 10

[Gervase Markham [:gerv]]

Taking.

Gerv

Comment 11

[Gervase Markham [:gerv]]

I'm pretty sure we bail as early as we can no, and no unnecessary DB calls are
made, but I'm happy to be proved wrong. :-)

Still looking for second review; we'd still like this to manage the 1.0
dependency tree :-)

Gerv

Comment 12

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 54287 [details] [diff] [review]
Patch v.1

looks good, works. r=myk

Comment 13

[Myk Melez [:myk] [@mykmelez]]

Checking in showdependencytree.cgi;
/cvsroot/mozilla/webtools/bugzilla/showdependencytree.cgi,v  <-- 
showdependencytree.cgi
new revision: 1.13; previous revision: 1.12
done

Comment 14

[Andreas Franke (gone)]

The summaries of some bugs (e.g. 98278) are missing on this page: 
http://bugzilla.mozilla.org/showdependencytree.cgi?id=103705&maxdepth=2&hide_resolved=1

Gerv, maybe you want to reopen this bug?

Comment 15

[Gervase Markham [:gerv]]

This is an interaction between the patch for this bug and the depth control; the
first hit on the bug is below the depth rendered, but we don't notice. 

This is a a separate bug - please file it on me.

Gerv

Comment 16

[Andreas Franke (gone)]

Filed bug 112537.

Comment 17

[Dave Miller [:justdave]]

fixing incorrect milestones on fixed bugs.