Skip to content

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)

Screen_Shot_2019-06-10_at_7.28.36_AM

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 on Jun 23rd
  • %12.1 Jun 8, 2019–Jul 22, 2019 - close, reschedule and add labels on Jul 23rd
  • %12.2 Jul 8, 2019–Aug 22, 2019 - close, reschedule and add labels on Aug 23rd

Screen_Shot_2019-06-10_at_7.28.32_AM

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.

Screen_Shot_2019-06-10_at_7.29.23_AM

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.

Screen_Shot_2019-06-12_at_10.48.15_AM

  • 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.

Edited by Mek Stittri