kubernetes
/
community
mirror of https://github.com/kubernetes/community.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

adding meeting minutes to yearly archive

This commit is contained in:
Jim Angel 2023-05-31 10:06:19 -05:00
parent 80cdcea691
commit d3e320c0e9
6 changed files with 8698 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

358
sig-release/meeting-notes-archive/2017.md Normal file
View File

@ -0,0 +1,358 @@
## 19 December 2017
* [Volunteer for 1.10 release team!](https://github.com/kubernetes/sig-release/pull/49)
## 7 November 2017
Agenda
* Revisit release process automation discussion
* Federation wants to release for 1.9 but is now in a separate repo
* @david-mcmahon: I can’t make this time slot unfortunately, but please send me any docs or information on what exactly you're trying to achieve here.
* My team is working on a few solutions to assist in releasing non-core Kubernetes components. Most don’t need the full orchestration that[ anago](https://github.com/kubernetes/release#kubernetes-release-process) provides for k/k.
* See some related work[ here for cluster-registry](https://github.com/kubernetes/cluster-registry/compare/master...javier-b-perez:cloud-builder) building using Google Cloud Builder
* Also the recent related[ update to push-build.sh](https://github.com/kubernetes/release/pull/444) to support federation pushes.
* Can we apply[ milestone automation](https://github.com/kubernetes/community/blob/master/contributors/devel/release/issues.md) to[ PRs too](https://github.com/kubernetes/sig-release/issues/26)? [enisoc]
## 24 October 2017
Agenda
* [Code freeze enforcement](https://github.com/kubernetes/features/pull/493)
## 10 October 2017
Agenda
* Kops team would like to partner with sig-release to have kops release process automated. Draft outline:[ https://docs.google.com/a/cnmconsulting.net/document/ d/1i29ntaLjRVmQuUkUXfnkL3_jLby38At98kaE5VEJvg8/edit?usp=sharing](https://docs.google.com/a/cnmconsulting.net/document/d/1i29ntaLjRVmQuUkUXfnkL3_jLby38At98kaE5VEJvg8/edit?usp=sharing)
* Want to partner with SIG Release
* Focus on release mechanics
* Where to put trusted keys?
* Want to find common denominators around projects
* General guidelines are important, and perhaps an end-state where artifacts get published
* Define how we handle release artifacts and build backwards from there
* Need to put something on the end of the test infra that does the push
* Q: Who can make a call on where the bits in the registry live? \
A:
* Notes
* Reminder about[ release roles for 1.9](https://docs.google.com/spreadsheets/d/1NGEtufpSfYlJwsB_0D9gF80Y24JQEreut9gT_QIN6Kk/edit#gid=0)
* solidify the roles
* When/How do release roles get finalized?
* Jaice will send announcement to begin timer on lazy consensus
* Product Management reboot proposal[ draft](https://docs.google.com/document/d/113gnr3tKXv79J0IYHyg6VbQwLfb-sCYGphW4D9dLZ_E/edit#)
* Updated milestone munger has been deployed
* Next step is migrating to a prow plugin
* Better maintainability
* Enables slack notifications
## 29 August 2017
Agenda - Recording
* Attending
* Jaice Singer DuMars
* Radhika
* Jennifer Rondeau
* Mehdy Bohlool
* Caleb Miles
* Aaron Crickenberger
Notes:
* 1.8 Release update
* [Issues](http://bit.ly/18issues)
* [Release notes](http://bit.ly/18relnotes)
* [Feature tracking](http://bit.ly/18features)
* [Tests](http://k8s-testgrid.appspot.com/release-master-blocking#Summary)
* Anything else we need to be tracking
* Upgrade tests are failing - Eric and Mehdy will look at these
* Serial tests are looking mostly ok
* SIGs are not checking off their release note additions, so we need to closely monitor this
* Issue automation for milestone labeling is merged, needs an announcement
* Getting a Prow plugin to limit who can apply “approved-for-milestone” label, akin to LGTM controls
* Use of[ OWNERS_ALIASES](https://github.com/kubernetes/kubernetes/blob/master/OWNERS_ALIASES) might be fraught with peril
* Short term, we may not need auditability as a primary concern, and will defer to teams
* Aaron: SIG Release creates a GitHub team for this purpose, specifically
* Having a limited entry point into the team may increase security around the implementation
* Notify: kubernetes-dev, kubernetes-sig-leads, kubernetes-sig-release, Community meeting
* Caleb will help Maru create the team
* What are the true release-blocking tests? How do we actually get a 100% passing version
* A release-blocking job that only runs X days may not be useful
* More frequent runs may be required, and ergo removed from required if it can’t be
* Currently many failing GKE/GCE jobs
* Need to establish accountability
* Guidelines around “how long can something block the submit queue”?
* Triage + plan to resolution / project-wide SLA = policy
* Who actually owns these tests?
* Jaice will draft _something_ here
*
* Announcements?
*
## 15 August 2017
Agenda - Recording
* Attending
* Aaron Crickenberger
* Jaice Singer DuMars
* Phillip Wittrock
* Mehdy Bohlool
* Steve Perry
* Jennifer Rondeau
* Radhika
* Caleb Miles
* Garrett Rodrigues
* Brian Tardell
* Ryan Kubiak
* David McMahon
Notes
* 1.8 Release update
* Feature freeze exceptions
* [https://github.com/kubernetes/features/issues/382](https://github.com/kubernetes/features/issues/382)
* [https://github.com/kubernetes/features/issues/384](https://github.com/kubernetes/features/issues/384)
* [https://github.com/kubernetes/features/issues/383](https://github.com/kubernetes/features/issues/383)
* [https://github.com/kubernetes/features/issues/386](https://github.com/kubernetes/features/issues/386)
* [https://github.com/kubernetes/features/issues/387](https://github.com/kubernetes/features/issues/387)
* Jaice would be deferent to features which are already in progress
* Jaice to take ownership of the PRs with Ihor and see what their status is ~ _Done as of 8/16 JSD_
* **Question**: how does the feature freeze impact the release cadence? **<-** **Jaice **Idea is to have some idea what work is planned before coding starts. Are these features “funded” with development efforts. Ideally we would have a release planning session where SIGs present what work is scheduled, what cross SIG dependencies exist, and SIGs would be accountable to their commitments
* [https://github.com/kubernetes/features/blob/master/release-1.8/release-1.8.md](https://github.com/kubernetes/features/blob/master/release-1.8/release-1.8.md)
* Still no alphas cut?
* Should be three already. Is this a risk?
* Jaice: it is a risk, we have not have met the criteria for releasing with regards to CI
* Caleb: I believe this is
* Grod: next (last) alpha is scheduled for 23rd August. We should aim to have all tests passing by then. Suggest using 23 August as hard deadline for all tests passing
* Thur 17 plan to cut an alpha - even if tests aren’t passing
* Meant to validate release cutting infra is correct
* Need to find a branch manager for weeks Adam is out
* [Merged PRs in the 1.8 milestone](https://docs.google.com/spreadsheets/d/18V_8YvqemC96W17O_3WZ6H_kS7r77NAI9FqUHAM2MS0/edit?usp=sharing) with release-note=true
* [GitHub query](https://github.com/kubernetes/kubernetes/pulls?utf8=%E2%9C%93&q=is%3Apr%20is%3Amerged%20label%3Arelease-note%20milestone%3Av1.8)
* Dawn’s proposal lives! Jago hiring 2 people to work on the coding
* Strive to link issues
* How do we get more support for all the back end processes/bots/CI?
*
* [Docs PRs](https://github.com/kubernetes/features/pulls) in flight
* Radhika sending an email to each group, then collect, edit and apply tech writer magic sprinkles
* re: action required, need to untangle release note PRs
* Better release note template might help
* 2 classes of release notes:
* Items in the k/features
* items in PRs against k/k ~ not organized …
* Planning for roll-out of milestone-maintaining munger
* Proposal:[ https://github.com/kubernetes/community/blob/master/contributors/devel/release/issues.md](https://github.com/kubernetes/community/blob/master/contributors/devel/release/issues.md)
* PR:[ https://github.com/kubernetes/test-infra/pull/4052](https://github.com/kubernetes/test-infra/pull/4052)
* If you don’t label it sufficient for triage, it warns, then moves out of the milestone
* priority, type, SIG
* 3 day grace period + pings to GH UIDs (no email currently)
* Need to send email to all the SIGs / present at community meeting
* For critical/urgent they warn without kicking out
* labels will allow us to track issues that get ejected
* Initial grace period could be 1 weeks - Enough to give SIGs a chance to take action
* This is step one, but the proposal has additional work items
* Is there a notion of SIGs acknowledging ownership?
* Maru needs a cool hat
## 1 August 2017
Agenda - Recording
* Attending
* Jaice Singer DuMars
* Erick Fejta
* David McMahon
* Aaron Crickenberger
* Phillip Wittrock
* Dan Gillespie
* Joe Betz
* Steve Perry
* Maru Newby
* Caleb Miles
Notes: JSD
* 1.8 Release update
* Feature freeze status check
* Any issues with no/wrong SIG
* This is a “stability” release, so are there things that we see in the feature queue that should be deferred?
* Does anyone know of notable missing features?
* Release team roll call
* [https://github.com/kubernetes/features/blob/master/release-1.8/release_team.md](https://github.com/kubernetes/features/blob/master/release-1.8/release_team.md)
* Release risks
* Upgrade testing
* Issue inclusion process ~_ need a way to decide what a substantial PR is for the contrib ladder_, also ensure that PRs are properly documented for release notes
* Is Dawn’s proposal being staffed?
* Work to extract release notes from the issue has not been completed
* This part happens in[ relnotes](https://github.com/kubernetes/release/blob/master/relnotes) and I can do this [@david-mcmahon]
* Need to ensure there’s a clear value prop for the requirement
* Phil’s proposal needs some dry run
* kops test failures and escalation of[ this](https://github.com/kubernetes/kubernetes/issues/49981)
* escalate to Justin SB / Kris Nova / Luis
* kops is unique in that it’s fully owned
* Test fails because of X and is owned by SIG Y, Z, B
* Ownership gets dropped so it’s difficult to get traction
* Release team has to find someone to fix it, which can be circular
* When low-level or high-impact tests fail, hard to know where to send this
* etcd testing specifically is tricky to understand
* umbrella issue for putting [sig-foo] in e2e test names ~ on Aaron’s backlog + Phillip Wittrock
* [https://github.com/kubernetes/kubernetes/issues/49161](https://github.com/kubernetes/kubernetes/issues/49161)
*
* Escalations for SIGs: mailing list / Slack / Individuals
* Put ACTION REQUIRED in the subject or IMPORTANT
* SIG rep for release if you have a SIG-owned issue or feature in the release ( if ! sig-lead ; then someone else)
*
* upgrade and serial tests - massive failures [pwittrock]
* Upgrade - Mehdy Bohlool?
* These have been highly problematic in past releases
* Serial - ???
* Must pass before a release is cut currently, but not blocking
* Could SIG merge be blocked by failing serial test?
* SIG-specific tests are the only way to validate a SIG’s contribution, so if it’s not fixed, then merges for code needing its validation should be blocked
* Break up serial jobs and apply them to a cluster that is not subject to prior changes
* Write this up so we can get feedback ASAP [ Maru & Phillip ]
* Execution frequency would be lowered
* etcd3 test flakes [pwittrock]
* [Hooking in deb/rpm publishing in anago](https://github.com/kubernetes/release/issues/365) [calebamiles]
* A/B/RC/Final
* Needs someone from Google because of the bucket (Mike Danese has done this up to now)
* Permissions model may be interfering
* Anago is OSS so someone could update it, but there may be some tripwire around Google accounts vs. not
* Caleb will connect with mikedanese@ (@mikedanese) to get a walkthrough
* Also reach out to djmm@ (@david-mcmahon) for any details on the included google layer that does google-specifics (push)
## 18 July 2017
Agenda -[ Recording](https://youtu.be/I0KbWz8MTMk)
* Attending
* Jaice Singer DuMars
* Phillip WIttrock
* Caleb Miles
* Dan Gillespie
* Aaron Crickenberger
*
* Notes: JSD
* 1.8 Release Team [DG]
* Empty
* Aaron willing to help but cannot commit to a role full-time
* Assisted with issue triage and pushing PR’s forward last time
* Trying to highlight escalation paths
* Companies should be funding a role, especially in terms of commitment to the project
* Going to advertise for more role involvement
* At community meeting we will announce that we have a tentative lead/second & ask (final) if there are any other nominations
* Also posting to SIG release list
* Alpha release stability needs to be understood - no more releases without green tests
* Phil is going to check on Google-specific roles
* Establishing release criteria / standards / due dates [DG]
* **Set[ release due dates](https://github.com/kubernetes/features/pull/305) for all of these items**: (merge[ https://github.com/kubernetes/features/pull/305](https://github.com/kubernetes/features/pull/305) )
* CI test signal
* Which suites/jobs are required?
* As of 1.7 anago polls testgrid’s config.yaml for release blocking jobs;[ issue for context](https://github.com/kubernetes/release/issues/340)
* Anago polling testgrid’s config.yaml[ https://github.com/kubernetes/release/blob/master/lib/releaselib.sh#L115](https://github.com/kubernetes/release/blob/master/lib/releaselib.sh#L115)
* The specific set of tesjobsts from config.yaml[ https://github.com/kubernetes/test-infra/blob/master/testgrid/config/config.yaml#L2036-L2119](https://github.com/kubernetes/test-infra/blob/master/testgrid/config/config.yaml#L2036-L2119)
* Of note: upgrade jobs are not included in this list
* Of velocity note: slow jobs are
* What tolerance for flakes do we expect?
* ie. 5 passes in a row on a commit we are releasing
* In the past, we as humans have used “3 passes in a row”
* Anago appears to look at 2 passes in a row if[ this comment in find_green_build](https://github.com/kubernetes/release/blob/2338077e3911ad2ede6473b2777ead38e9edf5b0/find_green_build#L32) is to be believed
* When in the release cycle should this be stabilized?
* Prior to cutting a build/release
* Need to determine how long we support version-specific test cases, e.g. etcd2 upgrade path, beta upgrades ~ what SIG owns upgrade lifecycles? (SIG Cluster Lifecycle?)
* API Policy
* Component upgrades
* Management of failing tests
* Need to raise this in community and get test-owner reps in the release meetings
* Upgrade test signal
* Which upgrade conditions do we expect to validate?
* Multi-master?
* etcd version?
* When in the release cycle should this be stabilized?
* Release Notes
* What format are they expected to be in?
* When in the release should this be complete?
* By the time feature freeze happens, we should have enough to create the PM-oriented “theme release notes”
* Need to enact the ‘marketing’ and ‘release notes’ roles
* A draft of the notes by code freeze will be required
* Call out features with no docs
* Call out features with no release notes
* Cherry picks are hard, and porting info across PRs is difficult
* Maybe this is not in the PR, and lives somewhere else
* Documentation
* When in the release should this be complete?
* Bugs
* **Action items summary from this meeting:**
* ~~Raise awareness (again) about release roles~~ (@ community and @ SIG-Release Google Group) ~ **Jaice & Caleb**
* **~~PWittrock to seek out Googlers for G-specific release roles~~** [ ~~branch manager~~ | patch release manager ]
* ~~Give attention to Community PR 305 and ratify on Friday~~ ~ **SIG Release team**
* ~~Schedule follow-up meeting for Friday at 2PM PT / 5PM ET / 9PM UTC~~ ~ **Caleb or Dan**
* Determine if/how an Alpha is possible ~ **SIG Release team**
* ~~Use Anago test list as the source of truth for release-blocking tests~~ ~ **Aaron** will provide this info
## 6 June 2017
Agenda - Recording
* Attending:
* Jaice Singer DuMars
* Anthony Yeh
* Ihor Dvoretskyi
* Maru Newby
* Caleb Miles
* Doug Claar
* Javier Perez
* David McMahon
* Andrew Chen
* Phil Wittrock
* Notes: JSD
* [ 0:01 ] What are we hoping to achieve from this meeting?
* How do we make long-term improvements to the release process?
* How do we empower teams to do more of the release tasking themselves?
* Different than the work cutting releases
* Iterating and improving on every release as a group
* Release team forms/disbands around the release so not a durable group
* Tools we need in order to improve the process, vs. release team uses current tool set
* [ 0:09 ] Updates
* SIG CLI was working on a page in the test grid, filtered for easy understanding
* [1.6 Retro Action Items](https://docs.google.com/document/d/1JjQW14R9FCaKceZV2hE9Wx41LIUoZST8gp8FF5EqMmk/edit)
* We need a measurable goal
* Do a mock release weekly to verify the process and testing [ Phil leading this ]
* What are the tools needed to make this happen?
* Start with a PR for discussing how to enact this work
* Release team retro [ Jaice ]
* ID bugs and issues we already know about [ ID targets for continuous improvement ]
* Schedule meeting

764
sig-release/meeting-notes-archive/2018.md Normal file
View File

@ -0,0 +1,764 @@
<table>
<tr>
<td>Date:
</td>
<td>Dec 18, 2018
</td>
</tr>
<tr>
<td>Recording
</td>
<td>https://youtu.be/WRJw27_QkiI
</td>
</tr>
<tr>
<td>Attending:
</td>
<td>
<ul>
<li> \
Tim Pepper
<li>Aaron Crickenberger
<li>Kendrick Coleman
<li>Josh Berkus
<li>Caleb Miles
<li>Aish Sundar
<li>Benjamin Elder
<li>Davanum Srinivas
<li>Stephen Augustus
</li>
</ul>
</td>
</tr>
</table>
* \
Part #2 of the 1.13 release retrospective:[ https://docs.google.com/document/d/1mKrJm3N4dC4rfOwa5WcvOptmjpteMcNOg1ZSoACKU1g/edit#](https://docs.google.com/document/d/1mKrJm3N4dC4rfOwa5WcvOptmjpteMcNOg1ZSoACKU1g/edit#)
* Part #1 was[ https://youtu.be/e5oHnmUOz3k?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ](https://youtu.be/e5oHnmUOz3k?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ)
<table>
<tr>
<td>
Date:
</td>
<td>Dec 4, 2018
</td>
</tr>
<tr>
<td>Recording
</td>
<td><a href="https://youtu.be/7gnQw8Jd2NA">https://youtu.be/7gnQw8Jd2NA</a>
</td>
</tr>
<tr>
<td>Attending:
</td>
<td>
<ul>
<li> \
Tim Pepper
<li>Aaron Crickenber (@spiffxp)
<li>Kendrick Coleman
<li>Hart Hoover
<li>Josh Berkus
<li>Claire Laurence
<li>Nicholas Lane
<li>Caleb Miles
</li>
</ul>
</td>
</tr>
</table>
* \
1.13 anything else to do?
* 1.13 retrospective:
* Thursday at community meeting.
* [1.13 Retro doc](https://docs.google.com/document/d/1mKrJm3N4dC4rfOwa5WcvOptmjpteMcNOg1ZSoACKU1g/edit#heading=h.tw06ll716grh) (and[ 1.12 retro doc](https://docs.google.com/document/d/1OgylAYqU0YoJz-PTd8uzyHtMcxYSewSq06AGeh1F-A8/edit#) for reference)
* Moderator? Don’t have Jaice confirmed yet.
* Jaice can do it, but probably should pass the baton so more people get experience doing this
* 1.13 Changelog, or what is a good changelog in general:
* [Major Themes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.13.md#major-themes) section: reads very high level and broad for some SIGs. Content is delegated to the SIGs, but the overarching doc then needs coherent editorial voice. The release team relnotes lead needs help (SIG Architecture) help on the “reduce” part following the “map”
* Should it refer to commercial offerings in the SIG ${cloud provider name} sections?
* Steering committee has two bullets in their charter:
* Decide how and when official releases of Kubernetes artifacts are made and what they include
* Declare a release, so that the committee can ensure quality/feature/other requirements are met. \
If it's steering who makes these choices (and associated support stance declarations?), some might feel they have insufficient voice, even though Steering is elected by all of us.
* Aaron will bring up question on changelog content in steering
* We as a group can discuss in the retro on Thursday
* Test flakes (spiffxp, jberkus):
* can we do some targeted work in December?
* Shifting issues from 1.13 milestone to master
* Umbrella: this is a massive amount of work, plus complex interdepencies and runtime context specific interactions increasing the flake likelihood
* Specific areas:
* Upgrade / Downgrade: needs critical mass of the right stakeholders to declare a better test architecture
* Event passing anti-pattern:[ https://github.com/kubernetes/kubernetes/issues/71646](https://github.com/kubernetes/kubernetes/issues/71646)
* 5k node Scale test
* Numretries: is this hiding flakes?
* Dashboard: community view into what is flaking, how much, feel the scope of problem. Partly in[ velodrome/bigquery](http://velodrome.k8s.io/dashboard/db/bigquery-metrics?orgId=1), also[ triage dashboard](https://storage.googleapis.com/k8s-gubernator/triage/index.html), and daily pre-submits.
* Release blocking criteria: need to improve flakes to make the testgrid board truly reliably release blocking, starting with measurement.
* Flakiest job, flakiest test are two separate things.
* Josh & Aaron want a dashboard of flakiness to assess where to prioritize fixing versus replacing
* Release-master-informing dashboard refining: 5k node? Serial jobs?
* [https://github.com/kubernetes/sig-release/issues/347](https://github.com/kubernetes/sig-release/issues/347)
* Also[ https://github.com/kubernetes/sig-release/issues/405](https://github.com/kubernetes/sig-release/issues/405) Why “extra”?
* Scale testing: things aren’t progressed far along enough to CNCF to know what tests will be there versus dedicated hardware. Needs dollars and staffers. WG K8s Infra is working to move this along, but is at the level of determining things like access controls, moving tooling like gcbmgr, etc. Not quite at the level of “who’s got a spare 5k node” on which to run tests, but if those are laying around, serial runs on such a cluster could be plumbed in. See #k8s-infra-team
* Release teams’ shadow selection process (justaugustus, jberkus, tpepper)
* Status check: drawing up a lightweight process and sample questionnaire. Finalize to ungate 1.14 shadow selection.
* Josh: we should go ahead. Remaining one incompleteness is: too hard to set up forms per role. Could do a generic questionnaire form, if the role handbooks all have a requirements section. ToDo during 1.14: add requirements to the role handbooks. In the meantime, 1.14’s leads have an informal conversation about requirements with prospective shadows. Send out the survey.
* Aaron: a good goal is to have a list of easily/readily delegatable tasks
* SIG charter cleanups (chairs ongoing TODO):[ https://github.com/kubernetes/sig-release/issues/378](https://github.com/kubernetes/sig-release/issues/378)
* Formalization of alpha/beta/stable graduations:
* Move enhancements tracking to PR based flow instead of issues
* KEP-like?
* SIG Architecture oversight sign off? Something that’s beyond the SIG(s) in question on a SIG(s) focused KEP. Also need to not be a bottleneck, or inject very late surprises.
* Release lead should have a simple checklist set of criteria including tests, coverage, stability, key contact individuals, reviewers/approvers. Too much for the release lead (or enhancements lead) to be able to assess from a KEP that it is genuinely on track.
* Is 1.14 the release in which to require tracked enhancements have a KEP? No, not yet. Need to finalized that more broadly across the org/project, establish criteria. Implement for 1.15.
<table>
<tr>
<td>
Date:
</td>
<td>Nov 20, 2018
</td>
</tr>
<tr>
<td>Recording
</td>
<td><a href="https://youtu.be/jmJOczWHFik">https://youtu.be/jmJOczWHFik</a>
</td>
</tr>
<tr>
<td>Attending:
</td>
<td>
<ul>
<li> \
Tim Pepper
<li>Aaron Crickenberger
<li>Arnaud Meukam
<li>Hannes Hoerl
<li>Hart Hoover
<li>Kendrick Coleman
<li>Cole Wagner
<li>Niko Penteridis
<li>Aish Sundar
<li>Nicholas Lane
</li>
</ul>
</td>
</tr>
</table>
* (justaugustus) Updates to SIG leadership
* [https://github.com/kubernetes/community/pull/2778](https://github.com/kubernetes/community/pull/2778)
* (justaugustus) Review SIG Release charter
* [https://github.com/kubernetes/sig-release/pull/348](https://github.com/kubernetes/sig-release/pull/348)
* [https://github.com/kubernetes/community/pull/2919](https://github.com/kubernetes/community/pull/2919)
* (justaugustus) Subproject / WG formation updates
* RT (release team)
* Release Engineering
* PST (project security team)
* LTS (long term support)
* (justaugustus) Enforce milestone for merge
* [https://github.com/kubernetes/sig-release/issues/321](https://github.com/kubernetes/sig-release/issues/321) (help wanted)
* Discussion noted in the issue
* Two sides:
* Is this for a gate of what might go in?
* Is this for post-tracking of what went in?
* (justaugustus) What qualifies for a milestone?
* [https://github.com/kubernetes/sig-release/issues/320](https://github.com/kubernetes/sig-release/issues/320) (help wanted)
* We have a loose process, which covers test cases, test health, docs.
* Declaration of “critical-urgent” during code freeze is sort of intentionally meant to be a discussion between the release team and stakeholder SIGs.
* Feature branches with demonstrable test can help.
* Green CI signal is one criteria.
* Do we have a problem that needs fixing? Is code missing a milestone due to vague acceptance criteria? We’re not seeing it as release leads this year.
* 1.10, 1.11 Josh notes there’s been “a team” that would abuse code freeze. The team specifically varied each time, so not a clear pattern. One was a SIG/developers who weren’t paying attention and just straight missed code freeze.
* 1.12 Tim each SIG was responsible and was on track, and then admitting they were behind, and then all who were behind did make a no-go call
* 1.13 Aish similar to 1.12. Most of friction now at code freeze is bug fixes so the question is how critical of a bug fix is it. Leads are erroring on the side of caution.
* (tpepper) What is supported? PR clarifying supported component version skews and upgrade:[ https://github.com/kubernetes/website/pull/11060](https://github.com/kubernetes/website/pull/11060)
* (nikopen) Decision making, critical thinking, “rule” malleability and definition of “urgency”
* How strictly are the role handbooks meant to be followed? Does following handbooks in a word-by-word manner create issues in more nuanced scenarios?
* Do labels always have a strict definition? Example: the priority label, and its usage across separate cycle stages (precode slush, code freeze etc)
* Does the enforcement of an ‘important-soon’ label on code slush offer any benefit? The priority filtering already occurs in code freeze where the merge conditions tighten.
* How tight are merge conditions in code slush and code freeze? How strict are rules meant to be followed? An example[ being this](https://github.com/kubernetes/kubernetes/pull/71208): fix to a CI flake. Details were not given but intent was clear.
* To avoid being overly strict in the future, can it be written down that handbooks are meant to be guidelines in order to solve actual problems (i.e. getting new code in a new release) and to not lose track of the actual goals over guidelines.
* Iterating on role handbooks == GOOD!
* Do it before and after and during release cycle
* Good to capture some specific examples: in release 1.x we worked through issue foo, weighed x/y/z evidence from SIG’s A/BC, decided such and such based on that.
* “Critical” and “Urgent” are clear and strong words. Same for “Important” and “Soon”, especially relevant to the other two. The “Kind” labels also are meant to be clarifying.
* It does remain subjective often and require conversation.
* Human conversation 1:1 continues to be our most productive means of getting something done urgently from a responsible SIG.
*
* (justaugutus, jberkus and aishs) Discuss 1.14 RT nominations
* Fill in lead roles[ https://github.com/kubernetes/sig-release/issues/372](https://github.com/kubernetes/sig-release/issues/372)
* Need especially a candidate
* Discuss shadow selection proposal -[ https://github.com/kubernetes/sig-release/issues/368](https://github.com/kubernetes/sig-release/issues/368)
* This isn’t about having a job interview, rather a conversation with prospective mentees/shadows..have they read the role handbook, do they have questions, is the time commitment something they can afford, are they ready and willing to learn & contribute. This is necessary to insure a successful mentor/mentee relationship.
* If we go this route SIG Release wouldn’t be involved in the shadow selection, rather just role lead and the release team lead
* Need to make sure time commitments across the release cycle are clearly in each role handbook
* Discuss roles and processes for Patch release team -[ https://github.com/kubernetes/sig-release/issues/369](https://github.com/kubernetes/sig-release/issues/369)
* Backlog: (tpepper and maybe jberkus) Upgrade test improvement plan:
* Upgrade issues and test case ambiguity causing continual release friction
* Forward plan is roughly to drop kube up and cluster/*, move to kubeadm only, assess coverage gaps, improve test coverage, insure skew testing works, version test cases.
* But this spans SIGs Release, Cluster Lifecycle, and Testing and that means it lacks a clear owner and staffing.
* Does this merit a WG or subproject so somebody’s name is owning creating a plan and coordinating execution of the plan? Is it a first task for the proposed (above) Release Engineering subproject/WG?
* What about downgrade?
* See also “what is supported” PR:[ https://github.com/kubernetes/website/pull/11060](https://github.com/kubernetes/website/pull/11060)
<table>
<tr>
<td>
Date:
</td>
<td>Nov. 6, 2018 (Cancelled. Too many people with conflicts
<p>
Oct 23, 2018 (Cancelled. No agenda and meeting invite has gone missing :/ )
</td>
</tr>
<tr>
<td>Attending:
</td>
<td>N/A
</td>
</tr>
</table>
<table>
<tr>
<td>Date:
</td>
<td>Oct 9, 2018
</td>
</tr>
<tr>
<td>Attending:
</td>
<td>
<ul>
<li> \
Jaice Singer DuMars
<li>Dhawal Yogesh Bhanushali
<li>Kendrick Coleman
<li>Aaron Crickenberger
<li>Aish Sundar
<li>Benjamin Elder
<li>Caleb Miles
<li>Arnaud Meukam
</li>
</ul>
</td>
</tr>
</table>
* \
**POSTPONE**: 2nd portion of 1.12 release retrospective
* Charter draft:[ https://github.com/kubernetes/community/pull/2778](https://github.com/kubernetes/community/pull/2778)
* Needs issues addressed ~ See PR, perhaps move to collab doc for edits
* Subprojects
* release team
* Owning the document of the process
* OWNERS = release process
* Each team has latitude to run the release
* SIG Release as owners of the handbooks (e.g. process),
* release engineering and infrastructure/automation improvements
*
* licensing/compliance
*
* Security / Threat Model / Provenance
*
* LTS (or[ WG](https://docs.google.com/document/d/1PWhUhm_a27BoWCGKZ5Bg6bV-DW-N06gIQIbrpwoscck/edit#heading=h.46dch1el9d8c)?):
* [https://github.com/kubernetes/community/issues/2720](https://github.com/kubernetes/community/issues/2720)
* [Doc](https://docs.google.com/document/d/1PWhUhm_a27BoWCGKZ5Bg6bV-DW-N06gIQIbrpwoscck/edit#heading=h.46dch1el9d8c) /[ ppt](https://docs.google.com/presentation/d/1-Z-mUNIs3mUi7AdP1KwoAVNviwKrCoo3lxMb5wzCWbk/edit#slide=id.g338ac0a8b6_0_36)
* Proceed with discovery on this
* Release cadence of patch releases -[ https://github.com/kubernetes/sig-release/tree/master/release-team/role-handbooks/patch-release-manager#release-timing](https://github.com/kubernetes/sig-release/tree/master/release-team/role-handbooks/patch-release-manager#release-timing)
* Predictability would be helpful here
* The patch release team….?
* Feature graduation and release guidance for out-of-tree Cloud Provider projects
* Skip to stable?
* SIG Cloud Provider / Architecture owns this
* Release-blocking job criteria[ PROPOSAL](https://docs.google.com/document/d/1kCDdmlpTnHPQt5z8JzODdFCc3T2D4MKR53twsDZu20c/edit)
*
<table>
<tr>
<td>
Date:
</td>
<td>Sept 25, 2018
</td>
</tr>
<tr>
<td>Attending:
</td>
<td>
<ul>
<li> \
Arnaud Meukam
<li>Tim Pepper
<li>Jaice Singer DuMars
<li>Kevin Kelani
<li>Aish Sundar
<li>Jim Angel
<li>Kendrick Coleman
<li>Lubomir I. Ivanov
<li>Silvia T. Sandy-Martinez
<li>Chuck Ha
<li>Josh Berkus
<li>Jorge Castro
<li>Dhawal Yogesh Bhanushali
<li>Stephen Augustus
<li>Sebastien Vas
</li>
</ul>
</td>
</tr>
</table>
* RPM(s) and DEB(s) for Release Candidates - dims
* Next meeting
* 1.13 Updates - AishSundar
* [1.13 timeline ](https://github.com/kubernetes/sig-release/pull/294)
* 1.12 is wrapping up
* 1.13 should start 10/1 - fully staffed release team
* Will adjust the timeline as needed
* Minding feature fallthrough from 1.12 because of a short timeline
* 1.13 team - you should have emails/invites
*
* SIG sessions for Seattle, Shanghai
* Shanghai
* [Intro](https://kccncchina2018english.sched.com/event/FuLM/intro-sig-release-tim-pepper-vmware): Tim Pepper - intro and how to get involved
* [Deep-dive](https://kccncchina2018english.sched.com/event/FuLi/deep-dive-sig-release-tim-pepper-vmware): Tim Pepper - open discussion of China ecosystem vendors’ needs
* Seattle
* [Intro](https://kccna18.sched.com/event/Grbb/intro-release-sig-tim-pepper-vmware-aishwarya-sundar-google) - Tim Pepper & Aish Sundar - intro, how to get involved, panel
* [Deep-dive](https://kccna18.sched.com/event/GrdX/deep-dive-release-sig-josh-berkus-red-hat-chuck-ha-heptio) - Chuck Ha on build tools.
* SIG Leadership
* (Stephen / Tim) Revisit Charter
* Formally define subprojects
* Release Team
* Release Engineering
* Patch Release Team - rotating slot on RT
* Meta KEP to define tooling
* Licensing & Compliance
* Product Security Team
* Time to rotate leads?
<table>
<tr>
<td>
Date:
</td>
<td>Sept 11, 2018
</td>
</tr>
<tr>
<td>Attending:
</td>
<td>
<ul>
<li> \
Aaron Crickenberger (@spiffxp)
<li>Aish Sundar
<li>Tim Fogarty
<li>Justin Santa Barbara
<li>Lubomir I. Ivanov
<li>Arnaud Meukam
<li>Morten
<li>Mike Arpaia
<li>Caleb Miles
<li>Kendrick Coleman
</li>
</ul>
</td>
</tr>
</table>
* Discuss 1.13 release team nominations ![ https://github.com/kubernetes/sig-release/issues/280#issuecomment-420059544](https://github.com/kubernetes/sig-release/issues/280#issuecomment-420059544)
* Possibly cap # of shadows to 4 per role. Specifically for Branch manager role, guidance is to not have >2 shadows.
* [https://github.com/kubernetes/test-infra/issues/9336](https://github.com/kubernetes/test-infra/issues/9336) - turning down misc-mungers and cherrypick-queue instances of mungegithub [spiffxp]
* Have reached out to existing patch release managers to verify I’ve surveyed their usage of cherry pick related labels and merging
* We need someone to adopt improving the cherrypick process, IIRC @nikhita and @guineversaenger have expressed interest
* [https://github.com/kubernetes/test-infra/pull/9342](https://github.com/kubernetes/test-infra/pull/9342) - moving all kubernetes repos over to tide [spiffxp]
<table>
<tr>
<td>
Date:
</td>
<td>Aug 28, 2018
</td>
</tr>
<tr>
<td>Attending:
</td>
<td>
<ul>
<li> \
name1
</li>
</ul>
</td>
</tr>
</table>
* Adding sig labels to PRs automatically based on OWNERS files is a thing, but too many OWNERS files don’t have “labels:” section. Could be good first issue for somebody looking to learn codebase layout and ownership:[ https://github.com/kubernetes/community/issues/1808#issuecomment-410309860](https://github.com/kubernetes/community/issues/1808#issuecomment-410309860)
* [TimP] Build-and-Publish-Infra-and-Automation:
* Is this a sub-part of test-infra?
* How do we work to pull this out more into community managed workflows and code maintenance? Eg:[ https://github.com/kubernetes/release/issues/591](https://github.com/kubernetes/release/issues/591) backs onto something building from a master branch instead of a release specific branch, but most of us don’t understand what/where this is or how to change it.
* Could we get to a workflow of build-validate-publish-validate, where we know all the expected artifacts, and have scripts to validate they’re created correctly, and were published correctly?
*
<table>
<tr>
<td>
Date:
</td>
<td>Aug 14, 2018
</td>
</tr>
<tr>
<td>Attending:
</td>
<td>
<ul>
<li> \
No meeting
</li>
</ul>
</td>
</tr>
</table>
<table>
<tr>
<td>Date:
</td>
<td>July 31, 2018
</td>
</tr>
<tr>
<td>Attending:
</td>
<td>
<ul>
<li> \
Jaice Singer DuMars
<li>Kendrick Coleman (1.12 Features Shadow)
<li>Stephen Augustus
<li>Aaron Crickenberger
</li>
</ul>
</td>
</tr>
</table>
* SIG Release Charter - Needs to be revamped with new template
* Link to[ template](https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-charter-template.md)
* Volunteers needed:
* Stephen Augustus
* Tim Pepper
* Jaice Singer DuMars
* Aish Sundar
* Using discuss.kubernetes.io for release announcements - Jorge Castro
* Currently working on autoingesting k8s releases and changelogs, then autogenerating a post on discuss.k8s.io
* We can then post to Slack/twitter automatically
* Submission is currently human gated while we sort out the exact workflow and test usage cases
* We could remove the burden of handing off -announce list access to each new release lead
* Contribex (jorge) owes you a fully documented process
* Features process reboots ~ PTAL
* Why do we need to change this?
* Current process is too manual and error-prone
* There is no feature planning process framework
* Release artifacts outside of GitHub are not traceable or transparent
* KEPs do not tie cleanly to work delivered
* Jaice’s[ proposal](https://docs.google.com/document/d/113gnr3tKXv79J0IYHyg6VbQwLfb-sCYGphW4D9dLZ_E/edit#heading=h.wzakwvll8dsp)
* Stephen’s[ proposal](https://docs.google.com/document/d/169x1nuvBTOvZyU8tx7-aZycsF6HGzluqm41rCXd4Rl4/edit#heading=h.ajp15jfaoupa)
* Revisiting milestone-munger - spiffxp
* Yes, I’m proposing we stop using it entirely, I can’t tell how we’re measuring its success
* Or at least identify what parts it’s doing that are actually useful vs. noise
* [https://github.com/kubernetes/sig-release/issues/243](https://github.com/kubernetes/sig-release/issues/243)
* EOL policy for older release-1.y jobs - spiffxp
* [https://github.com/kubernetes/sig-release/issues/244](https://github.com/kubernetes/sig-release/issues/244)
* Docs and policy for Milestone-Maintainers membership:
* [https://github.com/kubernetes/sig-release/pull/239](https://github.com/kubernetes/sig-release/pull/239)
## Next meeting - TBD
Potential topics (moved here from older[ SIG-Release minutes doc](https://docs.google.com/document/d/1Q6Ux-vsiRuiXhXSkVqGr9FUZifqVGRdCWkzVI1UT4l0))
* SIG-Release intro and deep dives at KubeCon China and North America
* Release process improvements:
* artifact provenance & signing
* release process threat model
* Ability for non-Google employees to be release branch maintainers
* More documentation details on what metadata feeds what machinery to generate what artifacts
* add test cases on artifact creation/publication so SIG-Cluster-Lifecycle's not pointing out that some part of the artifacts didn't build/publish correctly
* LTS releases
* Promotion of e2e test to conformance: when should this happen for features that are (or should be) going stable in the current release? Don’t want it late, because it could cause signal instability or other late surprises. Don’t want it too early in case the feature slips, but in that case could relegate from conformance back to e2e?
---
<table>
<tr>
<td>Date:
</td>
<td>June 5, 2018
</td>
</tr>
<tr>
<td>Attending:
</td>
<td>
<ul>
<li> \
Jaice Singer DuMars
<li>Stephen Augustus
<li>Paris Walters
<li>Zach Arnold
<li>Tim Pepper
<li>Kendrick Coleman
<li>Benjamin Elder
<li>Aish Sundar
</li>
</ul>
</td>
</tr>
</table>
**AGENDA**:
* SIG Release Charter - Need volunteers
* Need to create a draft and get it ratified
* Volunteers: Stephen Augustus, Tim Pepper
* Open / hold PR in k/community for RFC
* Move Release Team to a subproject
* Overlap with SIG-PM and the new features[ planning](https://docs.google.com/document/d/1qi4LKV3W9B5JJ5JLjmAY33jESYAqWMWFyO5bWoYEBDo/edit)/[tracking](https://docs.google.com/document/d/113gnr3tKXv79J0IYHyg6VbQwLfb-sCYGphW4D9dLZ_E/edit#heading=h.wzakwvll8dsp) process
* Need everything in GH somehow
* SIGs SHOULD be planning release work more than one release ahead
* KEPs are great, but not fully implemented yet
* SIG PM Charter draft PR:[ https://github.com/kubernetes/community/pull/2068](https://github.com/kubernetes/community/pull/2068)
* Release artifact signing and validation
* Tim Pepper was going to look at this?
* Threat model:
* Not an existing model, but would like one
* Create and collaborate on a draft
* How do signed artifacts support cluster operator requirements and use cases?
* How do we connect with Google peeps working on this? At KubeCon EU Caleb mentioned work underway to remove the requirement that release branch managers be Googlers. Whatever automation improvements are underway there tie into the overall release threat model and any signing story.
* Notary /[ TUF](https://theupdateframework.github.io/) could be very helpful?
*
* Scalability pre-submits
* Stabilized from add a month ago
* Every PR is being scale tested
* Can these be made blocking?
* 500 node kubemark would become the slowest test at 1:20:00
* Catch ~60% of regressions ahead of time
*
* Release cadence discussion
* 3x? 20x? LTS?
* 3 + 2 release idea?
* Need to figure out how to gate release content
*
* What release policies are missing?
* Documentation as a blocker
* To whom is this controversial?
* Alpha/Beta features should not be an “out” for docs
* if in_features == true ; docs_required
* label for this?
* Reverts (in greater detail)
* SIG vs. Release Team
* Unmaintained/able vs. policy-violating
*
* Revisit[ requirements](https://github.com/kubernetes/sig-release/blob/master/release-process-documentation/release-team-guides/release-lead.md#skills-and-experience-required) for the Release Lead
*
* Better define requirements for other Release Team roles
* [CI Signal lead role / tasks outlined a bit here](https://docs.google.com/document/d/1uDVrlzh9gZZukz-GYHWSyOnFW_2lplZ4JgR3D4tV4EA/edit)
* How are leads actually elected/selected?
* Nomination -> ratified by the subproject
* Tim Pepper!
* ========= Continue Next Meeting ===========
* Big features (k/features) vs others (k/k)
* Is there / should there be a “maximum term” for incumbents?
* Do leads need to be from a different company each time?
* How do we replace a release lead (or other position) if:
* They leave/quit/expire
* The SIG receives complaints, or the person is not performing the required duties
* Conformance test discussion / coverage as a blocker for features going to Stable each release
* PR conformance related tasks into a release role
* Identify few areas / features to increase conformance coverage per release [Aish]
---
Template:
<table>
<tr>
<td>Date:
</td>
<td>
</td>
</tr>
<tr>
<td>Attending:
</td>
<td>
<ul>
<li>
</li>
</ul>
</td>
</tr>
</table>
**AGENDA**:
* Item 1
---
**RECOVERED NOTES**
---
## 27 February 2018
Agenda
## 16 January 2018
Agenda
* @jdumars working on some process improvements
* sending out a weekly update to kubernetes-dev
* documenting all release roles
* would like to see more investment in strategic improvements beyond the release team
* Master upgrades on GCE/GKE need attention
* @calebamiles working to onboard as 1.10 branch manager
* Possibly looking for a replacement SIG colead for @pwittrock
* No objections from participants to replace @pwittrock with @jdumars
* Need to find earlier time to accommodate europe
* Possibly move to asynchronous meeting to replace biweekly Zoom meeting

1796
sig-release/meeting-notes-archive/2019.md Normal file
View File

File diff suppressed because it is too large Load Diff

1822
sig-release/meeting-notes-archive/2020.md Normal file
View File

File diff suppressed because it is too large Load Diff

1759
sig-release/meeting-notes-archive/2021.md Normal file
View File

File diff suppressed because it is too large Load Diff

2199
sig-release/meeting-notes-archive/2022.md Normal file
View File

File diff suppressed because it is too large Load Diff