1050259 - Automatically offer a list of recently filed nightly-regression bugs to nightly users filing a bug

Status: RESOLVED INCOMPLETE

(bugzilla.mozilla.org :: Extensions, defect)

Description

[:Gijs (he/him)]

https://bugzilla.mozilla.org/enter_bug.cgi?format=guided#h=dupes|Firefox

For nightly users, instead of showing an empty box to start with, above the input field we could list (non-dynamic list) the highest-ranking bugs that satisfy the following criteria:

- has nightly-regression keyword
- was filed no earlier than 6 weeks ago
- is still open, or was fixed no more than 2 weeks ago


and sort by a score depending on

- number of votes
- number of CCs
- number of duplicates


We should have the same "Add to CC" buttons as we have in the current dynamic duplicate search thing.

Comment 1

[Dylan Hardison [:dylan] (he/him)]

Context from offline discussion:

> When we're filing a bug in certain products (configured by products.js in the Guided bug entry 
> extension) and the we detect the user
> using a nightly release (by checking the last release in the versions table for the Firefox product),
> we display recently filed bugs (criteria in linked bug) before the find duplicates step.

I assume there is some upward limit on the number of "recently filed nightly bugs", probably 15-25.

Comment 2

[Dylan Hardison [:dylan] (he/him)]

I have implemented this as a step before 'dupes', but in using it that seems sort of annoying. If none of them are the bug you're looking for, you have to continue on. Then you have to look for dupes. I'm going to fold that table the dupes step.

Comment 3

[Dylan Hardison [:dylan] (he/him)]

Attachment: bug-1050259-v1.patch

This patch depends on bug 1050226 and includes code for bug 1050255 (which is a trivial feature).

You'll need to create a nightly-regression keyword to test this (and we'll need to needinfo someone for the description before this is pushed).

Comment 5

[Dylan Hardison [:dylan] (he/him)]

Attachment: bug-1050259-v2.patch

Revised patch, based on the webdev-landing changes, also removed the mysql specific date math.

Comment 6

[Dylan Hardison [:dylan] (he/him)]

Attachment: bug-1050259-v2.1.patch

Forgot to add this one.

Comment 7

[:glob ✱]

Comment on attachment 8520363 [details] [diff] [review]
bug-1050259-v2.1.patch

this patch depends on bug 1050226, which in turn depends on bug 1050232.

i'm clearing this review request to get it off my radar for now.

Comment 8

[Dylan Hardison [:dylan] (he/him)]

Attachment: bug-1050259-v3.patch

This one is also based on the improved layout bug (Bug 1050232).

Comment 9

[:glob ✱]

Comment on attachment 8527263 [details] [diff] [review]
bug-1050259-v3.patch

as this relies on bug 1050232, i'm clearing this review until that bug has an r+'d patch.

Comment 10

[Dylan Hardison [:dylan] (he/him)]

Attachment: bug-1050259-v4.patch

To review, apply after Bug 1050232.

No changes, just rebased on current Bug 1050232,

This patch is independent of bug 1050226

Comment 11

[:glob ✱]

Comment on attachment 8537878 [details] [diff] [review]
bug-1050259-v4.patch

as this relies on bug 1050232, i'm clearing this review until that bug has an r+'d patch.

Comment 12

[:glob ✱]

Comment on attachment 8537878 [details] [diff] [review]
bug-1050259-v4.patch

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

overall this looks good; just a few minor things to fix.

- Bug.recent_nightly_bugs is called twice with identical params when the dupes step is opened
- there's no need to re-execute the query each time the step is opened (eg. changing the product from firefox to core), run it once then set a flag to avoid running it again for this session

it's a bit jarring if there aren't any matching bugs .. the table loads briefly then disappears, resulting in a vertical shift of things.  i'm not sure there's a nice solution to this however.

::: extensions/GuidedBugEntry/Extension.pm
@@ +54,5 @@
> +        JOIN keywords USING (bug_id)
> +        WHERE " . $dbh->sql_in('product_id', $args{product_ids}) . "
> +          AND keywords.keywordid IN (select id
> +                                     FROM keyworddefs
> +                                     WHERE name = 'nightly-regression' OR name = 'regression')

nit: s/select/SELECT/

shouldn't this be just bugs with the 'nightly-regression' keyword?

@@ +59,5 @@
> +          AND ((" . $dbh->sql_in('bug_status', $open_status) . "
> +               AND creation_ts > " . $dbh->sql_date_math('NOW()', '-', 6, 'WEEK') . ")
> +           OR (bug_status = 'RESOLVED'
> +                AND resolution = 'FIXED'
> +                AND delta_ts > " . $dbh->sql_date_math('NOW()', '-', 2, 'WEEK') . "))

you should be using cf_last_resolved not delta_ts

@@ +155,5 @@
> +sub _init_user_on_nightly {
> +    my ($self, $vars) = @_;
> +
> +    $vars->{user_on_nightly} = 0;
> +    my $user_agent = Bugzilla->cgi->user_agent;

it's possible for cgi->user_agent to return undef, which would trigger an uninit warning.

::: extensions/GuidedBugEntry/template/en/default/guided/guided.html.tmpl
@@ +285,5 @@
>  
> +<div id="recent_bugs" class="hidden">
> +  <p>Recently filed nightly regression [% terms.bugs %]: (<a href="javascript:void(0)" onclick="recents.onHide()">Dismiss</a>)</p>
> +  <div id="recents_list"></div>
> +</div>

this should be moved to after #l10n_message

Comment 13

[Dylan Hardison [:dylan] (he/him)]

Just a note that I'm working through responding to the review on this one now.
I'm particularly interested in finding a solution to the aforementioned behavior when there are no matching bugs.

Comment 14

[Dylan Hardison [:dylan] (he/him)]

Well, I've spent *way* too much time on this one:

1) In testing, I realized that setting a flag isn't enough -- if the product changes, the input to Bug.recent_nightly_bugs *may* change.
2) I suspect you were right about the difficulty in not having the jarring behavior for the nightly bugs table. I had thought simply waiting until we get a result to show it would work, but some of the requests can take so long that this results in far *worse* behavior. I actually question the usefulness of this feature, I think it may alienate/scare the user more than it would help us by cutting down on dupes.

Comment 15

[:Gijs (he/him)]

(In reply to Dylan William Hardison [:dylan] from comment #14)
> I actually question the
> usefulness of this feature, I think it may alienate/scare the user more than
> it would help us by cutting down on dupes.

I'm assuming you mean "this feature in general". As an engineer, I can sympathize and I'm sorry that you're having to spend a lot of time on it only to conclude that it might not be worth it. That is always sucky. :-(

In any case, I'm intrigued, can you elaborate on why you think this'll alienate users? (particularly nightly users, who I would have thought are used to a lot!)

(not saying you might not be right, just trying to figure out a rationale here before abandoning ship)

Comment 16

[Dylan Hardison [:dylan] (he/him)]

I've thought on this a bit, and I think it would be better to include the nightly regression bugs in the same table as the possible duplicates, possibly changing that table to indicate if it is a matching dupe or just a regression.

Right now it's pretty jarring to have the regressions show up -- either the table is there and disappears when there are no regressions or it is not there until there are regressions found -- which can take a few seconds.