Closed Bug 1749479 Opened 4 months ago Closed 4 months ago

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

Categories

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

Tracking

()

RESOLVED FIXED

People

(Reporter: marco, Assigned: dkl, NeedInfo)

Details

Attachments

(1 file, 1 obsolete file)

46 bytes, text/x-github-pull-request
Details | Review

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?

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

Flags: needinfo?(mcastelluccio)

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.

Flags: needinfo?(mcastelluccio)

(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.

Flags: needinfo?(mcastelluccio)

(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.

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.

Flags: needinfo?(mcastelluccio)

(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.

Attached file GitHub Pull Request (obsolete) —
Assignee: nobody → dkl
Status: NEW → ASSIGNED

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.

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

Status: ASSIGNED → RESOLVED
Closed: 4 months ago
Resolution: --- → FIXED

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.

Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached file GitHub Pull Request
Attachment #9259137 - Attachment is obsolete: true

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

Status: REOPENED → RESOLVED
Closed: 4 months ago4 months ago
Resolution: --- → FIXED

(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.

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?

Flags: needinfo?(cdenizet)

It's a question for :dkl.

Flags: needinfo?(cdenizet) → needinfo?(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.

Flags: needinfo?(dkl) → needinfo?(aionescu)
You need to log in before you can comment on or make changes to this bug.