355996 - Ability to link to bugs by alias in bug descriptions/comments

Status: NEW

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

Description

[timeless]

bug sheriffpass and https://bugzilla.mozilla.org/show_bug.cgi?id=sheriffpass should both be linkified and should work about as well as bug 322423 and https://bugzilla.mozilla.org/show_bug.cgi?id=322423.

this is a complaint i saw in another bugzilla.

Comment 1

[Max Kanat-Alexander]

Yes, agreed. That would be nice.

It might slow down Bugzilla too much to check if every word after "bug" is a valid alias, though. We'd have to see.

Comment 2

[Kent Rogers [:mrbball]]

I just became aware of this bug today while working on a customization that makes
heavy use of bug aliases.

Unless I'm missing something, the change to implement this feature seems fairly simple,
but I'm not sure how to test it's performance.  I basically tried loading a bug with
over 300 comments to see if there was any significant difference and I saw none.
Other ideas?  I suppose the real issue is if there MANY comments with the word "bug"
(or its derivatives).  In my example, there were 200+ occurrences of the word "bug" in
the comments, which seems like a moderately large number.

I will attach the patch and request review.

Comment 3

[Frédéric Buclin]

(In reply to Kent Rogers [mrbball] from comment #2)
> In my example, there were 200+ occurrences of the
> word "bug" in
> the comments

For each string of the form "bug foo", you have to check if "foo" is a valid bug alias which you are allowed to see. This requires several SQL queries per occurence. I really doubt you see no perf difference.

Comment 4

[Kent Rogers [:mrbball]]

Attachment: Proposed fix, v1

The only characters that are not allowed for aliases are commas and whitespace.
So, Template.pm was simply updated to look for any word following "bug" that
does not contain commas or whitespace.

The 'new Bugzilla::Bug()' call in get_bug_link() already correctly handles
the case where the word following "bug" is not a valid bug alias or id.

Comment 5

[Frédéric Buclin]

OK, I see you updated existing regexps instead of writing new code. This should prevent the perf regressions I worried about in comment 3. :)

Comment 6

[Frédéric Buclin]

(In reply to Frédéric Buclin from comment #5)
> OK, I see you updated existing regexps instead of writing new code. This
> should prevent the perf regressions I worried about in comment 3. :)

... except that a SQL query will still be run every time the regexp sees the word "bug" in a comment, which still means much more SQL calls. So there is no perf regression to catch "bug foo", but then the perf regression is still present when checking what follows the word "bug".

Simply in this single comment, I wrote the word "bug" 4 times, i.e. 4 SQL queries. :(

Comment 7

[Kent Rogers [:mrbball]]

Well, like I said, in a bug with 300+ comments and 200+ references to the word "bug", I
couldn't detect any significant performance degradation.  Even doing a "Long Format"
display of 500 bugs I saw no significant slowdown.  I tried on systems running with and
without mod_perl.

There's obviously extra processing going on and I'm guessing if I measured very closely
I'd be able to detect some slowdown, but it was not "noticeable" to me.

FWIW, I test on Bugzilla 4.4 under MySQL where my SQL server is on the same system as
my web server/Bugzilla.

Comment 8

[:glob ✱]

Comment on attachment 831005 [details] [diff] [review]
Proposed fix, v1

while i like the proposed idea, i also have concerned about the performance overhead the proposed implementation will place on show_bug calls.

we can avoid this by detecting possible 'bug alias' words in comments, but defer linkification until after show_bug is loaded by calling a webserivce method to lookup bugs.

bug 1003719 should provide an appropriate webservice method.

Comment 9

[Kent Rogers [:mrbball]]

(In reply to Byron Jones ‹:glob› from comment #8)
> while i like the proposed idea, i also have concerned about the performance
> overhead the proposed implementation will place on show_bug calls.
> 
Okay, but if it's imperceptible, does the overhead matter?  I'd recommend
trying it yourself.

> we can avoid this by detecting possible 'bug alias' words in comments, but
> defer linkification until after show_bug is loaded by calling a webserivce
> method to lookup bugs.
> 
> bug 1003719 should provide an appropriate webservice method.
>
I don't understand how you will be able to defer linkification, but is there an
estimate/target on a fix for bug 1003719?

I can see where a fix there might *gain* some performance, but if it is not
imminent, I don't see any reason to postpone this fix, which shows no noticeable
*loss* in performance.  If they would both land at the same time and a fix there
resolves this bug, then I guess it doesn't matter.

Comment 10

[Stewart Gordon]

Bug 1003719 has been wontfix'd now.  In any case, I say it would be better to do the lookup when the bug is previewed or saved, and (in the case of a save) store the result of the lookup in the database so that it doesn't have to be looked up again each time the bug is viewed.

Moreover, the whole idea of linking any occurrence of "bug" followed by a bug alias would be likely to trigger false positives when a word that follows "bug" happens to coincide with a bug alias.  I too would like to be able to link to bugs by alias in bug descriptions and comments, but think there should be an explicit notation for doing so.  Maybe using a hash before the alias.  After all, "bug #86194" already works, so why not support "bug #useragent"?  (Are people going to love or hate it looking like a Twitter hashtag?)

Comment 11

[Stewart Gordon]

(In reply to Stewart Gordon from comment #10)
> Bug 1003719 has been wontfix'd now.  In any case, I say it would be better
> to do the lookup when the bug is previewed or saved, and (in the case of a
> save) store the result of the lookup in the database so that it doesn't have
> to be looked up again each time the bug is viewed.

This would have the further benefit that, if the bug alias is later removed or changed, the link will still work.

Comment 12

[Anthony Monti]

Attachment: same problem

Thanks from gubaslumppas1983.