[FEEDBACK REQUESTED] When should we lift the milestone restriction on kubernetes/kubernetes?

[Stephen Augustus]

Hi fellow leads!

As you may know, towards the end of the Kubernetes 1.19 release cycle, we put forth a proposal and imposed a milestone restriction on merges to the `master` branch unless they were targeted for the 1.20 milestone.

This restriction allowed us to better control merges and give some sorely-needed attention to bugs, failing tests, and the underlying CI infrastructure.

I've been sending periodic updates on our phased reopen for 1.20 development.
At this point, all of the pressing work we had planned on doing is complete.

So the next question is, "When do we remove the milestone restriction and get back to 'business-as-usual'?".

To paraphrase some things I mentioned in last week Thursday's Leads meeting...

I'm in favor of leaving the milestone restriction in place for the entire cycle.

I think there's a reasonable about of late-cycle work that is handled by the Release Team to determine whether or not something needs to be in-milestone, and this would assist in alleviating some of that as we move into the holidays later in the year.

From a SIG/component-level perspective, this will of course carry some additional burden on existing milestone maintainers.
At the same time, I think this is a reasonable burden, given the expectations of a milestone maintainer.

Some of this can burden can be mitigated by scaling up your area's milestone maintainers and having discussions about how triage is done in your SIGs.

Of course, this is a decision we should all make together and I'd like to solicit feedback here.

Can we set a clock to make a call on this by Friday, September 18, EOD US Eastern?

-- Stephen

[Wojciech Tyczynski]

 I would like to understand if the proposal is "leave that milestone restriction for 1.20 timeframe", or "leave the milestone restriction for some undefined future (longer than 1.20".

  I'm personally not convinced this cycle is very different from others.

 [To be clear - I'm still not neither against nor for the proposal - I'm trying to better understand the implications...]

--
To unsubscribe from this group and stop receiving emails from it, send an email to leads+un...@kubernetes.io.

[Aaron Crickenberger]

I'm still not sure whether I'm in favor of this or not.

On the side of keeping the restriction in place,  I am concerned that we lack sufficient awareness and policies to quickly identify when our CI Signal has regressed and what caused the regression.  I know WG Reliability wants to codify enforcement of some sort around this.  Maybe we should wait until the WG has formed and is in agreement that we'll be able to act expediently.

On the side of removing the restriction, we still lack a clear documented understanding of when / why milestone should be applied (https://github.com/kubernetes/sig-release/issues/320).  Thus keeping the restriction in place may at best introduce more arbitrary friction, but not more consistency or focus in terms of what we're choosing the land and why.

Maybe a different way to think about this is to ask: what would we use the milestone restriction to prevent from landing in the next two months?

- aaron

[Stephen Augustus]

Hearing no great reasons to keep the milestone restriction in place, I've opened https://github.com/kubernetes/test-infra/pull/19277 to remove it.

If you have strong objections to dropping the milestone restriction, please comment on the PR.

I'll release it for merge Monday, September 21, EOD US Eastern.

-- Stephen