[1.12] Code slush/freeze process change proposal
Timothy Pepper
With code slush (Aug. 28) and code freeze (Sept. 3) coming soon, I want to have a brief discussion of what are code slush and code freeze anyway? …And propose a simplification:
Slush is a period preceding the freeze where we’re slightly less strict about what merges into master. The freeze is a period when we are VERY strict about what merges into master. The code freeze strictness is enforced by automation and amounts today to requiring:
* priority/critical-urgent
* SIG label
* kind label
* lgtm and approved
* milestone v1.12
* status/approved-for-milestone
These latter two must be set by a group of folks who represent SIG leadership (the GitHub team “kubernetes-milestone-maintainers”).
With the milestone munger disabled earlier in the cycle, the “status/*” labels are now effectively redundant given they are applied by the same leader set as issues the /milestone command. And it’s done often along with all the other labels in a frenzy of argh how do I get this freaken PR to merge?!?!
Given that clear frustration in the developer base, plus detailed discussion amongst SIG-Release and the 1.12 Release team assuring ourselves we can safely manage without this label, I propose we drop the “status/*” label requirement in the upcoming code freeze, leaving only “/milestone v1.12”, “priority/critical-urgent” and the other normal merge required lables.
Lazy consensus: If there are no unaddressed objections by Monday 3pm PT Aug 27, the code PR for enforcing freeze on Sept. 4 will not include the “status/approved-for-milestone” label requirement.
--
Tim Pepper
Orchestration & Containers Lead
VMware Open Source Technology Center
Stephen Augustus
--
You received this message because you are subscribed to the Google Groups "Kubernetes Milestone Burndown" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-milestone...@googlegroups.com.
To post to this group, send email to kubernetes-mil...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-milestone-burndown/700A39F7-A366-49F1-A3E8-075D192E76BA%40vmware.com.
For more options, visit https://groups.google.com/d/optout.
jbe...@redhat.com
I want this change to go ahead, though, any thoughts on stopping accidental merges?
Timothy Pepper
Given reduced merge volume during code freeze and the release-X.YY branch content coming from merges and cherry picks from master branch…release branch manager (with additional release team eyes helping) must watch for commits on master that shouldn’t have been merged. If observed, these will either need reverted, or cherry picked around. This is obviously weaker than a hypothetical mechanically enforced system where no PR merges without a large hierarchy of checks like requiring an associated critical urgent bug issue or feature issue (where a feature issue must have KEP associated and approved for milestone before feature freeze), but I’m not proposing we roll out something like that this week.
This responsibility as last chance safety gatekeeper is a responsibility already on the shoulders of the release team. But it works best when SIG leadership (approvers and milestone maintainers) also are rigorous. Regardless of automation and mechanism we need a culture of caution and rigor at release time.
I think redundant layers actually work against that desired rigor by encouraging keyboard mashing (I must now apply all the labels to force a merge!) as a normal behavior.
--
Tim Pepper
Orchestration & Containers Lead
VMware Open Source Technology Center
--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
kubernetes-de...@googlegroups.com.
To post to this group, send email to
kuberne...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/kubernetes-dev/86908fca-d546-41c6-9ee0-5cfbb43c10ef%40googlegroups.com.
jbe...@redhat.com
Timothy Pepper
No blocking objections observed, and multiple positive responses across k-dev and SIG leadership so…lazy consensus achieved.
We will not require the “status/approved-for-milestone” label going forward.
Please do continue to use the “/milestone”, “/priority”, “/kind”, and “/sig” prow commands to accurately describe issues and PRs.
--
Tim Pepper
Orchestration & Containers Lead
VMware Open Source Technology Center
From: <kuberne...@googlegroups.com> on behalf of "jbe...@redhat.com" <jbe...@redhat.com>
Date: Monday, August 27, 2018 at 2:40 PM
To: Kubernetes developer/contributor discussion <kuberne...@googlegroups.com>
Subject: Re: [1.12] Code slush/freeze process change proposal
To be clear, I don't think that "accidental merges" is a sufficiently bad problem to block this clear improvement in the process. I just suspect that we'll eventually (1.13) need to develop another mechanism to deal with it.
--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
kubernetes-de...@googlegroups.com.
To post to this group, send email to
kuberne...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/b94461b8-9a06-45a8-9c01-f135f8ca95a4%40googlegroups.com.