1749479 - Add "regression" keyword and set "Has Regression Range" to "yes" on all bugs with a non-empty "Regressed By" field

Status: RESOLVED FIXED

(bugzilla.mozilla.org :: Bulk Bug Edit Requests, task)

Description

[Marco Castelluccio [:marco] (back May 20)]

Bugs that have a non-empty "Regressed By" field are clearly regressions, and they clearly have a regression range.

Can we make this bulk change without changing the last update time for bugs?

Comment 1

[David Lawrence [:dkl]]

Should be fairly easy to create a script to do this. How soon would you want it?

Comment 2

[Marco Castelluccio [:marco] (back May 20)]

It'd be great to have it as soon as possible so we can safely re-enable the autonag script that will apply the same change going forward.

Comment 3

[David Lawrence [:dkl]]

(In reply to Marco Castelluccio [:marco] from comment #0)

Can we make this bulk change without changing the last update time for bugs?

Just to clarify this point. Do you mean you didnt want email to be sent for the changes or do you mean that you want the last modified time to remain the same? The latter will require an extra change to be made after the keyword add to roll back the last modified time. Also a side effect will be that the next time a bug is updated, the recipients will get the keyword change mixed into the current change list. I can see the value of rolling back the modification time due to the way some external systems, such as dashboards, etc., use that value to determine when to download new bug data.

Comment 4

[David Lawrence [:dkl]]

(In reply to David Lawrence [:dkl] from comment #3)

(In reply to Marco Castelluccio [:marco] from comment #0)

Can we make this bulk change without changing the last update time for bugs?

Just to clarify this point. Do you mean you didnt want email to be sent for the changes or do you mean that you want the last modified time to remain the same? The latter will require an extra change to be made after the keyword add to roll back the last modified time. Also a side effect will be that the next time a bug is updated, the recipients will get the keyword change mixed into the current change list. I can see the value of rolling back the modification time due to the way some external systems, such as dashboards, etc., use that value to determine when to download new bug data.

That being said, I would rather not do this type of modification as I believe it is important to have consistency in the database always. If I add the keyword, it will be added to the history table with the current timestamp. If I set the bugs delta timestamp back before the last history entry, we then have inconsistency.

One option is to pick a random time before the last update time and add the keyword for then. Not ideal but possibly a better solution.

Comment 5

[Marco Castelluccio [:marco] (back May 20)]

Oh, now I understand why I see inconsistencies from time to time.

Ideally, we want this change to be done without sending emails and without changing the last update time (so other tools relying on the last update time are not triggered on these bugs).

(In reply to David Lawrence [:dkl] from comment #4)

One option is to pick a random time before the last update time and add the keyword for then. Not ideal but possibly a better solution.

Could we set the field with a time that is equal to the last update time or even to the time the "Regressed By" field was changed? This would be perfect.

Comment 6

[David Lawrence [:dkl]]

(In reply to Marco Castelluccio [:marco] from comment #5)

Oh, now I understand why I see inconsistencies from time to time.

Ideally, we want this change to be done without sending emails and without changing the last update time (so other tools relying on the last update time are not triggered on these bugs).

(In reply to David Lawrence [:dkl] from comment #4)

One option is to pick a random time before the last update time and add the keyword for then. Not ideal but possibly a better solution.

Could we set the field with a time that is equal to the last update time or even to the time the "Regressed By" field was changed? This would be perfect.

Seems like it would be fine. I will start working on the script now.

Comment 7

[David Lawrence [:dkl]]

Attachment: GitHub Pull Request

Comment 8

[David Lawrence [:dkl]]

Merged to master.
https://github.com/mozilla-bteam/bmo/commit/bb1f89ff3d2094c157d6f6ce098dce9549803708

Once the script is on production, I will be able to run it and close this bug.

Comment 9

[David Lawrence [:dkl]]

Actually I need to close this as part of the deployment process. Will comment when the migration is complete.

Comment 10

[David Lawrence [:dkl]]

Reopening as the script needs additional changes to narrow down the query results to bugs where the 'Has Regression Range' field is enabled and not all bugs. I only updated a couple as a test when I realized this issue.

Comment 11

[David Lawrence [:dkl]]

Attachment: GitHub Pull Request

Comment 12

[David Lawrence [:dkl]]

Merged new version of script to master. Will run again with the improved query.
https://github.com/mozilla-bteam/bmo/commit/731fe4190fbb81da18bd6e3368d56089640a85a9

Comment 13

[David Lawrence [:dkl]]

(In reply to David Lawrence [:dkl] from comment #12)

Merged new version of script to master. Will run again with the improved query.
https://github.com/mozilla-bteam/bmo/commit/731fe4190fbb81da18bd6e3368d56089640a85a9

The migration script has been run. Update took around an hour and updated ~9.4k bugs.

Comment 14

[Alexandru Ionescu (needinfo me) [:alexandrui]]

We are trying to set this field by default to yes when we file regression bugs.
https://github.com/mozilla/treeherder/blob/1e3d5ce1a0cd64f9f38eb75dde4f1e3ede0e8a28/ui/perfherder/alerts/StatusDropdown.jsx#L194
It doesn't work. What are we doing wrong?

Comment 15

[Calixte Denizet (:calixte)]

It's a question for :dkl.

Comment 16

[David Lawrence [:dkl]]

(In reply to Alexandru Ionescu (needinfo me) [:alexandrui] from comment #14)

We are trying to set this field by default to yes when we file regression bugs.
https://github.com/mozilla/treeherder/blob/1e3d5ce1a0cd64f9f38eb75dde4f1e3ede0e8a28/ui/perfherder/alerts/StatusDropdown.jsx#L194
It doesn't work. What are we doing wrong?

First, is the product being used for enter_bug.cgi always definitely one of the following?

"Core Graveyard"                      => [],
"Core"                                => [],
"DevTools Graveyard"                  => [],
"DevTools"                            => [],
"External Software Affecting Firefox" => [],
"Firefox Build System"                => [],
"Firefox for Android Graveyard"       => [],
"Firefox for Android"                 => [],
"Firefox for iOS"                     => [],
"Firefox Graveyard"                   => [],
"Firefox"                             => [],
"GeckoView"                           => [],
"NSS"                                 => [],
"Tech Evangelism Graveyard"           => [],
"Tech Evangelism"                     => [],
"Toolkit Graveyard"                   => [],
"Toolkit"                             => [],
"WebExtensions"                       => [],

These are the only products where the field is visilble.