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
()
People
(Reporter: marco, Assigned: dkl, NeedInfo)
Details
Attachments
(1 file, 1 obsolete file)
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?
Assignee | ||
Comment 1•4 months ago
|
||
Should be fairly easy to create a script to do this. How soon would you want it?
Reporter | ||
Comment 2•4 months ago
|
||
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.
Assignee | ||
Comment 3•4 months ago
|
||
(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.
Assignee | ||
Comment 4•4 months ago
|
||
(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.
Reporter | ||
Comment 5•4 months ago
|
||
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.
Assignee | ||
Comment 6•4 months ago
|
||
(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.
Assignee | ||
Comment 7•4 months ago
|
||
Assignee | ||
Comment 8•4 months ago
|
||
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.
Assignee | ||
Comment 9•4 months ago
|
||
Actually I need to close this as part of the deployment process. Will comment when the migration is complete.
Assignee | ||
Comment 10•4 months ago
|
||
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.
Assignee | ||
Comment 11•4 months ago
|
||
Assignee | ||
Comment 12•4 months ago
|
||
Merged new version of script to master. Will run again with the improved query.
https://github.com/mozilla-bteam/bmo/commit/731fe4190fbb81da18bd6e3368d56089640a85a9
Assignee | ||
Comment 13•4 months ago
|
||
(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•3 days ago
|
||
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?
Assignee | ||
Comment 16•18 hours ago
|
||
(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.
Description
•