

## Dec 15, 2020 (recording)

**Host:** Stephen Augustus

**Note Taker**: Carlos

**Attendees:**



* Marky Jackson
* Rob Kielty
* Rey Lejano
* Jeremy Rickard
* Max Körbächer
* Carlos Panato
* Marko Mudrinić
* Nabarun Pal
* Daniel Mangum
* Adolfo García Veytia
* Kirsten Schumy
* Lauri Apple
* Joseph Sandoval

**Recurring Topics [timebox to N min]:**



* (if you have any… here are some suggestions)
* Welcome any new members or attendees
* Subproject updates
    * Licensing ([https://github.com/orgs/kubernetes/projects/31](https://github.com/orgs/kubernetes/projects/31))
    * Release Engineering ([https://github.com/orgs/kubernetes/projects/30](https://github.com/orgs/kubernetes/projects/30))
    * Release Team ([https://github.com/orgs/kubernetes/projects/29](https://github.com/orgs/kubernetes/projects/29))
    * CI Signal ([https://github.com/orgs/kubernetes/projects/11](https://github.com/orgs/kubernetes/projects/11))
        * Testgrid dashboard review:[ https://testgrid.k8s.io/sig-release](https://testgrid.k8s.io/sig-release) 
* New[ kubernetes/kubernetes issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Frelease) review
* Project board review:[ https://github.com/orgs/kubernetes/projects/23](https://github.com/orgs/kubernetes/projects/23)
* Incoming issue and PR triage
    * [org:kubernetes SIG Release issue needs-triage](https://github.com/search?q=org%3Akubernetes+is%3Aopen+is%3Aissue+label%3Asig%2Frelease+label%3Aneeds-triage)
    * [org:kubernetes SIG Release PR needs-triage](https://github.com/search?q=org%3Akubernetes+is%3Aopen+is%3Apr+label%3Asig%2Frelease+label%3Aneeds-triage)

**Open Discussion [timebox to N min]:**



* [Jeremy] Can we make “freeze” dates more enforceable with merge blocking?
    * 1.20 we had several things merge after freeze dates w/o coordination w/ release team
    * Some thoughts:[ https://hackmd.io/2zJll3I2SLq8pdVNEAX0rQ](https://hackmd.io/2zJll3I2SLq8pdVNEAX0rQ)
    * [Stephen] Merge blocking plugin would be useful here, but:
        * currently too restrictive, applies to entire repo
        * based currently on an issue, if issue closes blockade drops
        * Would need to be extended to be team based, selective for branch (main only?)
        * Would need a break-glass escape like /override
        * Dovetails with what wg-reliability has proposed about blocking for quality
        * AI: Jeremy to investigate / research plugin more, craft a proposal and discuss with wg-reliability + sig-release + sig-arch 
* [Max] Observing the latest discussion e.g. about “critical” or at least market shaking changes (dockershim deprecation) as well as having long run topic within the SIG release; I got the idea if it wouldn’t make sense to extend the Emeritus Adviser to a Emeritus Adviser Team, where each team member is assigned for 1y to Comms/Enhancements/Triage and so on. This way we would have per team someone who can take on long running topics, and really ensure that the teams are improving. How it help with the latest topic of Docker? I personally believe it would make sense if Enhancements & Comms identify such topics, leverage them to the release team lead & SIG lead, and address this changes right in time (with first release note) but before the release blog posts)
    * [Stephen] Issue opened on k/community:[ https://github.com/kubernetes/community/issues/5344](https://github.com/kubernetes/community/issues/5344)
    * [Stephen] Having a release note with kind deprecation merged in the repo is too late to notify.
    * [Stephen] (Ideas) Deprecation Page that lives outside the release notes documentation
        * [Lauri] Idea to have a visual Path to Release with all steps and things related.
            * Onboarding for RT members
            * Onboarding for general new contributors
            * Re-onboarding of veterans who might assume what the processes are now but don’t have new info and context
            * Should we create an issue to track this and make a mini project [jeremy]?
* [Stephen] Release Cadence update
    * [Adolfo] Aren’t end users most impacted?
        * Yes, we should get feedback out as early, often and loudly as possible
        * Only so far we can go

        receipts process: aggregate a manifest of the release


        [jeremy] who can own the idea of a visual roadmap to release: anyone interested can take it

* AI: Jeremy/Nabarun to chat about notional schedules and provide 3 vs 4 schedule for the year
    * (should we notionally plan out the entire year for the purpose of the informational summary that will go out?)
* Delay release maybe a few weeks into Jan and allow decisions to be made and not make date changes that make people upset.
* Can shift a bit after if needed to accommodate 4 releases
* Stephen to aggregate all thoughts around 3 vs 4 releases per year and send to k-dev
* [Nabarun] 1.21 Updates
    * In Progress
        * Scaffolding the release-1.21 directory
        * Decision on schedule
            * Pushing Enhancements collection to Week 2
                * Enhancements Team has only one staff until shadows are selected
                * Risk: Less time for Enhancements collection if rest of schedule is not changed
        * 1.21 Shadow survey should be going out by the end of the week.
* [Lauri] Meetings in 2021
    * Walking the project board
    * Sidebar conversations on topics
    * Stephen: we need to be more precise, skip recurring topics. Not putting the right amount of focus on important stuff like walking the board.
    * We should strive to unblock things, difficult to do as boards are very large. Some effort has been done to trim them. 
    * More effort will go into walking the boards: SIG Release mtg the bigger things. Giving status updates during releng meeting
    * Make sure meetings are more focused by requiring topics to be sent to the mailing list first.
* Meetings for December are canceled we will return on Jan/2021


## Dec 1, 2020 (recording)

**Host:** TBD

**Note Taker**: Marko Mudrinić

**Attendees:**



* Marko Mudrinić
* Nabarun Pal
* Daniel Mangum
* Gianluca Arbezzano
* Jeremy Rickard
* Joyce Kung
* Lauri Apple
* Max Körbächer
* Carlos Panato
* Adolfo García Veytia
* Rob Kielty
* Sascha Grunert
* Rin Oliver

**Recurring Topics [timebox to N min]:**



* (if you have any… here are some suggestions)
* Welcome any new members or attendees
* Subproject updates
    * Licensing ([https://github.com/orgs/kubernetes/projects/31](https://github.com/orgs/kubernetes/projects/31))
    * Release Engineering ([https://github.com/orgs/kubernetes/projects/30](https://github.com/orgs/kubernetes/projects/30))
    * Release Team ([https://github.com/orgs/kubernetes/projects/29](https://github.com/orgs/kubernetes/projects/29))
    * CI Signal ([https://github.com/orgs/kubernetes/projects/11](https://github.com/orgs/kubernetes/projects/11))
        * Testgrid dashboard review:[ https://testgrid.k8s.io/sig-release](https://testgrid.k8s.io/sig-release) 
* New[ kubernetes/kubernetes issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Frelease) review
* Project board review:[ https://github.com/orgs/kubernetes/projects/23](https://github.com/orgs/kubernetes/projects/23)
* Incoming issue and PR triage
    * [org:kubernetes SIG Release issue needs-triage](https://github.com/search?q=org%3Akubernetes+is%3Aopen+is%3Aissue+label%3Asig%2Frelease+label%3Aneeds-triage)
    * [org:kubernetes SIG Release PR needs-triage](https://github.com/search?q=org%3Akubernetes+is%3Aopen+is%3Apr+label%3Asig%2Frelease+label%3Aneeds-triage)

**Open Discussion [timebox to N min]:**



* **New meeting times?**
    * We have new contributors, should we consider new meeting times that would work better for everyone?
    * [Jeremy] Earlier would be hard for the west coast, maybe 30 minutes earlier.
    * [Marko] Later could be harder for folks in Europe.
    * People are generally okay with the current meeting time and day.
* **2021 Wishlist**
    * There is still no doc for this, but if anyone has any wish or have an idea of something that should be on our roadmap for 2021, leave it in the notes and we will turn it into something more concrete.
* **[Jeremy] 1.20/1.21 RT updates**
    * We’re wrapping up 1.20, the release is scheduled for next Tuesday.
    * SIG-Scalability has no issues so far with tests.
    * Nabarun is nominated as a Release Lead for 1.21.
    * Lead Nomination issue
        * [https://github.com/kubernetes/sig-release/issues/1363](https://github.com/kubernetes/sig-release/issues/1363)
    * Joyce will be CI Signal lead for 1.21.
    * [Stephen] Did we select lead shadows?
        * People are reaching out to Nabarun. Nabarun will decide probably next week.
    * [Stephen] Congrats to everyone on the release team for the great job!
    * [Stephen] Branch management activities during 1.20
        * Generating release branch jobs is in progress - there are some bugs with config rotater and forker that Stephen and Dan are working on.
        * We hope that those bugs will be solved soon. We will provide an updated once jobs/dashboards are ready.
    * What about release cadence for the next year?
        * [Stephen] A lot of feedback since the keynote, but still not ready to make the decision now.
        * **AI: **Leads to come together to go through the feedback. Stephen to start aggregating the feedback and ping the lists again (k-dev, CNCF TLs and SIG-Contributor Strategy) to get feedback from the wider community.
        * Seems like 3 is not a bad idea. 3 is easiest and next lowest, but we need to make sure about API graduation, and tests.
* **[Dan/Sascha] Arch support updates**
    * [https://github.com/kubernetes/sig-release/issues/1337](https://github.com/kubernetes/sig-release/issues/1337)
    * Support Tiers:[ https://github.com/kubernetes/sig-release/pull/1360](https://github.com/kubernetes/sig-release/pull/1360)
    * Artifact docs cleanup:
        * [https://github.com/kubernetes/sig-release/pull/1359](https://github.com/kubernetes/sig-release/pull/1359)
        * [https://github.com/kubernetes/sig-release/pull/1358](https://github.com/kubernetes/sig-release/pull/1358)
        * [https://github.com/kubernetes/sig-release/pull/1357](https://github.com/kubernetes/sig-release/pull/1357)
    * Next steps: building some tooling around tests.
    * This work might intersect with work Stephen is working on artifacts, might collaborate on this.
    * PR reviews would be appreciated.
    * BOM (Bill of Materials) can be put as a roadmap item for the next year.
* **[Sascha] krel updates**
    * krel can now be considered as feature complete
    * krel stage/release
        * We have used it today and it works. There are some follows-up on announcement generation that are in-flight.
        * We had a walkthrough yesterday, the recording will be available: \
[https://zoom.us/rec/share/bZ-tccQ--G_a20fw3n-tYDQ4VfNzR-oSlKjcd92Kmmp6YLBStRxxmYtKDYLIBK57.0ETFZZ4nIHjaPThN](https://zoom.us/rec/share/bZ-tccQ--G_a20fw3n-tYDQ4VfNzR-oSlKjcd92Kmmp6YLBStRxxmYtKDYLIBK57.0ETFZZ4nIHjaPThN)
    * We are not completely done. Initially, we mimicked the anago behavior, now we can optimize.
        * Improvements around branches/tags and changelog generation.
        * We can do image promotion directly from the GCB.
        * JSON Release Notes/Changelog.
        * [Lauri] What are metrics for what to go with first?
            * We don’t have metrics currently, but we can create them.
            * [Stephen] Dig into individual packages and see what we can improve. Prioritize the feature requests.
            * [Stephen] We should make clear what’s happening inside Krel. We can create a mindmap of what’s happening and boundaries, for example what happens on a local laptop, what happens on Google Cloud. That would allow more people to look into krel.
            * Sascha, Carlos, Adolfo to do a session with Lauri about creating the mindmap.
            * [Stephen] People are startings holidays soon, so if there’s anything that should be done this year, this is a good time to reach out. You can also DM us if you’d like a private discussion.
            * [Stephen] We got a lot of feedback from the Release Managers check-in.
    * Updated k/release README:[ https://github.com/kubernetes/release/blob/master/README.md](https://github.com/kubernetes/release/blob/master/README.md) ([https://github.com/kubernetes/release/pull/1803](https://github.com/kubernetes/release/pull/1803))
* **[Stephen] Artifact management updates**
    * **[https://github.com/kubernetes-sigs/k8s-container-image-promoter/releases/tag/v3.0.0](https://github.com/kubernetes-sigs/k8s-container-image-promoter/releases/tag/v3.0.0)**
    * **k/artifacts:[ https://github.com/kubernetes/org/issues/2342](https://github.com/kubernetes/org/issues/2342)**
    * **CIP repo improvements:[ https://github.com/kubernetes-sigs/k8s-container-image-promoter/issues/266](https://github.com/kubernetes-sigs/k8s-container-image-promoter/issues/266)**
    * Bunch of different points where we interact with the community
        * push-build script - when we push a build, we push an API reference/version marker which are available in the bucket and that can be used by the community
        * dl.k8s.io - reference point to gs://kubernetes-release/release bucket
        * Anything that happens in release process primarily happens on Google Cloud
        * Stephen plans to work on manifest generation and files promotion
    * Some tools are specific (such as krel that works only with Kubernetes), some are generalized (such as release-notes). 
    * General purposes store interface - for example, what if we want gc2gcs to work with S3 or some other interfaces? The interface should help if someone wants to implement something like that.
        * For example, this would help if GCR goes away in favor of Google Artifacts Registry.
    * Artifacts repo will be in the Kubernetes organization and controlled by Release Engineering. Transition to having access to administer artifacts on the global scope.
    * Stephen hopes to build on the deb/rpm story this year.
    * [Rob] Suggestion based on CI - Spyglass has Artifacts links, but it only kinda points to Artifacts, doesn’t point to any build artifacts. We should build formality/language about what are artifacts and build artifacts.
        * [Stephen] Balance between the test process (happening in SIG-Testing). Jobs must be configured to dump into the bucket. Jobs using podutilites have this configured by default.
        * Those artifacts would be local to build node, instead of global in the bucket.
        * kubetest2 work in progress ([https://github.com/kubernetes-sigs/kubetest2](https://github.com/kubernetes-sigs/kubetest2))
    * [Jim] Is the release page in scope of this work?
        * Stephen would call it in scope.
        * We have an idea of the images we are promoting, but we don’t have idea about files. BOM work is relevant to this. JSON with information about what’s consumable.
* **[Stephen] WG Reliability proposal on blocking contributions:[ https://groups.google.com/g/kubernetes-sig-release/c/P5gFtnjXDqI](https://groups.google.com/g/kubernetes-sig-release/c/P5gFtnjXDqI)**
    * Please take a look at the proposal and give feedback


## October 20, 2020 (recording)

**Host:** Stephen Augustus

**Note Taker**: Joseph Sandoval 

**Attendees:**



* Rob Kielty
* Marko Mudrinić
* Nabarun Pal
* Jeremy Rickard
* Arnaud Meukam
* Eddie Zaneski
* Carlos Panato
* Seth McCombs
* Joyce Kung
* Max Körbächer
* Gianluca Arbezzano
* Adolfo García Veytia

**Recurring Topics [timebox to N min]:**



* (if you have any… here are some suggestions)
* Welcome any new members or attendees
* Subproject updates
    * Licensing ([https://github.com/orgs/kubernetes/projects/31](https://github.com/orgs/kubernetes/projects/31))
    * Release Engineering ([https://github.com/orgs/kubernetes/projects/30](https://github.com/orgs/kubernetes/projects/30))
    * Release Team ([https://github.com/orgs/kubernetes/projects/29](https://github.com/orgs/kubernetes/projects/29))
    * CI Signal ([https://github.com/orgs/kubernetes/projects/11](https://github.com/orgs/kubernetes/projects/11))
        * Testgrid dashboard review:[ https://testgrid.k8s.io/sig-release](https://testgrid.k8s.io/sig-release) 
* New[ kubernetes/kubernetes issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Frelease) review
* Project board review:[ https://github.com/orgs/kubernetes/projects/23](https://github.com/orgs/kubernetes/projects/23)
* Incoming issue and PR triage
    * [org:kubernetes SIG Release issue needs-triage](https://github.com/search?q=org%3Akubernetes+is%3Aopen+is%3Aissue+label%3Asig%2Frelease+label%3Aneeds-triage)
    * [org:kubernetes SIG Release PR needs-triage](https://github.com/search?q=org%3Akubernetes+is%3Aopen+is%3Apr+label%3Asig%2Frelease+label%3Aneeds-triage)

**Open Discussion [timebox to N min]:**



* CVE Information on changelogs (@puerco) \
Ref:[ https://github.com/kubernetes/release/pull/1441](https://github.com/kubernetes/release/pull/1441)

    Sig-security meeting discussion with Adolfo about old PR about CVE information. RFC was needed on the old PR. Regenerate the change log up until the last minute. They would like the vulnerability released at the last minute. 


    Stephen shouts out release manager associates. Jumping through all the hurdles that included patches and CVE’. One thing missed was patching release notes. What we need to do is talk about the workflow as we land the above PR. The process needs a bit more definition. If you are doing the patch note you may not be privy to the CVE up until the last minute. Product security committee might need to be consulted. 


    Do we lift the mapfile to GCS? Do we need something private to do the generation of release notes? 


    Release-engineering tagged in PR to review. 

* What do we do alerts? “To make CI-Signal less magic and more sciency.” Lauri has authored a doc and solicited comments from the release teams. First goal is what we do with CI-Signal alerts. The aim is to document the very first step in the process. The new PR workflow follows the K/K template. The overall goal is to provide documentation for CI-Signal. Looking for flakes will start with CI-Signal board. Issues being found on the board and the follow through with developers is receiving no response. Being able to deliver flake reports that are easy to read for the devs. Simplifying the job and test will help make it easier for the users. Linting flake issues so that they are conforming to policy. 
    * PR:[ https://github.com/kubernetes/community/pull/5244](https://github.com/kubernetes/community/pull/5244)
* Questions: Jobs related to master release blocking. There is not a good gate from putting something on master release blocking. There is a doc:[ https://github.com/kubernetes/sig-release/blob/master/release-blocking-jobs.md](https://github.com/kubernetes/sig-release/blob/master/release-blocking-jobs.md) You have to be informing before blocking. The job should also fork. Forking annotations. Make sure to be informed when something is added to the board. Jobs that land on the board informing or blocking it needs to be forked. 
* [https://github.com/kubernetes-sigs/k8s-container-image-promoter](https://github.com/kubernetes-sigs/k8s-container-image-promoter) Stephen working on improvements. CIP Repo Improvements:[ https://github.com/kubernetes-sigs/k8s-container-image-promoter/issues/266](https://github.com/kubernetes-sigs/k8s-container-image-promoter/issues/266) Next thing is to decompose the code flow. CIP is not in an importable state. Promobot files are being used by KOPs. Getting CIP into an importable state is the first step. Moving all tools into K/release is the final goal. More discussion is needed.[ https://github.com/kubernetes/test-infra/pull/19626](https://github.com/kubernetes/test-infra/pull/19626) submitted by Carlos. 
* [CI Signal draft roadmap](https://docs.google.com/document/d/1Ath8r0Q0KggfAuQe0L_0_HXn_Pg7pwO9HliA6QVl4Qo/edit?userstoinvite=rob.kielty@gmail.com&ts=5f7b5754&actionButton=1#)
* Also review Dan’s PR:[ https://github.com/kubernetes/sig-release/pull/1163](https://github.com/kubernetes/sig-release/pull/1163)
* [Walk the project board](https://github.com/orgs/kubernetes/projects/23)


## October 6, 2020 ([recording](https://youtu.be/FNwPuRMnJJQ))

**Host:** Stephen Augustus

**Note Taker**: Tim Pepper

**Attendees:**



* Rob Kielty
* Marko Mudrinić
* Jim Angel
* Rey Lejano
* James Laverack
* Savitha Raghunathan
* Lauri Apple
* Tim Pepper
* Gianluca Arbezzano
* Nabarun Pal
* Daniel Mangum
* Carlos Panato
* Jorge Alarcon
* Sascha Grunert
* Verónica López
* Eddie Zaneski

**Recurring Topics [timebox to N min]:**



* Welcome any new members or attendees
* Subproject updates
    * Release Engineering ([https://github.com/orgs/kubernetes/projects/30](https://github.com/orgs/kubernetes/projects/30))
    * Release Team ([https://github.com/orgs/kubernetes/projects/29](https://github.com/orgs/kubernetes/projects/29))
    * CI Signal ([https://github.com/orgs/kubernetes/projects/11](https://github.com/orgs/kubernetes/projects/11))
        * Testgrid dashboard review:[ https://testgrid.k8s.io/sig-release](https://testgrid.k8s.io/sig-release) 
        * CI Signal Report dev in progress  sample output
        * [Flaking Jobs as at Mon Oct  5 16:44:32 Irish Standard Time 2020](https://docs.google.com/spreadsheets/d/1E5pFHC7kiDTv6QGUKVxWfA-lSJdrs71JJk2nQ9eNjV8/edit?usp=sharing)
* New[ kubernetes/kubernetes issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Frelease) review
* Project board review:[ https://github.com/orgs/kubernetes/projects/23](https://github.com/orgs/kubernetes/projects/23)

**Open Discussion [timebox to N min]:**



* Update about krel/anago effort—big chunks left in releaselib.sh:
    * Whole build process, building the artifacts (maybe won’t be much)
    * Testing done for Alpha but not for the other release types
    * Dropping md5/sha1: these were communicated as deprecated, hopefully things are clean now, but odds are somebody will be broken and need to fix their code still
    * Action Item: to communicate to community the previous message 
* [CI Signal draft roadmap](https://docs.google.com/document/d/1Ath8r0Q0KggfAuQe0L_0_HXn_Pg7pwO9HliA6QVl4Qo/edit?userstoinvite=rob.kielty@gmail.com&ts=5f7b5754&actionButton=1#)
    * braindumping which docs must we create to happy-path "what to do when I get a testgrid alert”?
* [Enhance and evangelise milestone-maintainers documentation and do training/retraining ](https://github.com/kubernetes/sig-release/issues/1257)
* [Walk the project board](https://github.com/orgs/kubernetes/projects/23)


## September 22, 2020 ([recording](https://youtu.be/DL6P5_QY8iQ))

**Host:** Stephen Augustus

**Note Taker**: TBD

**Attendees:**



* Vlad Gorodetsky
* Lauri Apple
* Sascha Grunert
* James Laverack
* Marky Jackson
* Marko Mudrinić
* Tim Pepper
* Jordan Liggitt
* Daniel Mangum
* Jeremy Rickard
* Nabarun Pal
* Savitha Raghunathan
* Rob Kielty
* Nick Young
* Rey Lejano
* Max Körbächer
* Eddie Zaneski
* Arnaud Meukam
* Gianluca Arbezzano
* Adolfo García Veytia
* Hosam Kamel

**Agenda:**



* WG LTS status read out and decision on continuation or completion
    * 1.19 and newer will have 1 year patch release support
    * Does 1.18 and 1.17 have N-3 release patch release support term or 9 months patch release support, unless somebody pushes for consensus on another choice
        * Jordan: support policy always stated in terms of N-3 release
            * 1.19, 1.20 slow down has pushed preceding three get ~1 year support
            * If cadence stays slow, 3 releases and 1 year align
        * Stephen: We plan on having a discussion at upcoming meeting to discuss cadence
            * “[Scientific Twitter Poll](https://twitter.com/stephenaugustus/status/1305902993095774210)”: Asked 3 or 4 releases, >700 votes. 
            * Lots of conversations will come into play, ext deps will box a lot of this.
        * N-3 (this is the[ stated support policy](https://kubernetes.io/docs/setup/release/version-skew-policy/#supported-versions))
            * [1.20 schedule](https://github.com/kubernetes/sig-release/tree/master/releases/release-1.20#timeline) targets release on 2020-12-08, meaning 1.17 will have support at least through then. 1.17.0 was released 2019-12-05, meaning 1.17 will have ~1 year of support per[ 3-release support policy](https://kubernetes.io/docs/setup/release/version-skew-policy/#supported-versions).
            * 1.21 schedule is TBD but is unlikely to be before the end of March 2021, meaning 1.18 will have support at least through then. 1.18.0 was released 2020-03-25, meaning 1.18 will have ~1 year of support per[ 3-release support policy](https://kubernetes.io/docs/setup/release/version-skew-policy/#supported-versions).
            * NOTE: 1.16 is now out of support, but also got ~1 year
        * 9mo’s (**_not_** the stated support policy)
            * 1.17 and 1.18 would go out of support based on the calendar, relative to their initial release date
            * 1.17 released 2020-01-10 so would go out of support in October 2020
            * 1.18 released 2020-04-06 so would go out of support in December 2020 
    * The topic of release cadence (currently 3 months and 4 per year) was not addressed with a KEP.  No consensus among competing proposals.  Consensus could be driven out of in a continuing WG LTS if there is a passionate leader for the task.  Otherwise it could fall back to SIG Release to push if it has the resources.  Either way if a change is community agreed, SIG Release can operationalize it.
    * **Decision**: consensus to end WG LTS.  It drove good discussion and concrete outcomes and next topics have logical owners.
    * **AI**: report for steering
        * final readout, decisions made, things accomplished, capture remaining questions or workstreams to shift back into sig-level tracking
    * **AI**: Nick can sleep instead of be in meetings at 1-2am
* 1.20 reopen for kubernetes/kubernetes
    * Background:
        * From July into August the long code freeze for 1.19 left lots of PRs to merge for 1.20. Added milestone restriction and controlled merges. Residual effect: restriction still in place
        * Original reopening plan:[ https://docs.google.com/document/d/1yI7o7R2bOB7QtkHUFMHMb5XObiJmzIAnJPuxhdAX-CA/edit](https://docs.google.com/document/d/1yI7o7R2bOB7QtkHUFMHMb5XObiJmzIAnJPuxhdAX-CA/edit) 
        * Prior discussions:
            * [https://groups.google.com/g/kubernetes-dev/c/YXGBa6pxLzo/m/SPb6yhNBBAAJ](https://groups.google.com/g/kubernetes-dev/c/YXGBa6pxLzo/m/SPb6yhNBBAAJ)
            * [https://groups.google.com/a/kubernetes.io/g/leads/c/BZZk0tG2cJU](https://groups.google.com/a/kubernetes.io/g/leads/c/BZZk0tG2cJU)
    * Question: Lift it or Leave In Place?
        * Leaving in place increases friction
        * Stephen: don’t have strong opinions at this point. Some value in building up reviewers/milestone maintainers and treating as an active triage activity. Not sure increased friction is worth it. Opened PR to remove the restriction. Planned to merge yesterday but held for discussion. 
        * Jordan: what is the goal of the milestone requirement: if it is to make sure someone with project health is making decisions about bug/feature merge, some SIGs do a good job triaging, some do not. Leaving the restriction in place will push more people to MM, adding more people to MM that don’t pay attention to correct signals won’t help. WG Reliability adding automated feedback seems like a better idea than human gate
        * Stephen: points to a triage problem, some work release team does is triage. Eventually the goal is to get to the point where RT goes away because we don’t need cat herders and having some RT functions we mask some triage issues.
        *  Current membership of team is made up of:
            * release team leads
            * individual sig designated milestone maintainers (typically sig leads)
        * Responsibilities/standard for milestoning an issue/PR is not currently clear
            * [https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/release.md](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/release.md)
            * [https://github.com/kubernetes/sig-release/blob/master/release-team/README.md](https://github.com/kubernetes/sig-release/blob/master/release-team/README.md) 
            * How to communicate these docs’ content to the broader Kubernetes org group?
            * Has been unclear and variable for many years, eg: required all along for tracked features/enhancements, required middle/late in release cycle (eg: after freeze), not required for other items or at other times, manually applied to most things and auto applied to some things.
            * SIG Release’s CI Signal folks can go out to other SIG and advertise themselves and the point of their workstream
            * SIGs have gotten info about all of this stuff in the chairs&leads forum, but some need to do more onboarding new people, doing triage/reviews/approves, handling milestone maintaining
            * Deflaking requires first a deep knowledge of the test itself (SIG is logical place for that) but ALSO a solid understanding of the Kubernetes CI system and this is a notable hurdle.  Education/training is the answer.
        * Lauri: data about processes SIG to SIG (triage, feature health check):[ https://docs.google.com/spreadsheets/d/1V6ixS-8OH2opd5wxeF5FOCTv6Qw9Fs9vjIj6zmuFKYw/edit#gid=243279358](https://docs.google.com/spreadsheets/d/1V6ixS-8OH2opd5wxeF5FOCTv6Qw9Fs9vjIj6zmuFKYw/edit#gid=243279358)
        * Eddie: testgrid is a veeeery intimidating tool, the user experience needs improved.
        * Testgrid: It is open source, owned & maintained by non-SIG-Release, suggestions are acted on, presumably contributors welcome)
    * PR:[ https://github.com/kubernetes/test-infra/pull/19277](https://github.com/kubernetes/test-infra/pull/19277)
    * **Decisions**:
        * Need an enhanced education/communication plan developed and operationalized to help SIGs with their CI signal improvements.
        * The PR removing the milestone restriction from k/k should merge, going back to only requiring the milestone during freeze.
        * Avoid dramatic changes to milestone maintainers list until education and standards around milestone is communicated better
        * Re-evaluate a better quality gating process (like the ones being proposed in WG Reliability)
* Triage Party and progress by Arnaud ([related prototype doc](https://docs.google.com/document/d/1Yen26GS7VBX5CydwT8lk2j1m6yyllZaqd-oXjyaEGYE/edit#heading=h.e87k3ltggrs8))
    * SIG Release:[ http://release.triage.k8s.io/s/bug-triage](http://release.triage.k8s.io/s/bug-triage)
    * eddiezane: SIG-CLI implementation[ https://tp.kuberneddies.dev/s/daily](https://tp.kuberneddies.dev/s/daily)
* Quick updates (one minute each):
    * Clearing out old items: Release Team retro items (GitHub issues and from the docs), RT other-items, Release Engineering board
    * Release Engineering has a[ Ways of Working agreement](https://docs.google.com/document/d/11IWywLmG2sPNt7ttAX6I9Pmq3ewxD-9l6vKgLg-FCQE/edit) in progress
    * [Project board](https://github.com/orgs/kubernetes/projects/23): is walking the board in this meeting still a goal(?)
        * Walking the board is good for delegation, status, reevaluating priorities, transparency
        * Release Team is walking their board now
        * Posting items in Slack as threads and making headway closing out old items


## September 8, 2020 ([recording](https://youtu.be/aBJkf4e5iNU))

**Host:** Jeffrey Sica (Retro Moderator)

**Note Taker**: TBD

**Attendees:**



* Carlos Panato
* Lauri Apple
* Savitha Raghunathan
* Vlad Gorodetsky
* Adolfo García Veytia

**Kubernetes 1.19 Release Retro, Part Two:**



* Please head to the retro doc:[ https://bit.ly/k8s119-retro](https://bit.ly/k8s119-retro)

**Open Discussion [timebox to N min]:**



* 


## August 25, 2020 ([recording](https://www.youtube.com/watch?v=fGvVElSoBG8))

**Host:** Stephen Augustus

**Note Taker**: Jorge Alarcon

**Attendees:**



* Sascha Grunert
* Max Körbächer
* Savitha Raghunathan
* Zachary Estrella
* Lauri Apple
* Daniel Mangum
* Rey Lejano
* Taylor Dolezal
* Vlad Gorodetsky
* Adolfo García Veytia
* Robert Kielty
* Carlos Panato
* Marko Mudrinić
* Marky Jackson

**Recurring Topics [timebox to N min]:**



* (if you have any… here are some suggestions)
* Welcome any new members or attendees
* Subproject updates
    * Release Team ([https://github.com/orgs/kubernetes/projects/29](https://github.com/orgs/kubernetes/projects/29))
        * 1.19.0 delayed until Wednesday (tomorrow)
            * giving some soak time to tests
        * Community meeting, planning to move to next week pending feedback from the team.
        *  CI Signal
            * integration and verify were flaking due to infra change. Infra change was reverted and no flakes since.
            * Few critical PRs merged late and we want to allow scalability jobs run a bit
            * Flakes appearing seem to be infra-related flakes but pinging SIGs to make sure these are not critical
            * We are a GO!
        * 1.20 updates
            * Jeremy Rickard selected as 1.20 lead
            * All role leads have been selected and PR-ed in
    * Release Engineering ([https://github.com/orgs/kubernetes/projects/30](https://github.com/orgs/kubernetes/projects/30))
        * Final 1.16 patch (1.16.15) scheduled for 9/2. Cherry pick deadline this Friday (8/28)
        * Rolled new image tag format for Debian base images: os_codename-vx.y.z, example: buster-v1.0.0
            * we need to surface what things have changed in between images - work for 1.20
        * Migrated go-runner image building to k/release
            * few things we built into distroless
            * starting 1.19 this will be used for core images. We have been observing during 1.19 and they seem happy.
            * core images are not the only things that depend on debian base.
            * there is an overarching work to move images to distroless.
            * When building images, we usually start go debian-base -> promote it -> debian-iptables -> promote (previous release we have to also build a hyperkube image). FInally we PR into kubernetes to update images.
            * distroless images are built on debian.
            * There are 2 streams of distroless static images : static-debian9 and static-debian10. We want to make sure this info is in the name.
            * go runner build has 2 stages: build binary and copy into status debian image.
        * k/release has a merge blocker applied until 1.19.0 is outCI Signal ([https://github.com/orgs/kubernetes/projects/11](https://github.com/orgs/kubernetes/projects/11))
            * Thank you to Sascha, Adolfo, Carlos, and few others.
            * we will get rid of anago - hopefully by end of year - but we want to minimize the variance so this will go until after 1.19.
        * Testgrid dashboard review:[ https://testgrid.k8s.io/sig-release](https://testgrid.k8s.io/sig-release) 
* New[ kubernetes/kubernetes issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Frelease) review
    * Interesting issues to look at
        * Docker Hub's new policy for limiting image pulls[ https://github.com/kubernetes/kubernetes/issues/94018](https://github.com/kubernetes/kubernetes/issues/94018)
        * gcr.io/google-containers and gcr.io/k8s-artifacts-prod don't work anymore[ https://github.com/kubernetes/kubernetes/issues/94013](https://github.com/kubernetes/kubernetes/issues/94013)
* Project board review:[ https://github.com/orgs/kubernetes/projects/23](https://github.com/orgs/kubernetes/projects/23)

**Open Discussion [timebox to N min]:**



* Proposal approved for reopening k/k for 1.20 development


## August 11, 2020 ([recording](https://www.youtube.com/watch?v=LIBXW2P4Rsw))

**Host:** Stephen Augustus

**Note Taker**: Lauri Apple

**Attendees:**



* Stephen Augustus
* Taylor Dolezal
* Marko Mudrinić
* James Laverack
* Sascha Grunert
* Jim Angel
* Carlos Panato
* Josh Berkus
* Mikael Johansson (Docs Shadow)
* Nabarun Pal
* Lauri Apple
* Jeremy Rickard
* Rey Lejano
* Rob Kielty
* Adolfo García Veytia
* Jorge Alarcon 
* Daniel Mangum
* Verónica López
* Joseph Sandoval
* Vlad Gorodetsky

**Recurring Topics [timebox to N min]:**



* We’re following the agenda!
* Welcome any new members or attendees
* Subproject updates
    * Licensing ([https://github.com/orgs/kubernetes/projects/31](https://github.com/orgs/kubernetes/projects/31))
        * No updates
        * Moving into 1.20, we’ll want to look at some of those issues. Looking for volunteers.
        * Don’t probably need a meeting on this subproject, but if you want to get involved let us know.
    * Release Engineering ([https://github.com/orgs/kubernetes/projects/30](https://github.com/orgs/kubernetes/projects/30))
        * k/release @ v0.4.0 is out (IT CHONKY):[ https://github.com/kubernetes/release/releases/tag/v0.4.0](https://github.com/kubernetes/release/releases/tag/v0.4.0)
            * Lots of new image builds
            * improvements to krel (thanks Adolfo and Sascha and everyone else on krel)
            * Nice updates on port from bash libraries over to Go -- moving on nicely. Project to see Anago replacement by end of 2020. Fingers crossed.
        * [Stephen] Debian base images
            * Some new ones. We’re moving to distroless images for lots of components living in k/k. New image called Go Runner -- some sugar on top of the distroless static image. Makes some images more lightweight -- should see images built with this from 1.19. We believe all images for core components are now updated.
            * Currently on Debian Buster, and we’ve pulled in security updates (CVE for Perl, for ex.) -- patched over last weekend+half. 
            * Still rolling PRs for updates to previous branches (hopefully done by end of the week)
            * Want system for automated Debian base images
            * Automated everything -- Stephen has ideas, wants to turn them into something cohesive before opening to discussion but essentially leveraging same mechanism as test-infra to update their images. Would involve making the auto-bumper and gce builder across multiple repos. Pattern could be useful to the entire community. Images triggering their own builds or on their own schedule. Could alleviate lots of CVE-related issues. 1.20, not trailing-1.19.
        * [Stephen] Golang updates
            * Master and release branches were already on Go rc.1 as of Sunday. PR merged for rc.2. then. Tracking well. Low friction outside of mechanics of doing a Go update.
            * Release is essentially gated on Go 1.15 going live. So far so good -- by early September?
            * AI: Stephen to ping the Go team to check in, get an update. They have a release milestone and set of issues to aggregate (blocking, etc.). They don’t directly dictate timing.
        * [Lauri] updates on process
            * New columns in the project board
            * Want to go through the “In Progress” work slowly
            * Sig-testing will talk about CI Policy Improvements tonight at their regular meeting -- great work done, thanks Rob Kielty and others for your contributions
    * Release Team ([https://github.com/orgs/kubernetes/projects/29](https://github.com/orgs/kubernetes/projects/29))
        * [Stephen] Timing / Code Thaw / Comms to k-dev
            * Still on target
            * KubeCon blackout, give folks time to decompress, take a break, prepare for their talks
            * After this period we’ll release if everything looks good
            * CI Policy Improvements going well
                * Often falls to wayside as we discuss features instead but stability’s key
                * Every release should be stable, so if we must pump brakes during a release we should: sig-testing, Tim, Stephen support this
            * Code Freeze: We’ve extended it and pushed Code Thaw to some unknown date. Initially discussed in the first draft of the updated release schedule. 
                * Stephen talking to RT -- aim to have no thaw until end of the cycle. 
                * AI: RT Leads to discuss today and decide.
                * AI: Stephen to write a note about this.
                * Josh Berkus: for rest of dev community that’s not attending regular RT meetings, what’s going on with Code Freeze and Code Thaw has been a bit mysterious. Josh talked to Taylor about adding some things to Release Lead handbook about providing more frequent updates when the schedule changes.
                    * But the schedule hasn’t changed? Outside of RCs and initial Freeze not much change, but seems like it.
                    * Yes it has: k-dev@ been silent. 
                    * Taylor: more clarity is better, weekly updates (here’s what happened) makes a lot of sense. 
                    * Meeting updates or a template around internal comms.
            * What are the most effective communication vehicles for big updates?
                * Some SIGs now using GitHub
                * What about Hack.md?
                * These notes should also probably go out to the SIG leads list. Expectation: if you’re a lead, you’re paying attention to that list.
        * [Taylor] Team updates
            * We have a 1.20 Release Lead: Jeremy Rickard YAYYYY
                * Talk to Jeremy about 1.20 topics
            * 7 open PRs for 1.19 / 1 critical/urgent
                * [https://github.com/kubernetes/kubernetes/pulls?q=is%3Aopen+is%3Apr+milestone%3Av1.19](https://github.com/kubernetes/kubernetes/pulls?q=is%3Aopen+is%3Apr+milestone%3Av1.19)
            * 15 open Issues for 1.19 / 6 critical/urgent
                * [https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+milestone%3Av1.19](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+milestone%3Av1.19)
            * KubeCon/CloudNativeCon break! 
                * Resuming meetings on Monday, August 24th
            * Targeting August 25th for 1.19 release
            * [Kubernetes 1.19 Release Retro](https://docs.google.com/document/d/1vJW2AyTS4RTTnnlmVA76vZFzdQt9XDBR80qOi5gvxl4/edit)
    * CI Signal ([https://github.com/orgs/kubernetes/projects/11](https://github.com/orgs/kubernetes/projects/11))
        * [Stephen] Formation this week, Jorge is point person and execution lead; Dan M., subproject co-owner (YAY)
            * Mission: Do exactly what the CI Signal team of the RT does today, but for all release branches
            * A lot of our sub-teams for the RT are extensions of other groups and CI Signal has a close relationship with sig-testing (yay collaboration for CI Improvements and stability tasks)
            * Would be responsible for defining what release blocking and informing looks like
            * Sascha (Rel Eng) and Jorge (CI Signal) to align with the focus they’ve had over multiple cycles
        * [Dan/Jorge] SIG Testing collab updates
            * Adding limits and resource requests has increased flakes but this number is going down because we know how things are scheduled now
            * Presubmits have been outside scope of CI Signal, but continuing the push
            * have seen some improvements (seeing more out of memory errors, but that’s good because we can now address it, why it’s happening, and create specific jobs)
            * On all release-blocking jobs we should have limits and resource requests now
            * On 1.19, cleaning up flakes, SIGs super-responsive, so keep Code Freeze around longer to let them fix things
        * Testgrid dashboard review:[ https://testgrid.k8s.io/sig-release](https://testgrid.k8s.io/sig-release)
    * WG LTS… is basically sleeping until 1.19 finishes support
        * Length of patch support for 1.17 and 1.18 is up to SIG-Release
        * Movement on retroactive support: it’s not part of the LTS KEP. 1.17 and 1.18 are the retroactive support.
        * If you’re supporting for three releases, it’s nearly a year anyway, so if release engineering wants to follow three releases then it becomes a sort of de facto policy. But LTS won’t decide that. 
        * AI: Back to SIG Release to decide.
        * AI: Josh can circle back with Lauri, go through the KEP 
* New[ kubernetes/kubernetes issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Frelease) review
* Project board review:[ https://github.com/orgs/kubernetes/projects/23](https://github.com/orgs/kubernetes/projects/23)

**Open Discussion [timebox to N min]:**


## July 28, 2020 ([recording](https://www.youtube.com/watch?v=OZB7DM2SHEo))

**Host:** Stephen Augustus

**Note Taker**: TBD

**Attendees:**



* Stephen Augustus
* Tim Pepper
* Taylor Dolezal
* Till Wegmüller
* Daniel Mangum
* Nabarun Pal
* Robert Kielty
* Adolfo García Veytia
* Joseph Sandoval
* Lauri Apple
* Jorge Alarcon
* Carlos Panato

**Recurring Topics [timebox to N min]:**



* (if you have any… here are some suggestions)
* Welcome any new members or attendees
* Subproject updates
    * Licensing ([https://github.com/orgs/kubernetes/projects/31](https://github.com/orgs/kubernetes/projects/31))
    * Release Engineering ([https://github.com/orgs/kubernetes/projects/30](https://github.com/orgs/kubernetes/projects/30))
    * Release Team ([https://github.com/orgs/kubernetes/projects/29](https://github.com/orgs/kubernetes/projects/29))
    * CI Signal ([https://github.com/orgs/kubernetes/projects/11](https://github.com/orgs/kubernetes/projects/11))
        * Testgrid dashboard review:[ https://testgrid.k8s.io/sig-release](https://testgrid.k8s.io/sig-release) 
* New[ kubernetes/kubernetes issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Frelease) review
* Project board review:[ https://github.com/orgs/kubernetes/projects/23](https://github.com/orgs/kubernetes/projects/23)

**Open Discussion [timebox to N min]:**



* **Go1.15**
    * 1.19 is being built with 1.15 rc1 (a prerequisite for rc1 is Google being willing to run all production on it).
    * Scalability also runs some tests on the latest.
* Kubernetes 1.19
    * trimming down critical issues
* Kubernetes 1.20
    * Starting to discuss timelines around conferences, holidays, and TBD 1.19. Broader conversation will start next week.
    * If interested in the release team please be on the lookout for the call for volunteers
* We have an action items Issue for 1.19:[ https://github.com/kubernetes/kubernetes/issues/93430](https://github.com/kubernetes/kubernetes/issues/93430)
    * CI Signal subproject ([https://github.com/kubernetes/sig-release/issues/966](https://github.com/kubernetes/sig-release/issues/966)) could be helping with a lot of these (see also “CI Signal” below)
* We’re still moving forward with our RT prioritization session results
    * 1:1’s with Leads complete
    * Drafting plans based on our priorities to organize how we can deliver them
    * Setting up our backlog to start Triage Partying
    * If you’ve served on a past RT, get in touch
* CI Signal
    * SIG Testing meeting later today
    * Jordan’s proposal “Policies to improve Kubernetes CI”:[ https://docs.google.com/document/d/1uuP9kS28u1LFyx83Yl-Sodu7-2N_exPRrEoiwbAe0wc/edit?ts=5f1f3819#heading=h.xgjl2srtytjt](https://docs.google.com/document/d/1uuP9kS28u1LFyx83Yl-Sodu7-2N_exPRrEoiwbAe0wc/edit?ts=5f1f3819#heading=h.xgjl2srtytjt)


## July 14, 2020 ([recording](https://youtu.be/xcLl9AE_ULI))

**Host:** Stephen Augustus

**Note Taker**: TBD

**Attendees:**



* Marko Mudrinić
* Jeremy Rickard
* Nabarun Pal
* Adolfo García Veytia
* Sascha Grunert
* Jorge Alarcon
* Arnaud Meukam
* Tim Pepper
* Taylor Dolezal
* Wilson Husin
* Tina Tsou
* Veronica Lopez
* Marko Mudrinic
* Robert Kielty 
* Carlos Panato
* Lauri Apple
* Jim Angel

**Recurring Topics [timebox to N min]:**



* (if you have any… here are some suggestions)
* Welcome any new members or attendees
* Subproject updates
    * Licensing ([https://github.com/orgs/kubernetes/projects/31](https://github.com/orgs/kubernetes/projects/31))
    * Release Engineering ([https://github.com/orgs/kubernetes/projects/30](https://github.com/orgs/kubernetes/projects/30))
    * Release Team ([https://github.com/orgs/kubernetes/projects/29](https://github.com/orgs/kubernetes/projects/29))
    * CI Signal ([https://github.com/orgs/kubernetes/projects/11](https://github.com/orgs/kubernetes/projects/11))
        * Testgrid dashboard review:[ https://testgrid.k8s.io/sig-release](https://testgrid.k8s.io/sig-release) 
* New[ kubernetes/kubernetes issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Frelease) review
* Project board review:[ https://github.com/orgs/kubernetes/projects/23](https://github.com/orgs/kubernetes/projects/23)

**Open Discussion [timebox to N min]:**



* Trending this week
    * 1.19 rc.1 July 14: happening right now, looking on track
    * Golang security bump: 
        * [https://groups.google.com/u/1/g/golang-announce/c/f2c5bqrGH_g](https://groups.google.com/u/1/g/golang-announce/c/f2c5bqrGH_g):
        * No info, but coming July 14
        * If high severity, options:
            * Delay k8s patch release (July 15 target), or
            * Do k8s patch release, incorporate without release again next week?
    * K8s patch releases target July 15
        * See also golang update...maybe need to delay this if PSC read of golang issue is high sev which we need to fix immediately
    * Branch ff & 1.19 & cherry picks:
        * will end at 1.19.0-rc.2 July 21,
        * cherry picks required after that
        * Prior releases usually had a few days of final cherry picks ahead of the .0 release, this time it will span ~2 weeks.
        * Branch management, CI Signal, Release Team, and Release Team lead will need to have conversations and evaluate what has merged on master, is it truly critical critical urgent for .0, is it ready, should it be pulled it.  With extra time, more people may try to push more content into .0 last minute, increasing risks.
    * VDF (Vanity domain flip) : next week, misc. PRs to tidy up urls, also svc acct kubernetes-release-test needs access to write staging
* Longer term
    * Patch release bug or feature relative to cloud providers:
        * Common issue of cloud provider wanting to add support for new, previously unknown scenario.  These may be complex (big feature, unlikely to backport), or fairly simple (append the specs of a new VM type to a list of available VM types, could we going ahead with these)
        * Need heuristics across the spectrum of issue types.  (current criteria here:[ https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md#what-kind-of-prs-are-good-for-cherry-picks](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-release/cherry-picks.md#what-kind-of-prs-are-good-for-cherry-picks)) 
    * Golang 1.15 trending early (maybe later?) August maybe?[ https://groups.google.com/d/msg/golang-dev/0XatS61k9j4/zIhil_L1AQAJ](https://groups.google.com/d/msg/golang-dev/0XatS61k9j4/zIhil_L1AQAJ) 
    * Bazel: ongoing but on-hold discussions around removing Bazel from Kubernetes.  We have 3+ ways of building, Bazel is complicated, but useful in test-infra.  Many would like to see it removed and a simpler mechanism for the caching used by test-infra.  Most recent discussion at[ https://github.com/kubernetes/kubernetes/issues/88553](https://github.com/kubernetes/kubernetes/issues/88553).  Would like to see this happen, but it needs dedicated staffing from people with the interest and know-how spanning k/k, release, and test
    * Kubernetes Golang image building: consuming straight from upstream golang’s community run semi-officialimages means we have more ability to build variations (and faster, instead of waiting for their volunteers). Doing this would enable us to get earlier signal on golang integration issues (eg: perf/scale) and speed up our regular patch version updates too.
* Triage party: having a health check issue versus ingress


## June 30, 2020 ([recording](https://youtu.be/7M4RIwKmzNk))

**Host:** Tim Pepper

**Note Taker**: TBD

**Attendees:**



* Marky Jackson
* Sascha Grunert
* Adolfo García Veytia
* Taylor Dolezal
* Jim Angel
* Tina Tsou
* Tim Pepper
* Marko Mudrinić
* Arnaud Meukam
* Jorge Alarcon
* Gianluca Arbezzano
* Rey Lejano
* Rob Kielty
* Carlos Panato
* Vlad Gorodetsky
* Lauri Apple

**Recurring Topics [timebox to N min]:**



* (if you have any… here are some suggestions)
* Welcome any new members or attendees
* Subproject updates
    * Licensing ([https://github.com/orgs/kubernetes/projects/31](https://github.com/orgs/kubernetes/projects/31))
    * Release Engineering ([https://github.com/orgs/kubernetes/projects/30](https://github.com/orgs/kubernetes/projects/30))
        * Mapping Release Notes to fix-up:
            * Can iterate on the notes early in the cycle and be able to add information \
[https://github.com/kubernetes/release/pull/1373](https://github.com/kubernetes/release/pull/1373)
            * Can add special CVE details mentioned once they’re being made public[ https://github.com/kubernetes/release/issues/1354](https://github.com/kubernetes/release/issues/1354))
            * Yaml mapping files to override the release-note (and other) fields automatically pulled in for a given PR
            * Thanks Adolfo, Sascha!  Makes it easier to spread work across time on large .0 releases and eases last minute handling of security issues.
    * Release Team ([https://github.com/orgs/kubernetes/projects/29](https://github.com/orgs/kubernetes/projects/29))
        * Eight (8) weeks away from release week!
        * FF until RC.2, everything else is Cherry Picks (one week of FF, three weeks of CPs)
            * Merge restrictions for roughly a month (from Code Freeze/Branch Cut to CP deadline)
    * CI Signal ([https://github.com/orgs/kubernetes/projects/11](https://github.com/orgs/kubernetes/projects/11))
        * Testgrid dashboard review:[ https://testgrid.k8s.io/sig-release](https://testgrid.k8s.io/sig-release) 
        * Have a first conformance run green after (a week?) red...hopefully fixed on 3rd attempt
* New[ kubernetes/kubernetes issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Frelease) review
* Project board review:[ https://github.com/orgs/kubernetes/projects/23](https://github.com/orgs/kubernetes/projects/23)

**Open Discussion [timebox to N min]:**



* Migrating kubelet from Hyperkube [ Marko Mudrinic]
    * Do we have any recommendations how kubelet should be run, especially for container Linux distros (Flatcar, Fedora)?  Check with SIG Node if they have preferences.  Kubelet in container has been considered deprecated.
    * Should we consider making a kubelet image?
        * If not, can we provide some recommendations on what image should be used or how the image should be built?
        * For reference: deprecate “containerized kubelet”[ https://github.com/kubernetes/kubernetes/issues/74148](https://github.com/kubernetes/kubernetes/issues/74148)
            * [https://github.com/kubernetes/kubernetes/pull/74267](https://github.com/kubernetes/kubernetes/pull/74267) “Containerized kubelet was originally part of a level of self-hosting, but the idea ran into multiple issues and folks are no longer using it. There are no owners for this feature and the CI jobs are flaky as well.”
            * kind still runs kubelet in a container, it just does not use the flag (--containerized) or volume mounts.
* ARM64 initial support [ Tina Tsou, Robin Lu, Howard Zhang et al from ARM ]
    * Walk through adding the CI jobs to the release informing board and how to move the test reports into release-blocking.
    * Discussion thread:[ https://github.com/kubernetes/kubernetes/issues/86295](https://github.com/kubernetes/kubernetes/issues/86295)
    * Currently, we can use kubeadm/kops to deploy an arm64 conformance test cluster.
    * All known tests related to arm64:
        * [https://testgrid.k8s.io/conformance-arm](https://testgrid.k8s.io/conformance-arm)
        * [https://testgrid.k8s.io/sig-node-arm64](https://testgrid.k8s.io/sig-node-arm64)
        * [https://k8s-testgrid.appspot.com/sig-cluster-lifecycle-kops#kops-aws-arm64](https://k8s-testgrid.appspot.com/sig-cluster-lifecycle-kops#kops-aws-arm64)
    * What else can we do?
        * Have discussed Dim & Ben
        * Have discussed with SIG Node and are on next agenda
        * Should discuss with SIG Arch (along with Illumos)[ https://docs.google.com/document/d/1BlmHq5uPyBUDlppYqAAzslVbAO8hilgjqZUTaNXUhKM/edit#](https://docs.google.com/document/d/1BlmHq5uPyBUDlppYqAAzslVbAO8hilgjqZUTaNXUhKM/edit#)  Thursday July 2
        * Potential gaps:
            * SIG Node evaluation of readiness?
            * SIG Arch thoughts on process for adding globally “support” for arch/distro?
            * Federated tests:
                * are running in a VM and had some host networking issues.  Test is stable (periodic set to daily), but weren’t getting 
                * Lubomir: aware in SIG Cluster Lifecycle that ARM works based on user reports, but haven’t had the test signal so very much appreciate the effort to formalize it.  The project needs a succinct list of arch/OS variations and their current status.
                * Tina: many companies internally have it running and are doing CI, so now is time for community CI
            * Build artifacts: need to understand if/which additional build artifacts are needed.  We have golang ones and containers.  Do we also need RPMs/Debs
            * Phrasing:  this isn’t “initial support”.  We’ve had that.  This is “Additional test signal” and quality assurance, which gets at a more formal concept of support
* Triage-Party Update
    * Marky: Almost there on tool, some DNS tweeking
    * Tim: when will we do our parties?
    * Marky: Doodle coming soon to the mailing list
    * Lauri: let know if help on moderating the party
* KubeCon EU: will need to record our SIG sessions soon (presenters watch for email on it)


## June 16, 2020 ([recording](https://youtu.be/ypnXMZcKJxI))

**Host:** Stephen Augustus

**Note Taker**: TBD

**Attendees:**



* Sascha Grunert
* Daniel Mangum
* Tim Pepper
* Nikhita Raghunath
* Carlos Panato
* Seth McCombs
* Marky Jackson
* Adolfo Garcia Veytia
* Rey Lejano
* Arnaud Meukam
* Jorge Alarcon (the people ↑ are cool)

**Recurring Topics [timebox to N min]:**



* (if you have any… here are some suggestions)
* Welcome any new members or attendees
* Subproject updates
    * Licensing ([https://github.com/orgs/kubernetes/projects/31](https://github.com/orgs/kubernetes/projects/31))
    * Release Engineering ([https://github.com/orgs/kubernetes/projects/30](https://github.com/orgs/kubernetes/projects/30))
    * Release Team ([https://github.com/orgs/kubernetes/projects/29](https://github.com/orgs/kubernetes/projects/29))
    * CI Signal ([https://github.com/orgs/kubernetes/projects/11](https://github.com/orgs/kubernetes/projects/11))
        * Testgrid dashboard review:[ https://testgrid.k8s.io/sig-release](https://testgrid.k8s.io/sig-release) 
* New[ kubernetes/kubernetes issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Frelease) review
* Project board review:[ https://github.com/orgs/kubernetes/projects/23](https://github.com/orgs/kubernetes/projects/23)

**Open Discussion [timebox to N min]:**



* SIG Technical Leads discussion
    * Proposing Jorge and Sascha as TLs:[ https://groups.google.com/d/topic/kubernetes-sig-release/2VZndEcjPTo/discussion](https://groups.google.com/d/topic/kubernetes-sig-release/2VZndEcjPTo/discussion)
    * Lazy consensus timeout: Thursday, June 18th at 4pm US Eastern
* Deploy triage-party:[ https://github.com/kubernetes/k8s.io/pull/967](https://github.com/kubernetes/k8s.io/pull/967)
    * Awaiting github token in cluster and dns
    * Could start against k/sig-release and k/release (and k/enhancements?) for simpler SIG Release start than the volume of k/k
* WG Naming proposal[ https://groups.google.com/g/kubernetes-dev/c/kry8QbIpxRs/m/xaWKZYUGBgAJ](https://groups.google.com/g/kubernetes-dev/c/kry8QbIpxRs/m/xaWKZYUGBgAJ) 
    * Basic goal to remove racist or non-inclusive language from project
    * Some docs PRs already moving away from whitelist/blacklist
    * Control plane terminology (master/slave)
    * The way we discuss control plane members mailing list thread[ https://groups.google.com/forum/#!msg/kubernetes-sig-cluster-lifecycle/IjN_9n0KEUg/h4i93a_EAgAJ](https://groups.google.com/forum/#!msg/kubernetes-sig-cluster-lifecycle/IjN_9n0KEUg/h4i93a_EAgAJ)
* 1.19 release schedule change[ https://groups.google.com/g/kubernetes-dev/c/TVXhcNO3SPU/m/-Uj-xJP2BQAJ](https://groups.google.com/g/kubernetes-dev/c/TVXhcNO3SPU/m/-Uj-xJP2BQAJ) 
    * How do we communicate more effectively?
    * Document how we do external communications
* Illumos OS support? [ https://github.com/kubernetes/kubernetes/issues/91570](https://github.com/kubernetes/kubernetes/issues/91570)
    * First recorded Hi from the[ illumos](http://illumos.org/) community: continuation of OpenSolaris
    * Till Wegmueller is going to work up a KEP for Kubernetes support of the illumos zones implementation (eg: add Illumos container support next to Linux and Windows in k8s)
    * OS has stable interfaces and CRI/CNI implementations
    * Implications for k8s dev/test/release/conformance processes across the board
    * SIG Architecture meeting agenda/time/links:[ http://bit.ly/sig-architecture](http://bit.ly/sig-architecture) 
    * ML discussion:[ https://groups.google.com/d/topic/kubernetes-sig-architecture/eHBFgfd6Qxg/discussion](https://groups.google.com/d/topic/kubernetes-sig-architecture/eHBFgfd6Qxg/discussion)
* Kubelet.service crashloop service change:[ https://github.com/kubernetes/release/pull/1352](https://github.com/kubernetes/release/pull/1352)
    * Want to change the systemd unit file to not be default enabled/started
    * Shouldn’t change that in patch releases
    * The file lives in k/release, but is not forked (or easily forkable?)
    * Where should the spec files for packages live (eg: k/release or k/k)?  Preferably in the component repo.
    * Where should the systemd unit files for project components like kubelet exist (eg: k/release or the corresponding component’s repo...k/k, k/kubeadm, k/kubelet)?  Preferably in the component repo.
    * Long term need to allow the package content (and spec?) to be forked and versioned
    * Today SIG CL / kubeadm sees the systemd unit file issue as a minor annoyance.  People understand it and workaround it if needed.  Bigger issue is the packages’ current drop in config file which includes config elements which are going away as a potentially breaking change, and fixing that would require the packaging be forked and versioned
* Golang updates
    * Still in-flight:
        * go1.14.4
        * go1.13.12
    * [Stephen] Pending a repo-infra bump for bazel rules_go


## June 2, 2020 -[ Meeting canceled](https://groups.google.com/d/topic/kubernetes-sig-release/ZElQ4flH3so/discussion)


## May 19, 2020 ([recording](https://youtu.be/GwFnwmCkOGI))

**Host:** Stephen Augustus

**Note Taker**: TBD

**Attendees:**



* Daniel Mangum
* Vlad Gorodetsky
* Marko Mudrinić
* Rey Lejano
* Jorge Alarcon
* Tim Pepper
* Sascha Grunert
* Verónica López
* Nabarun Pal
* John T Skarbek
* Taylor Dolezal
* Harsha Narayana
* Carlos Panato
* Ricky Lindenhovius
* Gianluca Arbezzano
* Rob Kielty
* Adolfo García Veytia

**Recurring Topics [timebox to N min]:**



* (if you have any… here are some suggestions)
* Welcome any new members or attendees
* Subproject updates
    * Licensing ([https://github.com/orgs/kubernetes/projects/31](https://github.com/orgs/kubernetes/projects/31))
    * Release Engineering ([https://github.com/orgs/kubernetes/projects/30](https://github.com/orgs/kubernetes/projects/30))
    * Release Team ([https://github.com/orgs/kubernetes/projects/29](https://github.com/orgs/kubernetes/projects/29))
    * CI Signal ([https://github.com/orgs/kubernetes/projects/11](https://github.com/orgs/kubernetes/projects/11))
        * Testgrid dashboard review:[ https://testgrid.k8s.io/sig-release](https://testgrid.k8s.io/sig-release) 
* New[ kubernetes/kubernetes issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Frelease) review
* Project board review:[ https://github.com/orgs/kubernetes/projects/23](https://github.com/orgs/kubernetes/projects/23)

**Open Discussion [timebox to N min]:**



* Base images
    * debian-base / debian-iptables: first update in quite a while.  These images have had (and will always) a smattering of CVEs, so important to keep up to date.
    * go-runner
    * Updated base image exception list:[ https://github.com/kubernetes/sig-release/blob/master/release-engineering/baseimage-exception-list.md](https://github.com/kubernetes/sig-release/blob/master/release-engineering/baseimage-exception-list.md)
    * Etcd
        * Do we need our own?  It is just basic etcd on our baseimage, plus a migration shell script. Do we have upgrade[ tests depending on its migrate-if-needed.sh](https://github.com/kubernetes/kubernetes/tree/master/cluster/images/etcd) script?
        * Follow-up w/ Dims on status for this
        * [https://github.com/kubernetes/kubernetes/tree/d63d77dc4cae044702dac1fc5a97fafebebcbb0f/cluster/images/etcd/migrate](https://github.com/kubernetes/kubernetes/tree/d63d77dc4cae044702dac1fc5a97fafebebcbb0f/cluster/images/etcd/migrate) includes a go based etcd migration and a commit from 2 years ago “Reimplement migrate-if-needed.sh in go”
* 1.19.0-beta.0 released
    * [https://groups.google.com/forum/#!topic/kubernetes-announce/E7C1to9mrSA](https://groups.google.com/forum/#!topic/kubernetes-announce/E7C1to9mrSA)
    * Includes updated base images (as above)
    * Go dependency report is now autogenerated (thx Sascha!).  See the release note link on kubernetes-announce: Dependencies {Added, Changed, Removed}
* Patch releases tomorrow
* Updates from Marky:
    * Triage-Party: @veronica, @xmudrii and I met yesterday to start lining up the tasks to drive to completion.
        * Smooth experience trialing w/ minikube.
        * Looking at options for infra hosting.  Not this week, but next week WG K8s Infra:[ https://bit.ly/wg-k8s-infra-notes](https://bit.ly/wg-k8s-infra-notes) …this initial triage party hosting is quite possibly something they could get up quickly.
        * [Stephen] Could there be a top level navigator page (like testgrid.k8s.io) to drop into the triage party for any SIG using it?
    * Continue working on go version bump
        * [Stephen] go 1.14.[0,1,2] update attempt on master has seen some unexpected scalability issue
        * [Stephen] Needs go1.13.11 (since it just came out for a 390x nil dereference in the compiler)
* Annual support update:[ https://github.com/kubernetes/enhancements/pull/1782](https://github.com/kubernetes/enhancements/pull/1782)
* Cherrypick approval request - “Add back anti-affinity to kube-dns pods”  [prameshj]
    * 1.18[ https://github.com/kubernetes/kubernetes/pull/91061](https://github.com/kubernetes/kubernetes/pull/91061)
    * 1.17[ https://github.com/kubernetes/kubernetes/pull/91060](https://github.com/kubernetes/kubernetes/pull/91060)
    * Re-re-fixing past issue (1.15 timeframe?), with possible scalability implications, but as of yesterday has SIG Scalability (wojtek-t) has ACK’d
    * Kube-dns not default on these newer versions so less test coverage.
    * Past cherry pick deadline for tomorrow’s release.  Will merge Thursday for June’s patch release, leaving time to possibly see if there’s any additional test feedback on 1.19/master or 1.18/1.17 ahead of next patch release.
* Re-re-fixing past issue with complex possible scalability implications, but as of yesterday has SIG Scalability (@wojtek-t) ACK
* KEPS
    * [https://git.k8s.io/enhancements/keps/sig-release/1729-rebase-images-to-distroless](https://git.k8s.io/enhancements/keps/sig-release/1729-rebase-images-to-distroless)
    * [https://git.k8s.io/enhancements/keps/sig-release/1731-publishing-packages](https://git.k8s.io/enhancements/keps/sig-release/1731-publishing-packages)
    * [https://git.k8s.io/enhancements/keps/sig-release/1732-artifact-management](https://git.k8s.io/enhancements/keps/sig-release/1732-artifact-management)
    * [https://git.k8s.io/enhancements/keps/sig-release/1733-release-notes](https://git.k8s.io/enhancements/keps/sig-release/1733-release-notes)
    * [https://git.k8s.io/enhancements/keps/sig-release/1734-k8s-image-promoter](https://git.k8s.io/enhancements/keps/sig-release/1734-k8s-image-promoter)
* 


## May 5, 2020 ([recording](https://youtu.be/Vq0KLO5dm1s))

**Host:** Stephen Augustus

**Note Taker**: TBD

**Attendees:**



* Sascha Grunert
* Vlad Gorodetsky (Bug Triage Shadow)
* Marko Mudrinić
* Mikael Johansson (Docs Shadow)
* Daniel Mangum
* Rey Lejano
* Jim Angel
* Jeremy Rickard
* Taylor Dolezal
* Nabarun Pal
* Wilson Husin (Release Notes Shadow)
* Gianluca Arbezzano (Bug Triage Lead)
* Fei Yang
* Adolfo García Veytia
* Carlos Panato

**Recurring Topics [timebox to N min]:**



* (if you have any… here are some suggestions)
* Welcome any new members or attendees
* Subproject updates
    * Licensing ([https://github.com/orgs/kubernetes/projects/31](https://github.com/orgs/kubernetes/projects/31))
    * Release Engineering ([https://github.com/orgs/kubernetes/projects/30](https://github.com/orgs/kubernetes/projects/30))
    * Release Team ([https://github.com/orgs/kubernetes/projects/29](https://github.com/orgs/kubernetes/projects/29))
    * CI Signal ([https://github.com/orgs/kubernetes/projects/11](https://github.com/orgs/kubernetes/projects/11))
        * Testgrid dashboard review:[ https://testgrid.k8s.io/sig-release](https://testgrid.k8s.io/sig-release) 
* New[ kubernetes/kubernetes issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Frelease) review
* Project board review:[ https://github.com/orgs/kubernetes/projects/23](https://github.com/orgs/kubernetes/projects/23)

**Open Discussion [timebox to N min]:**



* Kubernetes 1.19 release schedule update:[ https://github.com/kubernetes/sig-release/blob/master/releases/release-1.19/README.md](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.19/README.md)
    * **Monday, April 13**: Week 1 - Release cycle begins
    * **Tuesday, May 19**: Week 6 -[ Enhancements Freeze](https://github.com/kubernetes/sig-release/blob/master/releases/release_phases.md#enhancements-freeze)
    * **Thursday, June 25**: Week 11 -[ Code Freeze](https://github.com/kubernetes/sig-release/blob/master/releases/release_phases.md#code-freeze)
    * **Thursday, July 9**: Week 14 - Docs must be completed and reviewed
    * **Tuesday, August 4**: Week 17 - Kubernetes v1.19.0 released
    * **Thursday, August 20**: Week 19 - Release Retrospective
* Kubernetes 1.15 release this week:[ https://github.com/kubernetes/sig-release/issues/1051](https://github.com/kubernetes/sig-release/issues/1051)
* kube-cross variant builds:[ https://github.com/kubernetes/release/pull/1258](https://github.com/kubernetes/release/pull/1258)
* Release Team meetings moving to bi-weekly until June 1st.


## April 21, 2020 ([recording](https://youtu.be/6I3tetpOlK8))

**Host:** Stephen Augustus

**Note Taker**: Tim Pepper

**Attendees:**



* Marky Jackson
* Gianluca Arbezzano
* Jim Angel
* Jorge Alarcon
* Jordan Liggitt
* Vlad Gorodetsky
* Sascha Grunert
* John Belamaric
* Wilson Husin
* Bart Smykla
* Rey Lejano
* Mo Khan
* Daniel Mangum
* Bob Killen
* Taylor Dolezal
* Adolfo García Veytia
* Nikhita Raghunath
* Jeremy Rickard
* Tim Pepper
* Verónica López

**Open Discussion [timebox to N min]:**



* **Discuss changes to the release timeline**
    * Community announcement:[ https://groups.google.com/d/topic/kubernetes-dev/IVpiIOZ4WcM/discussion](https://groups.google.com/d/topic/kubernetes-dev/IVpiIOZ4WcM/discussion)
    * PR:[ https://github.com/kubernetes/sig-release/pull/1058](https://github.com/kubernetes/sig-release/pull/1058)
    * Could we make a declaration of no removal of deprecated features, or even no feature alpha/beta/ga promotions?
    * How much risk do we have unmanaged today in a release cycle?  How much risk accumulates during an elongated release cycle?
    * Two dimensions of activity and required resources need consideration:
        * Developer activity and inability/ability to make forward progress
        * Consumer complexity in a new release (especially the changelog section list “must do before upgrade”...how can we drive it to be empty this cycle)
    * Desires are:
        * less human toil in our project’s developers
        * less new feature quality risk and at least maintained quality:  
            * Can we get SIGs to decrease/defer any major feature work?
            * Can we get SIGs to shift some feature focus to test enhancing focus?
            * Action Required label (“release-note-action-required”) is a sign post we could key off (potentially requiring late reverts)
        * less end-user/consumer toil in adopting releases right now:
            * Adding a supported release has generally been accepted as doable and gives some breathing room to consumers (although they may need more now)
            * WG LTS has been looking at this problem already, but consumers are likely now in a worse position than they’d been in during the WG’s discussions
            * KEP[ https://github.com/kubernetes/enhancements/pull/1497](https://github.com/kubernetes/enhancements/pull/1497) likely to be proposed this week as “implementable” with lazy consensus deadline to merge
    * Contributor experience impact:
        * Need to be cognizant of new barriers to entry now are piled on top of an already difficult contributor experience for first time contribution in the project.
        * Even some existing contributors are seeing notable increased activity and developer efficiency because crisis drives focus for them.
        * What about contributors whose sole job is to deliver some content in k8s and they are focused on it and it brings them joy and now they’re not allowed by the community to do it?
    * How much has a longer than three weeks elongation been discussed?
        * 4, 5, 6 months for 1.19?
        * If we push 1.19 a bit more to +6weeks-ish, then 1.20 would be the last release for 2020 and perhaps then go back to normal in 2021
        * Or if we keep 1.19 only slightly elongated, then a normal 1.20, and then a tiny December 1.21 “stability release”. [ What is a “stability release”?](https://github.com/kubernetes/sig-release/issues/809)
    * Schedule options
    * 

<table>
  <tr>
   <td>
<strong>Event</strong>
   </td>
   <td>
<strong>Date (normal?)</strong>
   </td>
   <td>
<strong>Date (+3 weeks)</strong>
   </td>
   <td>
<strong>Date (+6 weeks)</strong>
   </td>
   <td>
<strong>Date (+8 weeks)</strong>
   </td>
  </tr>
  <tr>
   <td>
<p style="text-align: right">
Enhancements freeze</p>

   </td>
   <td>
May 5
   </td>
   <td>
May 12
   </td>
   <td>
May 19
   </td>
   <td>
May 19
   </td>
  </tr>
  <tr>
   <td>
<p style="text-align: right">
Code freeze</p>

   </td>
   <td>
June 11
   </td>
   <td>
June 9
   </td>
   <td>
June 18
   </td>
   <td>
June 18
   </td>
  </tr>
  <tr>
   <td>
<p style="text-align: right">
Cherry pick deadline</p>

   </td>
   <td>
June 25
   </td>
   <td>
June 25
   </td>
   <td>
July 31
   </td>
   <td>
July 30
   </td>
  </tr>
  <tr>
   <td>
<p style="text-align: right">
Release target</p>

   </td>
   <td>
June 30
   </td>
   <td>
July 21
   </td>
   <td>
August 18
   </td>
   <td>
August 25
   </td>
  </tr>
  <tr>
   <td>
<strong>Consequences</strong>
   </td>
   <td>
Human pressure
   </td>
   <td>
<ul>

<li> \
Still has enhancements really soon

<li>Very short gap from enhancements to code freeze
</li>
</ul>
   </td>
   <td>
<ul>

<li> \
Get 1.20 out in December

<li>Encourage/require<a href="https://github.com/kubernetes/kubernetes/issues/85892"> feature branch development</a>

<li>Shortness between enhancements freeze and code freeze means only smaller, done-er things make this release, others continue dev for 1.20

<li><strong>[Stephen] Post-meeting update</strong> 
<ul>
 
<li><strong>This happens immediately after KubeCon</strong>
</li> 
</ul>
</li> 
</ul>
   </td>
   <td>
<ul>

<li> \
Get 1.20 out in DecemberEncourage/require<a href="https://github.com/kubernetes/kubernetes/issues/85892"> feature branch development</a>

<li>Shortness between enhancements freeze and code freeze means only smaller, done-er things make this release, others continue dev for 1.20

<li><strong>[Stephen] Post-meeting update</strong> 
<ul>
 
<li><strong>Longer Code Freeze</strong>
 
<li><strong>Adds a release blackout period of two weeks to compensate for KubeCon </strong>
</li> 
</ul>
</li> 
</ul>
   </td>
  </tr>
</table>




* 
* 


## April 7, 2020 ([recording](https://youtu.be/DEa9_2suWUI))

**Host:** Stephen Augustus

**Note Taker**: TBD

**Attendees:**



* Daniel Mangum
* Jorge
* Marky Jackson
* Sascha Grunert
* Taylor Dolezal
* Joseph Sandoval
* Rey Lejano
* Bob Killen

**Recurring Topics [timebox to N min]:**



* (if you have any… here are some suggestions)
* Welcome any new members or attendees
* Subproject updates
    * Licensing ([https://github.com/orgs/kubernetes/projects/31](https://github.com/orgs/kubernetes/projects/31))
    * Release Engineering ([https://github.com/orgs/kubernetes/projects/30](https://github.com/orgs/kubernetes/projects/30))
    * Release Team ([https://github.com/orgs/kubernetes/projects/29](https://github.com/orgs/kubernetes/projects/29))
    * CI Signal ([https://github.com/orgs/kubernetes/projects/11](https://github.com/orgs/kubernetes/projects/11))
        * Testgrid dashboard review:[ https://testgrid.k8s.io/sig-release](https://testgrid.k8s.io/sig-release) 
* New[ kubernetes/kubernetes issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Frelease) review
* Project board review:[ https://github.com/orgs/kubernetes/projects/23](https://github.com/orgs/kubernetes/projects/23)

**Open Discussion [timebox to N min]:**



* Kubernetes 1.19 discussion
    * Kicking off the 1.19 release: this is how we do it 😄
        * [https://github.com/kubernetes/sig-release/pull/1043](https://github.com/kubernetes/sig-release/pull/1043) 
    * Should we delay?
        * Doesn’t make sense due to holiday conflicts with timelines
        * Release to start officially 4/13
    * [Stephen] Focus doc for the quarter
        * kubeadm OOT KEP
            * [https://github.com/kubernetes/enhancements/pull/1425](https://github.com/kubernetes/enhancements/pull/1425) 
        * LTS support KEP
            * [https://github.com/kubernetes/enhancements/pull/1497](https://github.com/kubernetes/enhancements/pull/1497) 
    * KEPs are now in a directory structure:[ https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/617-improve-kep-implementation](https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/617-improve-kep-implementation) 
    * Removing fast-forwards in the 1.19 release
        * Do we need them?
        * Want to decrease the amount of alphas, do more betas, add one more RC to the cycle
    * Issue Triage Workflow and Automation
        * [https://github.com/kubernetes/enhancements/pull/1554](https://github.com/kubernetes/enhancements/pull/1554) 


## March 23, 2020 ([recording](https://youtu.be/utNRJXDOMz0))

**Host:** Tim Pepper

**Note Taker**: TBD

**Attendees:**



* Bob Killen
* Jeremy Rickard
* Josh Berkus
* Daniel Mangum
* Bart Smykla
* Jorge Alarcon
* Taylor Dolezal
* Joseph Sandoval
* Sascha Grunert
* Adolfo Garcia Veytia
* Rey Lejano

**Recurring Topics [timebox to N min]:**



* (if you have any… here are some suggestions)
* Welcome any new members or attendees
    * Joseph Sandoval from Adobe
* 1.19 Release Lead Intro (Taylor)
    * Release team lead selection is open and happening, see GitHub:
        * [https://github.com/kubernetes/sig-release/issues/1031](https://github.com/kubernetes/sig-release/issues/1031) (Assemble 1.19 Release Team)
        * Full list of 1.19 Milestone Issues:[ https://github.com/kubernetes/sig-release/milestone/14](https://github.com/kubernetes/sig-release/milestone/14) 
* Subproject updates
    * Licensing ([https://github.com/orgs/kubernetes/projects/31](https://github.com/orgs/kubernetes/projects/31)): stalled
    * Release Engineering ([https://github.com/orgs/kubernetes/projects/30](https://github.com/orgs/kubernetes/projects/30))
        * Branch management:  in the past we’ve created the release branch very early with mostly manual git-fast-forward.
            * Reasons:
                * Gives extra CI signal (redundant test of same commits on different branches)
                * extra eyes on code coming from master to release branch (ie: look at all merged commits and affirm they should technically go to the release branch)
                * practice operationally the tooling and processes around shifting content from master to release branch
                * Upgrade test variations
            * Can we create the branch later?  Yes.
            * How much later?  Code thaw is too late.  Code freeze might be sufficient
            * Issue to discuss further:[ https://github.com/kubernetes/release/issues/1207](https://github.com/kubernetes/release/issues/1207)
    * Release Team ([https://github.com/orgs/kubernetes/projects/29](https://github.com/orgs/kubernetes/projects/29))
        * 1.18: last week was potentially looking to delay a few days, but looking good as the week starts
        * 1.19: team forming aiming for around first week of April
    * WG-LTS
        * KEP still in discussion at[ https://github.com/kubernetes/enhancements/pull/1497](https://github.com/kubernetes/enhancements/pull/1497)
    * Testgrid dashboard review:[ https://testgrid.k8s.io/sig-release](https://testgrid.k8s.io/sig-release) 
    * Project board review:[ https://github.com/orgs/kubernetes/projects/23](https://github.com/orgs/kubernetes/projects/23)
        * Promote KinD tests to blocking[ https://github.com/kubernetes/kubeadm/issues/1599](https://github.com/kubernetes/kubeadm/issues/1599):
            * Is there general consensus to move this from informing to blocking?  Informing board tests are already intended as just as important as blocking, but in informing as recognition of the test not being perfectly stable.
            * Useful signal
            * Flakes exist occasionally, usually around bringing up the test env (docker copy fails)
            * SIG Cluster Lifecycle is willing to try to support as blocking, but also limited hands and the flake debug is complex.  Lubomir’s preference is to get to bottom of the actual failure and keep it in informing until then.
        * Image management (eg:[ https://github.com/kubernetes/kubernetes/issues/70249](https://github.com/kubernetes/kubernetes/issues/70249),[ https://github.com/kubernetes/kubernetes/issues/75114](https://github.com/kubernetes/kubernetes/issues/75114)  and others) → next rel eng meeting topic
        * CI Signal subproject starting up needs update, relates to 
            * [https://github.com/kubernetes/sig-release/issues/966](https://github.com/kubernetes/sig-release/issues/966)
            * [https://github.com/kubernetes/community/issues/3455](https://github.com/kubernetes/community/issues/3455)
            * [https://github.com/kubernetes/enhancements/pull/1554](https://github.com/kubernetes/enhancements/pull/1554) 
            * [https://github.com/kubernetes/enhancements/issues/1553](https://github.com/kubernetes/enhancements/issues/1553) 
            * [https://github.com/kubernetes/community/issues/3456](https://github.com/kubernetes/community/issues/3456) 
        * Golang related dep management topics:
            * toolchain version:[ https://github.com/kubernetes/release/issues/1139](https://github.com/kubernetes/release/issues/1139)
            * Module deps:[ https://github.com/kubernetes/kubernetes/issues/82531](https://github.com/kubernetes/kubernetes/issues/82531) 

**Open Discussion [timebox to N min]:**



* New Doodle for SIG Release / Releng meeting times:[ https://doodle.com/poll/yp3wrghih6r4td65](https://doodle.com/poll/yp3wrghih6r4td65)
* What qualifies for a milestone, cherry-picking (Taylor) -[ https://github.com/kubernetes/community/pull/4628](https://github.com/kubernetes/community/pull/4628)


## March 9, 2020 ([recording](https://youtu.be/jcZJPvO4AH4))

**Host:** Stephen Augustus

**Note Taker**: Tim Pepper

**Attendees:**



* Taylor Dolezal
* Sascha Grunert
* Rey Lejano
* Marko Mudrinić
* Bart Smykla
* Daniel Mangum
* Tim Pepper
* Jorge Alarcon
* Lubomir Ivanov
* 

**Recurring Topics [timebox to N min]:**



* (if you have any… here are some suggestions)
* Welcome any new members or attendees
* Subproject updates
    * Licensing ([https://github.com/orgs/kubernetes/projects/31](https://github.com/orgs/kubernetes/projects/31))
    * Release Engineering ([https://github.com/orgs/kubernetes/projects/30](https://github.com/orgs/kubernetes/projects/30))
    * Release Team ([https://github.com/orgs/kubernetes/projects/29](https://github.com/orgs/kubernetes/projects/29))
    * Testgrid dashboard review:[ https://testgrid.k8s.io/sig-release](https://testgrid.k8s.io/sig-release) 
    * Project board review:[ https://github.com/orgs/kubernetes/projects/23](https://github.com/orgs/kubernetes/projects/23)

**Open Discussion [timebox to N min]:**



* Establish Kubernetes build/stage/release process on k8s-infra (@bsmykla): 
    * [https://github.com/kubernetes/release/issues/911](https://github.com/kubernetes/release/issues/911)
* Annual support cycle KEP (tpepper):[ https://github.com/kubernetes/enhancements/pull/1497](https://github.com/kubernetes/enhancements/pull/1497)
    * SIG Release has been involved in discussion, but lacking Contrib Summit session at KubeCon EU 2020, WG LTS wants to explicitly reach out again regarding:
    * Are there specific costs/efforts for SIG Release not captured in the proposal?
    * Readiness?  Could this be implementable from SIG Release’s perspective?
        * In Tim St. Clair’s alternate suggestion comment on the KEP, if doing three by four month releases with three releases supported at a time still yielding 12 months of patch support, can we get release team volunteers for 16 weeks instead of the current 12 week commitment?
        * Tools supportability/maintainability complexities:
            * Order of operations
            * Tagging, branching of k/release and related k/* repos
* Removing debian-* images?[ https://github.com/kubernetes/kubernetes/pull/80909](https://github.com/kubernetes/kubernetes/pull/80909)
    * Still looking at this; will probably be a 1.19 endeavor
* Updates on [RFC] CI Signal subproject[ https://github.com/kubernetes/sig-release/issues/966](https://github.com/kubernetes/sig-release/issues/966). What can we do to move forward? (alejandrox1)
    * [Stephen] I need to strip contentious parts of the proposal around scope and have defining scope be the first task of this group


## February 24, 2020 ([recording](https://youtu.be/HsCtsPlQ2Pk))

**Host:** Tim Pepper

**Note Taker**: Bob Killen

**Attendees:**



* Sascha Grunert
* Bob Killen
* Daniel Mangum
* Marko Mudrinić
* Stephen Augustus
* Tim Pepper
* Bart Smykla
* Gianluca Arbezzano
* Jim Angel
* Augustas Verbickas
* Adolfo García Veytia
* Joseph Sandoval
* Marky Jackson

**Recurring Topics [timebox to N min]:**



* (if you have any… here are some suggestions)
* Welcome any new members or attendees
* Subproject updates
    * Licensing ([https://github.com/orgs/kubernetes/projects/31](https://github.com/orgs/kubernetes/projects/31))
        * Potentially looking for new owners / contributors
    * Release Engineering ([https://github.com/orgs/kubernetes/projects/30](https://github.com/orgs/kubernetes/projects/30))
        * [Krel](https://github.com/kubernetes/release/tree/master/cmd/krel)
            * Lots of effort this past cycle
            * Successfully using krel ff.  And also a PR to remove branchff.  Either way, for discussion of why there is an ff, see last week:[ https://kubernetes.slack.com/archives/CJH2GBF7Y/p1582216315166800](https://kubernetes.slack.com/archives/CJH2GBF7Y/p1582216315166800) 
            * Incrementally switching over to krel for more components
            * Right now replicating functionality (bash -> golang) versus enhancing, simplifying, rearchitecting
            * Potentially rename gcbmanager command, it was named gcbmanager to mirror the current command.
            * Gcb components are difficult to mock and test locally.
                * Might render gcbtemplate locally in the future for local cloud build
            * Some of the thoughts on the development of krel and future big picture changes -[ https://docs.google.com/document/d/1Js_36K51Q6AjEsVUjRBMISTA4D7cnjZmoSkn43_Jmxo/edit?usp=sharing](https://docs.google.com/document/d/1Js_36K51Q6AjEsVUjRBMISTA4D7cnjZmoSkn43_Jmxo/edit?usp=sharing)
            * Need to determine “end goal” for krel / tooling
                * Initial goal:
                    * non-googlers being able to publish a release (publishing images, publishing/signing debs/rpms)
                    * More maintainable implementation (more people involved, ability to do local dev/test w/o priv’s, smaller units, units with tests in CI)
            * WG K8s Infra: What are plans from Release which need new/different infra?  When are they needed?  What are the artifacts to be delivered?  Let’s create an issue describing this with a checklist of the 2020 deliverables.  Also these two exist:
                * “Can  we do release on the new infra?”  This is the TOP priority.[ https://github.com/kubernetes/release/issues/911](https://github.com/kubernetes/release/issues/911) ← needs input from WG K8s Infra
                * [https://github.com/kubernetes/release/issues/964](https://github.com/kubernetes/release/issues/964)
        * Release Managers
        * hyperkube
    * Release Team ([https://github.com/orgs/kubernetes/projects/29](https://github.com/orgs/kubernetes/projects/29))
* Testgrid dashboard review:[ https://testgrid.k8s.io/sig-release](https://testgrid.k8s.io/sig-release) 
* Project board review:[ https://github.com/orgs/kubernetes/projects/23](https://github.com/orgs/kubernetes/projects/23)

**Open Discussion [timebox to N min]:**



* KEP Updates for Graduated Enhancements (Jeremy Rickard)
* k/enhancement issues per “stage” (Jeremy Rickard)
    * 1 KEP for the entire lifecycle of the Enhancement
    * Should be addressed by:[ https://github.com/kubernetes/enhancements/pull/1545](https://github.com/kubernetes/enhancements/pull/1545)
* SIG Release related KEPs:[ https://github.com/kubernetes/enhancements/pulls?q=is%3Aopen+is%3Apr+label%3Asig%2Frelease](https://github.com/kubernetes/enhancements/pulls?q=is%3Aopen+is%3Apr+label%3Asig%2Frelease)
    * Plus revisions to the KEP process:[ https://github.com/kubernetes/enhancements/pull/1545](https://github.com/kubernetes/enhancements/pull/1545)
    * Conformance documentation for k8s releases:
        * [https://github.com/kubernetes/enhancements/pull/717](https://github.com/kubernetes/enhancements/pull/717)
        * Stale (1yr+), sig-testing owned
    * Kubeadm split out of k/k:
        * [https://github.com/kubernetes/enhancements/pull/1425](https://github.com/kubernetes/enhancements/pull/1425)
        * Quiet since a month ago, not everybody in sync, but deferred from 1.18 to 1.19
        * What tools changes needed?  Lubomir’s looking at changing the proposal in a way that would not require changes in anago.  Experimenting with tools around branching and tag management.  Need to discuss more with Release to see how this can blend with where krel is going.
        * Dims: are these changes just to make it easier relative to release tooling today?  Or does it represent that way we want things to be for all things that split out of k/k?  We should think broadly about how to support not just core + kubeadm, but core + any of the things we expect to split out.  Need a shared concept of what should be the release tooling architecture.
* 


## February 10, 2020 ([recording](https://youtu.be/yZM4NOsuAJU))

**Host:** Stephen Augustus

**Note Taker**: TBD

**Attendees:**



* Sascha Grunert
* Carlos Panato
* Bob Killen
* Jim Angel
* James Laverack
* Tim Pepper
* Joseph Sandoval
* Taylor Dolezal
* Daniel Mangum
* Bart Smykla
* Marko Mudrinić
* Adolfo García Veytia

**Recurring Topics [timebox to N min]:**



* (if you have any… here are some suggestions)
* Welcome any new members or attendees
* Subproject updates
    * Licensing ([https://github.com/orgs/kubernetes/projects/31](https://github.com/orgs/kubernetes/projects/31))
    * Release Engineering ([https://github.com/orgs/kubernetes/projects/30](https://github.com/orgs/kubernetes/projects/30))
        * Release Managers
        * hyperkube
    * Release Team ([https://github.com/orgs/kubernetes/projects/29](https://github.com/orgs/kubernetes/projects/29))
* Testgrid dashboard review:[ https://testgrid.k8s.io/sig-release](https://testgrid.k8s.io/sig-release) 
* Project board review:[ https://github.com/orgs/kubernetes/projects/23](https://github.com/orgs/kubernetes/projects/23)

**Open Discussion [timebox to N min]:**



* New repo plugins
    * [https://github.com/kubernetes/sig-release/pull/980](https://github.com/kubernetes/sig-release/pull/980)
    * [https://github.com/kubernetes/release/pull/1063](https://github.com/kubernetes/release/pull/1063)
    * [https://github.com/kubernetes/test-infra/pull/16161](https://github.com/kubernetes/test-infra/pull/16161)
* Note on commit messages
* Change to generate updates to[ https://relnotes.k8s.io/](https://relnotes.k8s.io/) as part of the krel tool.[ https://github.com/kubernetes/release/issues/1061](https://github.com/kubernetes/release/issues/1061) @james.laverack, @puerco
* Progress report on krel (Sascha, Daniel) \
[https://github.com/kubernetes/release/issues/918](https://github.com/kubernetes/release/issues/918)
* krel gcbmgr in progress:[ https://github.com/kubernetes/release/pull/1081](https://github.com/kubernetes/release/pull/1081)
* k/k image building (Hannes):[ https://github.com/kubernetes/kubernetes/pull/80909#issuecomment-574230358](https://github.com/kubernetes/kubernetes/pull/80909#issuecomment-574230358)
* Add a 'kind/test' category for release milestone PRs -[ https://github.com/kubernetes/kubernetes/issues/65180](https://github.com/kubernetes/kubernetes/issues/65180) (Bob Killen)
* Rename release-note-* and cherrypick- labels to conform to category/sub-category norm -[ https://github.com/kubernetes/kubernetes/issues/24057](https://github.com/kubernetes/kubernetes/issues/24057) (Bob Killen)
* Add your suggested topic here and move this to the line below [firstname lastname, email or @slackname]


---


## January 27, 2020 ([recording](https://www.youtube.com/watch?v=ChpG7h-nhnA&list=PL69nYSiGNLP3QKkOsDsO6A0Y1rhgP84iZ&index=6&t=0s))

**Host:** Tim Pepper

**Note Taker**: Tim Pepper

**Attendees:**



* Sascha Grunert
* Daniel Mangum
* Hannes Hoerl
* Marko Mudrinić
* Taylor Dolezal
* Jorge Alarcon
* Adolfo García Veytia
* Savitha Raghunathan

**Recurring Topics [timebox to N min]:**



* Subproject updates
    * Licensing: No representative
    * Release Engineering
        * Anago issues Dec./Jan.:
            * Associative array traversed incorrectly, minimally worked around for now.
            * Could simplify the top level control logic in Anago.  Might want to / need to for Kubeadm KEP.  Somewhat prefer not to given complexity to debug, and intent to replace anago ([https://github.com/kubernetes/release/issues/918](https://github.com/kubernetes/release/issues/918)).
        * Kubeadm KEP:
            * [https://github.com/kubernetes/enhancements/pull/1425](https://github.com/kubernetes/enhancements/pull/1425) Please read/comment
            * Could modify Anago to support also branching, tagging, building k/kubeadm
            * Could modify k/k’s build to pull in k/kubeadm, build, output to the expected places; have a job to
        * Package building:
            * When do we start using it?
            * Is getting close to ready
            * Most tools today have presumed github.com/kubernetes, specific repos, and pre-defined taxonomy of branches (master, release-1.YY)
            * How to transfer off anago:
                * Rewrite from scratch?  Easier and cleaner for us.  Hard to know the replacement is truly ready.  This path has much easier testing, but does require having shadow repositories
                * Modify anago piecemeal, eg: remove old changelog generator, call new one.
            * Tagging: today we tag, then build changelog, then commit changelog.  The changelog is not “a part of the release” if we build from the release tag.  Build from HEAD, or some other commit(s) just after the tag?  Change the version tagging scheme?
                *  K/kubeadm repo is looking (see KEP above) to add a prow post-submit job to mirror k/k repo branches and tags, without consideration for build reproducibility.
                * Lubomir proposes not having changelogs in subsidiary repos (eg: kubeadm).  SIG Release’s tool acts as an aggregator, puts changelogs from a list of repos in a single place such as k/k.  This would also give common style to “the Kubernetes project changelog”.
    * Release Team ([https://github.com/orgs/kubernetes/projects/29](https://github.com/orgs/kubernetes/projects/29))
* Testgrid dashboard review:[ https://testgrid.k8s.io/sig-release](https://testgrid.k8s.io/sig-release) 
* Project board review:[ https://github.com/orgs/kubernetes/projects/23](https://github.com/orgs/kubernetes/projects/23)

**Open Discussion [timebox to N min]:**



* Reminder [RFC] CI Signal subproject[ https://github.com/kubernetes/sig-release/issues/966](https://github.com/kubernetes/sig-release/issues/966)


## January 13, 2020 ([recording](https://youtu.be/fCrxWgkZGls))

**Host:** Stephen Augustus

**Note Taker**: TBD

**Attendees:**



* Jorge Alarcon
* Taylor Dolezal
* Marky Jackson
* Bob Killen
* Daniel Mangum
* Hannes Hoerl
* Marko Mudrinić
* Tim Pepper
* Gianluca Arbezzano
* Rey Lejano
* Thomas Wodarek
* Carlos Panato
* Arnaud Meukam
* Josh Berkus 
* John Belamaric
* Maria Ntalla

**Recurring Topics [timebox to N min]:**



* (if you have any… here are some suggestions)
* Welcome any new members or attendees
* Subproject updates
    * Licensing ([https://github.com/orgs/kubernetes/projects/31](https://github.com/orgs/kubernetes/projects/31))
    * Release Engineering ([https://github.com/orgs/kubernetes/projects/30](https://github.com/orgs/kubernetes/projects/30))
        * Release Managers
        * hyperkube
    * Release Team ([https://github.com/orgs/kubernetes/projects/29](https://github.com/orgs/kubernetes/projects/29))
* Testgrid dashboard review:[ https://testgrid.k8s.io/sig-release](https://testgrid.k8s.io/sig-release) 
* Project board review:[ https://github.com/orgs/kubernetes/projects/23](https://github.com/orgs/kubernetes/projects/23)

**Open Discussion [timebox to N min]:**



* New meeting times. Stephen to send Doodle this week.
* 1.18 async grooming. Happening over the next two weeks.
* ContribEx survey:[ https://www.surveymonkey.com/r/VYRJZ5G](https://www.surveymonkey.com/r/VYRJZ5G)
* kubeadm out-of-tree:[ https://github.com/kubernetes/enhancements/pull/1425](https://github.com/kubernetes/enhancements/pull/1425)
* kubepkg (Deb/rpm builder) in alpha:[ https://github.com/kubernetes/release/blob/master/cmd/kubepkg/README.md](https://github.com/kubernetes/release/blob/master/cmd/kubepkg/README.md)
    * Image is already live, but image building PR needs merge:[ https://github.com/kubernetes/test-infra/pull/15871](https://github.com/kubernetes/test-infra/pull/15871)
    * Initial PRs:
        * [https://github.com/kubernetes/release/pull/935](https://github.com/kubernetes/release/pull/935)
        * [https://github.com/kubernetes/release/pull/998](https://github.com/kubernetes/release/pull/998)
* Patch Releases tomorrow:
    * Stephen and Tim to handle to be watching for errors from[ https://github.com/kubernetes/kubernetes/issues/86182](https://github.com/kubernetes/kubernetes/issues/86182) and[ https://github.com/kubernetes/release/issues/968#issuecomment-564792325](https://github.com/kubernetes/release/issues/968#issuecomment-564792325).
        * The build/release code is supposed to do:
            * tag v1.16.3
            * commit openapi-spec versioned files
            * tag v1.16.4-beta.0
        * But it is instead doing:
            * commit openapi-spec versioned files
            * tag v1.16.5-beta.0
            * tag v1.16.4
        * By way of[ https://github.com/kubernetes/kubernetes/pull/84654](https://github.com/kubernetes/kubernetes/pull/84654) (and cherry picks onto each of the release branches), the openapi-spec commit is no longer needed.  At that point it doesn’t matter if the tagging is out of order.
        * We need to remove the build code bash that makes a commit on the openapi-spec.
        * We still need to understand how a sequential, non-parallel series of bash commands is happening in a different order than shown in the code in the repo we think we’re building from.  Is GCB doing something weird?  Are we misunderstanding this bash?
    * Patch releases will be:
        * 1.17.1:[ https://github.com/kubernetes/sig-release/issues/948](https://github.com/kubernetes/sig-release/issues/948)
        * 1.16.5:[ https://github.com/kubernetes/sig-release/issues/949](https://github.com/kubernetes/sig-release/issues/949)
        * 1.15.8:[ https://github.com/kubernetes/sig-release/issues/950](https://github.com/kubernetes/sig-release/issues/950)
        * 1.14.11??  May need to because 1.14.10 was one of the builds that had out of order tagging as[ https://github.com/kubernetes/kubernetes/commit/575467a0eaf3ca1f20eb86215b3bde40a5ae617a](https://github.com/kubernetes/kubernetes/commit/575467a0eaf3ca1f20eb86215b3bde40a5ae617a) was included in the 1.14.10 build marking it as 1.14.11 in the openapi-spec/swagger.json.
    * Issues remain with the “marker files” used by test-infra.  Test configs are relatively static, using a set of “channels” as described in[ https://github.com/kubernetes/test-infra/blob/master/docs/kubernetes-versions.md](https://github.com/kubernetes/test-infra/blob/master/docs/kubernetes-versions.md):
        * <span style="text-decoration:underline;">channel	branch</span>
        * dev		master
        * beta		release-1.15
        * stable1		release-1.14
        * stable2		release-1.13
        * stable3		release-1.12
        * When we drop 1.12, stable3 is marked to refer not to release-1.12, but rather release-1.13.  The release versions rotate relative to the channel marker names.  The tests always use the same channel marker name.  This leads to weird skews in test results where the results of stable3 in testgrid are non-continuous, but testgrid’s heuristic for “green” or “red” does not understand this.  There is some caching and cache invalidation and it does not function correctly relative to how the release versions are rotated, and this very much confuses the task of CI signal analysis
* Creating CI Signal subproject
    * It will soon be time to remove the 1.14 CI, ie:[ https://github.com/kubernetes/test-infra/pull/15875](https://github.com/kubernetes/test-infra/pull/15875)
    * If CI Signal is a subproject we gain more continuity across the year, instead of rotating teams fairly aggressively in each release team.  We can grow the set of folks watching issues to be more than just the smaller set of a lead and shadows in the release team
    * Release team role is still needed as they report status into the release team in order to enable the go / no-go decisions on releasing.
* Tagging/branching (request for comments):[ https://github.com/kubernetes/release/issues/857](https://github.com/kubernetes/release/issues/857)
    * Anago prototype:[ https://github.com/kubernetes/release/pull/957](https://github.com/kubernetes/release/pull/957)
* KubeCon EU SIG Release maintainers track Intro & Deep Dive
    * Attendening Kubecon EU:
        * Marky Jackson
        * Gianluca Arbezzano
        * Josh Berkus
        * Marko Mudrinić
        * Carlos Panato
        * Tim Pepper
        * Stephen Augustus
        * Daniel Mangum
    * SIG Intro: Sascha (and somebody additional?) do details of release tooling and process[ https://docs.google.com/document/d/1M4670sP4PxDi1tRf1AkYGBDvahnKGZekrERneaBDVs0/edit#](https://docs.google.com/document/d/1M4670sP4PxDi1tRf1AkYGBDvahnKGZekrERneaBDVs0/edit#) 
    * SIG Deep Dive: Do a pair of deep dives into two of our subprojects (eg: releng, CI signal), each 15-20 minutes, plus Q&A.
    * Abstracts for these are due by Jan. 20.  Caleb/Tim/Stephen as SIG chairs will collate info from above into specific abstract and speakers proposal then enter them into the conference tool ahead of the deadline.