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)
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•1 year ago
|
||
Should be fairly easy to create a script to do this. How soon would you want it?
|
Reporter | |
Comment 2•1 year 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•1 year 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•1 year 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•1 year 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•1 year 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•1 year ago
|
||
|
|
Assignee | |
Comment 8•1 year 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•1 year ago
|
||
Actually I need to close this as part of the deployment process. Will comment when the migration is complete.
|
|
Assignee | |
Comment 10•1 year 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•1 year ago
|
||
|
|
Assignee | |
Comment 12•1 year 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•1 year 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 hidden (off-topic) |
| Comment hidden (off-topic) |
| Comment hidden (off-topic) |
| Comment hidden (off-topic) |
Description
•