Automate the launchpad release bug targeting process
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Evergreen |
Confirmed
|
Wishlist
|
Unassigned | ||
Bug Description
Currently, there is a lot of tedious work in launchpad after a release is cut:
* Update "Fix Committed" bugs tied to that release to "Fix Released"
* Create a new milestone for the next release.
* If a bug wasn't released, target it to the new milestone.
It should be done as the Evergreen BugMaster account, rather than as an individual account, since this prevents bug subscribers from being flooded with a bunch of emails from launchpad. If it comes from the BugMaster account, people's email filters can catch it, or they can batch delete those emails.
Jason Stephenson wrote a script to do this that would be a great starting place, which is attached as part of a zip file.
From Jason:
* One challenge are the API limits: "It never worked all that well because there's a limit to how many updates you can make in a certain amount of time"
* "The scripts predate the bugmaster account, but the way you login via oauth and authorize the application, it could be run as the bugmaster without requiring extra logins later."
See the complete IRC discussion: http://
| Jane Sandberg (sandbergja) wrote | #1 |
| Galen Charlton (gmc) wrote | #2 |
| Changed in evergreen: | |
| importance: | Undecided → Wishlist |
| status: | New → Confirmed |
Noting that there's also a procedural change to consider to reduce the manual work required (and/or reduce the changes of hitting API limits): assign specific milestones only at the point where it is nigh certain that a fix will make it into that release.
In practice, I think that boils down to the committer making the assignment at the point of merging the change or somebody making a commitment to shepherd the bugfix over the next few days.
Doing this would also reduce the overall email churn, whether or not somebody filters out Bugmaster mail or not.
Targeting to series without selecting a milestone could continue to be a way of making assertions about the affected versions for a bug or requesting backports to maintenance versions.