馃摉 Update release tracking issue template to include LTS checkboxes #25886
Conversation
rcebulko
changed the title
|
Gonna hold off on submit until @mrjoro gives the thumbs up |
| - [x] Release <RELEASE_NUMBER> will be the next LTS | ||
| - [ ] Release <RELEASE_NUMBER> pushed to LTS (<CL submit time>) |
There was a problem hiding this comment.
Having both lines is redundant, no?
There was a problem hiding this comment.
I don't believe so. The first would be checked when a build is first release as experimental/beta (or unchecked). Maybe the first one should always be present. The second one is only relevant if the first one is checked, but that's for indicating that the release has been promoted to LTS. So there would be a 2 week period where the first is checked but not the second.
There was a problem hiding this comment.
My 2 cents: I think the presence of line 42 is enough to indicate that it will be the next LTS, and makes line 41 unnecessary.
There was a problem hiding this comment.
Will address in #26256
| @@ -36,9 +36,14 @@ Note: remove the backticks (``) from the link. | |||
| - [ ] Release <RELEASE_NUMBER> pushed to production (<CL submit time>) | |||
|
|
|||
| <!-- | |||
| If this release will become the next LTS release, add/update the checkboxes above as needed e.g. | |||
There was a problem hiding this comment.
I can see the release engineer not knowing whether it is an LTS candidate. Instructions here may be helpful.
There was a problem hiding this comment.
It's not yet determined how the LTS weeks will be presented (likely via something like RSS or an infrequently-updated calendar/table), but when that is in place we'll add a link here.
There was a problem hiding this comment.
Agree with the idea to link to instructions for determining if a release must go to LTS.
There was a problem hiding this comment.
Will address in #26256
No description provided.