Process - GitLab Bot closes sets missed-deliverable label before the cutoff date
Summary
The GitLab Bot sets the missed-deliverable label on the 18th of the month (~12am UTC). The Release Timeline lists the 22nd as the release date: https://about.gitlab.com/handbook/engineering/releases/#timelines. This doesn't line up and causes unnecessary work, as some issues need to have the label removed again. Worse - the issues have incorrect data: the milestone field gets updated by the bot and there is no way to set it back to the original.
More detail
Perhaps the label is added on the 18th to align with the last pick into the auto-deploy branch. This would make sense as it's the last date/time that code changes have to make it into the milestone. However this ignores issues that aren't reliant on core code changes, e.g. they might track docs changes.
This occurred at least twice in 12.5 - where code changes were merged but the issues were still open on the 18th awaiting docs changes or verification: #31376 (closed), #31375 (closed). The bot then applied the label.
There could be a number of reasons to have an issue in the gitlab project that tracks work that happens outside of the auto-deploy cycle, e.g:
- updating documentation
- updating tests
- verifying code changes
- release post work
- www-gitlab-com changes
Related compounding issue
(perhaps worth raising separately)
After the cutoff on the 18th it seems impossible to set any issues as 12.5 - the milestone option is removed from the dropdown. This makes fixing the earlier problems even harder.
Proposals
- Have the Bot update issue milestones on the 22nd rather than the cutoff (e.g. 18th).
OR at least: - Allow milestones to be set for the current release up until the 22nd.
Two counter-points
- Docs are bundled with the release, so doc changes ideally should be merged before the last auto-deploy pick for that branch anyway.
- The vast majority of changes are probably code changes, so it makes sense to have the rule cover the majority of cases and allow manual intervention for the edge cases.
We might not make these changes for the above reasons, but I thought it was worth having a discussion at least.