Blockers for the MediaWiki 1.25 release should be added to the MW-1.25-release project.
Tasks deemed as non-blockers will be removed from that project. They can be re-added post release to (potentially) be included in future point releases.
Blockers for the MediaWiki 1.25 release should be added to the MW-1.25-release project.
Tasks deemed as non-blockers will be removed from that project. They can be re-added post release to (potentially) be included in future point releases.
Errm, that's exactly what the existing TM is meant for, IMHO. It is not about (ab)using the project field as a version field ("the problem happened in version 1.25").
Why would using the board at https://phabricator.wikimedia.org/project/board/327/ and having a "really must fix before release OMG world would collapse" column not be sufficient?
(Releasing a 1.25 tarball is of course a valid task itself: I really referred to "tracks the blocking issues" part.)
Because I don't like abusing workboards that much. Workboards are for doing work and making sure it progresses through the stages correctly. Backlog -> Ready -> In progress -> Done or some variation of that.
Why force it all in workboards? There's nothing wrong with using a task like this to track absolute blockers and leaving the other issues in 1.25-release as "known issues" to be documented (if deemed necessary) at release time.
This method would also allow a "Release 1.25.1" task in this project, with blockers for that task. I don't want to have to mess with multiple columns for that stuff; it seems like a waste of dragging.
Every bug in in the MW-1.25-release project should be closed before the release, or they should be bumped to 1.26.
That can also work. MW-1.26-release (nor #mw-26-release ;) ) doesn't yet exist (NB: will that autolink in the future when it does?) so as long as every software bug also has another project attached (mw-gen or what not) so it doesn't get lost that can also work.
I'll leave this task for the act of doing the actual release then.