For each weekly MediaWiki wmf.n branch, two separate phabricator objects are created. These are used for tracking two different aspects of the weekly development and deployment cycle but they nonetheless duplicate a lot of effort in creating and maintaining them.
- @greg creates (and the Release-Engineering-Team maintains) a "Deployment blockers" task for each iteration of the train where we track critical bugs introduced in the new branch which block the new branch deployment until fixed or otherwise mitigated. An example of one such blockers task is T163512: MW-1.30.0-wmf.2 deployment blockers
- @Jdforrester-WMF creates and maintains the series of milestones which are organized into #mw-1.nn-release-notes projects. Each weekly version has a project, for example: MW-1.30-release-notes (WMF-deploy-2017-05-30_(1.30.0-wmf.3)) and these are used for tracking bugs fixed in a given version. This includes all bugs not just release-critical issues and there is no assumption of blocking status when a task is added to a release milestone.
There are some advantages of using a "blocking task" for critical issues, however, there are also advantages to the project milestones.
Feature matrix:
| Feature/Function | Blocking task support | Miletone support | Remarks |
| Easily adding a task | Add via related-task ui in maniphest | add via "edit tags" in maniphest | Draw, both have straightforward UI |
| Easily finding and referencing a blocker in remarkup | Tnnn is hard to find / remember | Hashtags are human-readable, memorable and discoverable. | Milestones |
| Easily linking from IRC | Stashbot Tnnn mentions | no | Tasks are a clear winner here |
| Easy creation and navigation between objects in a series | Awkward. Manually editing each task to link up a series is not a good use of our time. | Much easier, can be automated, navigation is built in | Milestones win here although I can work around the problems and automate task series maintenance. |
It would make a certain amount of sense to use milestones for deployment blockers, however, if we did that, the only way to track "blocking" status would be using workboard columns - we'd have a workboard for each milestone and blocking tasks would get moved into the blocking column to distinguish them from other bugs fixed in the same milestone. I'm not sure if that's a good thing or a bad thing.
Certainly milestones and workboards are a good fit for the job and it's sort-of what they were intended for. Blocking tasks are a slightly dirty hack which got carried over from the days of Bugzilla. On the other hand, people are familiar with it. It's a pretty darn good hack, really, it serves it's purpose and is only a bit awkward.
I have more to say about this stuff but this task is my attempt at getting feedback from stakeholders, mainly @Jdforrester-WMF and @greg but also members of Project-Admins might have valuable input. Discussion welcome :).