Thanks for writing up the proposal. Here a couple of things:
“08:00 to 12:00 AMS time”. Please change to an actual timezone, maybe add several different ones with their respective times.
This proposal together with the one posted on code.blender.org don’t give a clear picture as to what goes in and what not. In particular I feel that the proposals lack how triaging is handled in whole.
I believe that the current proposals combined fail to address regressions. A regression is something that also should be included next to critical issues. It would be good if there was a clear documentation on what actually is a critical issue.
The passage “LTS reports are treated the same as for previous releases – if already fixed in master, the report is to be closed.” is troublesome. This should be handled differently: if a report for an LTS release is valid, even already fixed in master, it should still be tagged for the LTS release in the case of regressions and critical issues.
The triaging and testing process should be adapted to include LTS as well. The following flow is what at minimum should be done: 1) test against latest LTS - if valid regression or critical accept for LTS, 2) test against upcoming blender-vx.xx-release - if valid issues, accept for blender-vx.xx-release, 3) and finally test against master.
The phabricator task section is insufficient for triaging purposes.
In your bf-committers message, and with online discussion it is stated that “The process is written so it won’t effect regular development.”. I have said it before, and I will say it again: work on LTS __is__regular development. I can’t shake the feeling that the current proposals and approaches, along with existing mindset, is insufficient to do proper LTS.
I’d like us to reiterate the current proposals, and make sure the entire process becomes an intrinsic part of how we develop Blender - not a tacked on afterthought.
edit: some text I forgot to add
To help with the tagging of tasks before they end up on the parent task I would suggest adding a project per LTS release. That way we aren’t restricted to having only one milestone tag per issue (2.90 vs 2.83 for instance)
I think having a parent task alone is insufficient for triaging and tracking issues, especially when tasks are still being considered for LTS before being added to the parent task.