Next iteration of closing milestones and moving issues and MRs to the next milestone
This is the next iteration of #3555 (closed)
Currently, we close out a milestone on month m+1
on the 7th, where milestone m
is marked as closed. See Milestone Cleanup https://about.gitlab.com/handbook/engineering/workflow/#product-development-timeline
When this happens all unfinished m
issues and merge requests are automatically moved to milestone m+2
, with the exception of security issues. See https://about.gitlab.com/handbook/engineering/workflow/#product-development-timeline
For %11.11 we would have closed the milestone on Jun 7th. (Delay due to my out sick)
Proposal
With the new continuous release and deployment, we should just close out the milestone on the last day of the development period. This means on the 23rd of each month. These are the dates specified in the milestone itself
-
%12.0
May 8, 2019–Jun 22, 2019
- close, reschedule and add labels onJun 23rd
-
%12.1
Jun 8, 2019–Jul 22, 2019
- close, reschedule and add labels onJul 23rd
-
%12.2
Jul 8, 2019–Aug 22, 2019
- close, reschedule and add labels onAug 23rd
Updating automatic triage
The following should also be updated.
Missed deliverable
Currently, we add missed deliverable when issues labeled ~Deliverable
has passed the feature freeze date.
We should do this on the 23rd
when the milestone has closed as well.
- Change the date when this runs to be on the day the milestone has expired.
- Update message
Milestone %"#{milestone.title}" for this ~Deliverable issue has expired and the issue is considered a ~"missed-deliverable".
- Add the label missed deliverable
Removing feature freeze on the 7th
Currently, we mark issues past the 7th as a missed item, we will be removing this and align the cleanup with the above.
Generic missed items clean up
Currently when we close the milestone all the issues in that milestone is moved m+2
. This is original implementation in #3555 (closed). We should clean this up more frequently and reduce the noise.
- Change the date when this runs to be on the day the milestone has closed.
- Automatically move this to
m+1
the next milestone instead. - Add
missed:x.y
and continue to generate a report on what was moved to the next milestone.
Edge cases
- We will still exclude issues with
~security
to not disrupt the security release process. - Any additional cases I might have missed.
Action items
-
Remove feature freeze notification -
Update triage ops logic to move to the next milestone when a milestone is closed on the 23rd -
Update missed deliverable to use the same mechanism -
Updated generic missed items to use the same mechanism
@godfat @markglenfletcher @marin, would like to hear your thoughts first before opening it up to all engineering managers and etc.