There are numerous Phabricator tasks (most deprecation tasks like T250316 are one example) which are marked as stalled pending a MediaWiki release branch cut. I'd like to see a way (a tag or something similar) that tracks all of them for a specific release so that it's easier to find the tasks that now can be actioned as we've just cut 1.37.
Description
Description
Related Objects
Related Objects
Event Timeline
Comment Actions
For example MW-1.37-release/MW-1.38-release (haven't checked others) has a "To deprecate or remove" column on it's work board, Is something else needed?
Comment Actions
My understanding is that those columns are for things that need to happen for that release, not *after* that release.
Comment Actions
This idea makes a lot of sense and I've also wondered a bunch of times, between random after 1.xx free-text suffixes in task titles, potential project tags or columns, or a potential dedicated task specifically about cutting a branch for the next version and making lots of other tasks depend on it, or per-task due dates (if cutting a branch actually happened at a predictable date). :-/
Comment Actions
Perhaps:
Add a new phab task status (stalled until after next MW release)
Run a batch change after every release to switch "stalled until after next MW release" to "open"
Reuse status for the following release, repeat
Comment Actions
@DannyS712: Statuses are global across all and any projects; I am very reluctant to add dropdown clutter for a single codebase (plus its extensions) only :)
(stalled until after next MW release)
This already exists; it's called "stalled"
Comment Actions
Personally I think this is a self-invented problem, tasks only need to stay stalled because we're using the same task for deprecation and removal. I think those should be two separate tasks, one for deprecation (intent to remove), and then another for the actual removal (a hard breaking change). The deprecation task is closed once it's done, and the removal task stays stalled until it's ready.
Comment Actions
Doesn't this have the exact same problem, but just on a different task?
It could be, yes... If there was more clarity how #mw-1.xx-release tags are [not] meant to be used (hard blockers for a release? nice-to-have-but-no-problem-if-not for a release? wishful thinking of some devs?) and if there was active triage/gatekeeping on tickets with such tags, that problem could be avoided. I think.
Comment Actions
The Technical-Debt (Deprecation process) workboard can be used to discover these if you like.
And indeed the release tags also have a column for deprecating or removing, so you can place it in that column of the future release to avoid being forgotten.
I support the notion of splitting these if for some reason the task staying open is undesirable in a particular context (e.g. part of a sub tree with lots of other work and want to close it out). Although I do note that for small ones with very little usage it can reduce overhead to just keep the same task open, mark it as stalled for a while, and keeo assigned to the same person.
I agree these workflows appear to be working, and for myself are working well. With two other voices above saying more or less the same, and providing answers for the various use cases brought up, perhaps this is resolved then? As always, we could perhaps improve documentation on one of these workboards.
find the tasks that now can be actioned as we've just cut 1.37.
For this we also have a maintenance script, which I believe @Jdforrester-WMF uses from time to time for tasks such as T232864, and T259108. These mostly deprecations that did not have their own dedicated tasks.