

<table>
  <tr>
   <td>Date:
   </td>
   <td>Dec 18, 2018
   </td>
  </tr>
  <tr>
   <td>Recording
   </td>
   <td>https://youtu.be/WRJw27_QkiI
   </td>
  </tr>
  <tr>
   <td>Attending:
   </td>
   <td>
<ul>

<li> \
Tim Pepper

<li>Aaron Crickenberger

<li>Kendrick Coleman

<li>Josh Berkus

<li>Caleb Miles

<li>Aish Sundar

<li>Benjamin Elder

<li>Davanum Srinivas

<li>Stephen Augustus
</li>
</ul>
   </td>
  </tr>
</table>




*  \
Part #2 of the 1.13 release retrospective:[ https://docs.google.com/document/d/1mKrJm3N4dC4rfOwa5WcvOptmjpteMcNOg1ZSoACKU1g/edit#](https://docs.google.com/document/d/1mKrJm3N4dC4rfOwa5WcvOptmjpteMcNOg1ZSoACKU1g/edit#) 
* Part #1 was[ https://youtu.be/e5oHnmUOz3k?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ](https://youtu.be/e5oHnmUOz3k?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ) 

<table>
  <tr>
   <td>
Date:
   </td>
   <td>Dec 4, 2018
   </td>
  </tr>
  <tr>
   <td>Recording
   </td>
   <td><a href="https://youtu.be/7gnQw8Jd2NA">https://youtu.be/7gnQw8Jd2NA</a> 
   </td>
  </tr>
  <tr>
   <td>Attending:
   </td>
   <td>
<ul>

<li> \
Tim Pepper

<li>Aaron Crickenber  (@spiffxp)

<li>Kendrick Coleman

<li>Hart Hoover

<li>Josh Berkus

<li>Claire Laurence

<li>Nicholas Lane

<li>Caleb Miles
</li>
</ul>
   </td>
  </tr>
</table>




*  \
1.13 anything else to do?
* 1.13 retrospective:
    * Thursday at community meeting.
    * [1.13 Retro doc](https://docs.google.com/document/d/1mKrJm3N4dC4rfOwa5WcvOptmjpteMcNOg1ZSoACKU1g/edit#heading=h.tw06ll716grh) (and[ 1.12 retro doc](https://docs.google.com/document/d/1OgylAYqU0YoJz-PTd8uzyHtMcxYSewSq06AGeh1F-A8/edit#) for reference)
    * Moderator?  Don’t have Jaice confirmed yet. 
        * Jaice can do it, but probably should pass the baton so more people get experience doing this
* 1.13 Changelog, or what is a good changelog in general:
    * [Major Themes](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG-1.13.md#major-themes) section: reads very high level and broad for some SIGs.  Content is delegated to the SIGs, but the overarching doc then needs coherent editorial voice.  The release team relnotes lead needs help (SIG Architecture) help on the “reduce” part following the “map” 
    * Should it refer to commercial offerings in the SIG ${cloud provider name} sections?
    * Steering committee has two bullets in their charter:
        * Decide how and when official releases of Kubernetes artifacts are made and what they include
        * Declare a release, so that the committee can ensure quality/feature/other requirements are met. \
If it's steering who makes these choices (and associated support stance declarations?), some might feel they have insufficient voice, even though Steering is elected by all of us.
    * Aaron will bring up question on changelog content in steering
    * We as a group can discuss in the retro on Thursday
* Test flakes (spiffxp, jberkus):
    * can we do some targeted work in December?
    * Shifting issues from 1.13 milestone to master
    * Umbrella: this is a massive amount of work, plus complex interdepencies and runtime context specific interactions increasing the flake likelihood
    * Specific areas:
        * Upgrade / Downgrade: needs critical mass of the right stakeholders to declare a better test architecture
        * Event passing anti-pattern:[ https://github.com/kubernetes/kubernetes/issues/71646](https://github.com/kubernetes/kubernetes/issues/71646) 
        * 5k node Scale test
        * Numretries: is this hiding flakes?
    * Dashboard: community view into what is flaking, how much, feel the scope of problem.  Partly in[ velodrome/bigquery](http://velodrome.k8s.io/dashboard/db/bigquery-metrics?orgId=1), also[ triage dashboard](https://storage.googleapis.com/k8s-gubernator/triage/index.html), and daily pre-submits.
    * Release blocking criteria: need to improve flakes to make the testgrid board truly reliably release blocking, starting with measurement.
    * Flakiest job, flakiest test are two separate things.
    * Josh & Aaron want a dashboard of flakiness to assess where to prioritize fixing versus replacing
    * Release-master-informing dashboard refining: 5k node?  Serial jobs?
        * [https://github.com/kubernetes/sig-release/issues/347](https://github.com/kubernetes/sig-release/issues/347) 
        * Also[ https://github.com/kubernetes/sig-release/issues/405](https://github.com/kubernetes/sig-release/issues/405)  Why “extra”?
        * Scale testing:  things aren’t progressed far along enough to CNCF to know what tests will be there versus dedicated hardware.  Needs dollars and staffers.  WG K8s Infra is working to move this along, but is at the level of determining things like access controls, moving tooling like gcbmgr, etc.  Not quite at the level of “who’s got a spare 5k node” on which to run tests, but if those are laying around, serial runs on such a cluster could be plumbed in.  See #k8s-infra-team
* Release teams’ shadow selection process (justaugustus, jberkus, tpepper)
    * Status check: drawing up a lightweight process and sample questionnaire.  Finalize to ungate 1.14 shadow selection.
    * Josh: we should go ahead.  Remaining one incompleteness is: too hard to set up forms per role.  Could do a generic questionnaire form, if the role handbooks all have a requirements section.  ToDo during 1.14: add requirements to the role handbooks.  In the meantime, 1.14’s leads have an informal conversation about requirements with prospective shadows.  Send out the survey.
    * Aaron: a good goal is to have a list of easily/readily delegatable tasks
* SIG charter cleanups (chairs ongoing TODO):[ https://github.com/kubernetes/sig-release/issues/378](https://github.com/kubernetes/sig-release/issues/378) 
* Formalization of alpha/beta/stable graduations:
    * Move enhancements tracking to PR based flow instead of issues
    * KEP-like?
    * SIG Architecture oversight sign off?  Something that’s beyond the SIG(s) in question on a SIG(s) focused KEP.  Also need to not be a bottleneck, or inject very late surprises.
    * Release lead should have a simple checklist set of criteria including tests, coverage, stability, key contact individuals, reviewers/approvers.  Too much for the release lead (or enhancements lead) to be able to assess from a KEP that it is genuinely on track.
    * Is 1.14 the release in which to require tracked enhancements have a KEP?  No, not yet.  Need to finalized that more broadly across the org/project, establish criteria.  Implement for 1.15.

<table>
  <tr>
   <td>
Date:
   </td>
   <td>Nov 20, 2018
   </td>
  </tr>
  <tr>
   <td>Recording
   </td>
   <td><a href="https://youtu.be/jmJOczWHFik">https://youtu.be/jmJOczWHFik</a> 
   </td>
  </tr>
  <tr>
   <td>Attending:
   </td>
   <td>
<ul>

<li> \
Tim Pepper

<li>Aaron Crickenberger

<li>Arnaud Meukam

<li>Hannes Hoerl

<li>Hart Hoover

<li>Kendrick Coleman

<li>Cole Wagner

<li>Niko Penteridis

<li>Aish Sundar

<li>Nicholas Lane
</li>
</ul>
   </td>
  </tr>
</table>




* (justaugustus) Updates to SIG leadership
    * [https://github.com/kubernetes/community/pull/2778](https://github.com/kubernetes/community/pull/2778)
* (justaugustus) Review SIG Release charter
    * [https://github.com/kubernetes/sig-release/pull/348](https://github.com/kubernetes/sig-release/pull/348)
    * [https://github.com/kubernetes/community/pull/2919](https://github.com/kubernetes/community/pull/2919)
* (justaugustus) Subproject / WG formation updates
    * RT (release team)
    * Release Engineering
    * PST (project security team)
    * LTS (long term support)
* (justaugustus) Enforce milestone for merge
    * [https://github.com/kubernetes/sig-release/issues/321](https://github.com/kubernetes/sig-release/issues/321) (help wanted)
    * Discussion noted in the issue
    * Two sides:
        * Is this for a gate of what might go in?
        * Is this for post-tracking of what went in?
* (justaugustus) What qualifies for a milestone?
    * [https://github.com/kubernetes/sig-release/issues/320](https://github.com/kubernetes/sig-release/issues/320) (help wanted)
    * We have a loose process, which covers test cases, test health, docs.
    * Declaration of “critical-urgent” during code freeze is sort of intentionally meant to be a discussion between the release team and stakeholder SIGs.
    * Feature branches with demonstrable test can help.
    * Green CI signal is one criteria.
    * Do we have a problem that needs fixing?  Is code missing a milestone due to vague acceptance criteria?  We’re not seeing it as release leads this year.
        * 1.10, 1.11 Josh notes there’s been “a team” that would abuse code freeze.  The team specifically varied each time, so not a clear pattern.  One was a SIG/developers who weren’t paying attention and just straight missed code freeze.
        * 1.12 Tim each SIG was responsible and was on track, and then admitting they were behind, and then all who were behind did make a no-go call
        * 1.13 Aish similar to 1.12.  Most of friction now at code freeze is bug fixes so the question is how critical of a bug fix is it.  Leads are erroring on the side of caution.
* (tpepper) What is supported? PR clarifying supported component version skews and upgrade:[ https://github.com/kubernetes/website/pull/11060](https://github.com/kubernetes/website/pull/11060) 
* (nikopen) Decision making, critical thinking, “rule” malleability and definition of “urgency”
    * How strictly are the role handbooks meant to be followed? Does following handbooks in a word-by-word manner create issues in more nuanced scenarios?
    * Do labels always have a strict definition? Example: the priority label, and its usage across separate cycle stages (precode slush, code freeze etc) 
    * Does the enforcement of an ‘important-soon’ label on code slush offer any benefit? The priority filtering already occurs in code freeze where the merge conditions tighten.
    * How tight are merge conditions in code slush and code freeze? How strict are rules meant to be followed? An example[ being this](https://github.com/kubernetes/kubernetes/pull/71208): fix to a CI flake. Details were not given but intent was clear.
    * To avoid being overly strict in the future, can it be written down that handbooks are meant to be guidelines in order to solve actual problems (i.e. getting new code in a new release) and to not lose track of the actual goals over guidelines.
        * Iterating on role handbooks == GOOD!
        * Do it before and after and during release cycle
        * Good to capture some specific examples:  in release 1.x we worked through issue foo, weighed x/y/z evidence from SIG’s A/BC, decided such and such based on that.
        * “Critical” and “Urgent” are clear and strong words.  Same for “Important” and “Soon”, especially relevant to the other two.  The “Kind” labels also are meant to be clarifying.
        * It does remain subjective often and require conversation.
        * Human conversation 1:1 continues to be our most productive means of getting something done urgently from a responsible SIG.
        * 
* (justaugutus, jberkus and aishs) Discuss 1.14 RT nominations
    * Fill in lead roles[ https://github.com/kubernetes/sig-release/issues/372](https://github.com/kubernetes/sig-release/issues/372)
        * Need especially a candidate
    * Discuss shadow selection proposal -[ https://github.com/kubernetes/sig-release/issues/368](https://github.com/kubernetes/sig-release/issues/368) 
        * This isn’t about having a job interview, rather a conversation with prospective mentees/shadows..have they read the role handbook, do they have questions, is the time commitment something they can afford, are they ready and willing to learn & contribute.  This is necessary to insure a successful mentor/mentee relationship.
        * If we go this route SIG Release wouldn’t be involved in the shadow selection, rather just role lead and the release team lead
        * Need to make sure time commitments across the release cycle are clearly in each role handbook
    * Discuss roles and processes for Patch release team -[ https://github.com/kubernetes/sig-release/issues/369](https://github.com/kubernetes/sig-release/issues/369) 
* Backlog: (tpepper and maybe jberkus) Upgrade test improvement plan:
    * Upgrade issues and test case ambiguity causing continual release friction
    * Forward plan is roughly to drop kube up and cluster/*, move to kubeadm only, assess coverage gaps, improve test coverage, insure skew testing works, version test cases.
    * But this spans SIGs Release, Cluster Lifecycle, and Testing and that means it lacks a clear owner and staffing.
    * Does this merit a WG or subproject so somebody’s name is owning creating a plan and coordinating execution of the plan?  Is it a first task for the proposed (above) Release Engineering subproject/WG?
    * What about downgrade?
    * See also “what is supported” PR:[ https://github.com/kubernetes/website/pull/11060](https://github.com/kubernetes/website/pull/11060) 

<table>
  <tr>
   <td>
Date:
   </td>
   <td>Nov. 6, 2018 (Cancelled. Too many people with conflicts
<p>
Oct 23, 2018 (Cancelled. No agenda and meeting invite has gone missing :/ )
   </td>
  </tr>
  <tr>
   <td>Attending:
   </td>
   <td>N/A
   </td>
  </tr>
</table>



<table>
  <tr>
   <td>Date:
   </td>
   <td>Oct 9, 2018
   </td>
  </tr>
  <tr>
   <td>Attending:
   </td>
   <td>
<ul>

<li> \
Jaice Singer DuMars

<li>Dhawal Yogesh Bhanushali

<li>Kendrick Coleman

<li>Aaron Crickenberger

<li>Aish Sundar

<li>Benjamin Elder

<li>Caleb Miles

<li>Arnaud Meukam
</li>
</ul>
   </td>
  </tr>
</table>




*  \
**POSTPONE**: 2nd portion of 1.12 release retrospective
* Charter draft:[ https://github.com/kubernetes/community/pull/2778](https://github.com/kubernetes/community/pull/2778)
    * Needs issues addressed ~ See PR, perhaps move to collab doc for edits
* Subprojects
    * release team
        * Owning the document of the process
        * OWNERS = release process
        * Each team has latitude to run the release
        * SIG Release as owners of the handbooks (e.g. process), 
    * release engineering and infrastructure/automation improvements
        * 
    * licensing/compliance
        * 
    * Security / Threat Model / Provenance
        * 
    * LTS (or[ WG](https://docs.google.com/document/d/1PWhUhm_a27BoWCGKZ5Bg6bV-DW-N06gIQIbrpwoscck/edit#heading=h.46dch1el9d8c)?): 
        * [https://github.com/kubernetes/community/issues/2720](https://github.com/kubernetes/community/issues/2720)
        * [Doc](https://docs.google.com/document/d/1PWhUhm_a27BoWCGKZ5Bg6bV-DW-N06gIQIbrpwoscck/edit#heading=h.46dch1el9d8c) /[ ppt](https://docs.google.com/presentation/d/1-Z-mUNIs3mUi7AdP1KwoAVNviwKrCoo3lxMb5wzCWbk/edit#slide=id.g338ac0a8b6_0_36) 
        * Proceed with discovery on this
* Release cadence of patch releases -[ https://github.com/kubernetes/sig-release/tree/master/release-team/role-handbooks/patch-release-manager#release-timing](https://github.com/kubernetes/sig-release/tree/master/release-team/role-handbooks/patch-release-manager#release-timing) 
    * Predictability would be helpful here
    * The patch release team….?
* Feature graduation and release guidance for out-of-tree Cloud Provider projects
    * Skip to stable?
    * SIG Cloud Provider / Architecture owns this
* Release-blocking job criteria[ PROPOSAL](https://docs.google.com/document/d/1kCDdmlpTnHPQt5z8JzODdFCc3T2D4MKR53twsDZu20c/edit)
    * 

<table>
  <tr>
   <td>
Date:
   </td>
   <td>Sept 25, 2018
   </td>
  </tr>
  <tr>
   <td>Attending:
   </td>
   <td>
<ul>

<li> \
Arnaud Meukam

<li>Tim Pepper

<li>Jaice Singer DuMars

<li>Kevin Kelani

<li>Aish Sundar

<li>Jim Angel

<li>Kendrick Coleman

<li>Lubomir I. Ivanov

<li>Silvia T. Sandy-Martinez

<li>Chuck Ha

<li>Josh Berkus

<li>Jorge Castro

<li>Dhawal Yogesh Bhanushali

<li>Stephen Augustus

<li>Sebastien Vas
</li>
</ul>
   </td>
  </tr>
</table>




* RPM(s) and DEB(s) for Release Candidates - dims
    * Next meeting
* 1.13 Updates - AishSundar
    * [1.13 timeline ](https://github.com/kubernetes/sig-release/pull/294)
    * 1.12 is wrapping up
    * 1.13 should start 10/1 - fully staffed release team
    * Will adjust the timeline as needed
    * Minding feature fallthrough from 1.12 because of a short timeline
    * 1.13 team - you should have emails/invites
    * 
* SIG sessions for Seattle, Shanghai
    * Shanghai
        * [Intro](https://kccncchina2018english.sched.com/event/FuLM/intro-sig-release-tim-pepper-vmware): Tim Pepper - intro and how to get involved
        * [Deep-dive](https://kccncchina2018english.sched.com/event/FuLi/deep-dive-sig-release-tim-pepper-vmware): Tim Pepper - open discussion of China ecosystem vendors’ needs
    * Seattle
        * [Intro](https://kccna18.sched.com/event/Grbb/intro-release-sig-tim-pepper-vmware-aishwarya-sundar-google) - Tim Pepper & Aish Sundar - intro, how to get involved, panel
        * [Deep-dive](https://kccna18.sched.com/event/GrdX/deep-dive-release-sig-josh-berkus-red-hat-chuck-ha-heptio) - Chuck Ha on build tools.
* SIG Leadership
    * (Stephen / Tim) Revisit Charter
        * Formally define subprojects
            * Release Team
            * Release Engineering
                * Patch Release Team - rotating slot on RT
                * Meta KEP to define tooling
            * Licensing & Compliance
            * Product Security Team
    * Time to rotate leads?

<table>
  <tr>
   <td>
Date:
   </td>
   <td>Sept 11, 2018
   </td>
  </tr>
  <tr>
   <td>Attending:
   </td>
   <td>
<ul>

<li> \
Aaron Crickenberger (@spiffxp)

<li>Aish Sundar

<li>Tim Fogarty

<li>Justin Santa Barbara

<li>Lubomir I. Ivanov

<li>Arnaud Meukam

<li>Morten

<li>Mike Arpaia

<li>Caleb Miles

<li>Kendrick Coleman
</li>
</ul>
   </td>
  </tr>
</table>




* Discuss 1.13 release team nominations ![ https://github.com/kubernetes/sig-release/issues/280#issuecomment-420059544](https://github.com/kubernetes/sig-release/issues/280#issuecomment-420059544)  
    * Possibly cap # of shadows to 4 per role. Specifically for Branch manager role, guidance is to not have >2 shadows.
* [https://github.com/kubernetes/test-infra/issues/9336](https://github.com/kubernetes/test-infra/issues/9336) - turning down misc-mungers and cherrypick-queue instances of mungegithub [spiffxp]
    * Have reached out to existing patch release managers to verify I’ve surveyed their usage of cherry pick related labels and merging
    * We need someone to adopt improving the cherrypick process, IIRC @nikhita and @guineversaenger have expressed interest
* [https://github.com/kubernetes/test-infra/pull/9342](https://github.com/kubernetes/test-infra/pull/9342) - moving all kubernetes repos over to tide [spiffxp]

<table>
  <tr>
   <td>
Date:
   </td>
   <td>Aug 28, 2018
   </td>
  </tr>
  <tr>
   <td>Attending:
   </td>
   <td>
<ul>

<li> \
name1
</li>
</ul>
   </td>
  </tr>
</table>




* Adding sig labels to PRs automatically based on OWNERS files is a thing, but too many OWNERS files don’t have “labels:” section.  Could be good first issue for somebody looking to learn codebase layout and ownership:[ https://github.com/kubernetes/community/issues/1808#issuecomment-410309860](https://github.com/kubernetes/community/issues/1808#issuecomment-410309860) 
* [TimP] Build-and-Publish-Infra-and-Automation:
    * Is this a sub-part of test-infra?
    * How do we work to pull this out more into community managed workflows and code maintenance?  Eg:[ https://github.com/kubernetes/release/issues/591](https://github.com/kubernetes/release/issues/591) backs onto something building from a master branch instead of a release specific branch, but most of us don’t understand what/where this is or how to change it.
    * Could we get to a workflow of build-validate-publish-validate, where we know all the expected artifacts, and have scripts to validate they’re created correctly, and were published correctly? 
* 

<table>
  <tr>
   <td>
Date:
   </td>
   <td>Aug 14, 2018
   </td>
  </tr>
  <tr>
   <td>Attending:
   </td>
   <td>
<ul>

<li> \
No meeting
</li>
</ul>
   </td>
  </tr>
</table>



<table>
  <tr>
   <td>Date:
   </td>
   <td>July 31, 2018
   </td>
  </tr>
  <tr>
   <td>Attending:
   </td>
   <td>
<ul>

<li> \
Jaice Singer DuMars

<li>Kendrick Coleman (1.12 Features Shadow)

<li>Stephen Augustus

<li>Aaron Crickenberger
</li>
</ul>
   </td>
  </tr>
</table>




* SIG Release Charter - Needs to be revamped with new template
    * Link to[ template](https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-charter-template.md)
    * Volunteers needed:
        * Stephen Augustus
        * Tim Pepper
        * Jaice Singer DuMars
        * Aish Sundar 
* Using discuss.kubernetes.io for release announcements - Jorge Castro
    * Currently working on autoingesting k8s releases and changelogs, then autogenerating a post on discuss.k8s.io
        * We can then post to Slack/twitter automatically
        * Submission is currently human gated while we sort out the exact workflow and test usage cases
        * We could remove the burden of handing off -announce list access to each new release lead
        * Contribex (jorge) owes you a fully documented process
* Features process reboots ~ PTAL
    * Why do we need to change this?
        * Current process is too manual and error-prone
        * There is no feature planning process framework
        * Release artifacts outside of GitHub are not traceable or transparent
        * KEPs do not tie cleanly to work delivered
    * Jaice’s[ proposal](https://docs.google.com/document/d/113gnr3tKXv79J0IYHyg6VbQwLfb-sCYGphW4D9dLZ_E/edit#heading=h.wzakwvll8dsp)
    * Stephen’s[ proposal](https://docs.google.com/document/d/169x1nuvBTOvZyU8tx7-aZycsF6HGzluqm41rCXd4Rl4/edit#heading=h.ajp15jfaoupa)
* Revisiting milestone-munger - spiffxp
    * Yes, I’m proposing we stop using it entirely, I can’t tell how we’re measuring its success
    * Or at least identify what parts it’s doing that are actually useful vs. noise
    * [https://github.com/kubernetes/sig-release/issues/243](https://github.com/kubernetes/sig-release/issues/243)
* EOL policy for older release-1.y jobs - spiffxp
    * [https://github.com/kubernetes/sig-release/issues/244](https://github.com/kubernetes/sig-release/issues/244)
* Docs and policy for Milestone-Maintainers membership: 
    * [https://github.com/kubernetes/sig-release/pull/239](https://github.com/kubernetes/sig-release/pull/239)


## Next meeting - TBD

Potential topics (moved here from older[ SIG-Release minutes doc](https://docs.google.com/document/d/1Q6Ux-vsiRuiXhXSkVqGr9FUZifqVGRdCWkzVI1UT4l0))



* SIG-Release intro and deep dives at KubeCon China and North America
* Release process improvements:
    * artifact provenance & signing
    * release process threat model
    * Ability for non-Google employees to be release branch maintainers
    * More documentation details on what metadata feeds what machinery to generate what artifacts
    * add test cases on artifact creation/publication so SIG-Cluster-Lifecycle's not pointing out that some part of the artifacts didn't build/publish correctly
* LTS releases
* Promotion of e2e test to conformance: when should this happen for features that are (or should be) going stable in the current release?  Don’t want it late, because it could cause signal instability or other late surprises.  Don’t want it too early in case the feature slips, but in that case could relegate from conformance back to e2e?


---


<table>
  <tr>
   <td>Date:
   </td>
   <td>June 5, 2018
   </td>
  </tr>
  <tr>
   <td>Attending:
   </td>
   <td>
<ul>

<li> \
Jaice Singer DuMars

<li>Stephen Augustus

<li>Paris Walters

<li>Zach Arnold

<li>Tim Pepper

<li>Kendrick Coleman

<li>Benjamin Elder

<li>Aish Sundar
</li>
</ul>
   </td>
  </tr>
</table>


**AGENDA**:



* SIG Release Charter - Need volunteers
    * Need to create a draft and get it ratified
        * Volunteers: Stephen Augustus, Tim Pepper
        * Open / hold PR in k/community for RFC
    * Move Release Team to a subproject
    * Overlap with SIG-PM and the new features[ planning](https://docs.google.com/document/d/1qi4LKV3W9B5JJ5JLjmAY33jESYAqWMWFyO5bWoYEBDo/edit)/[tracking](https://docs.google.com/document/d/113gnr3tKXv79J0IYHyg6VbQwLfb-sCYGphW4D9dLZ_E/edit#heading=h.wzakwvll8dsp) process
        * Need everything in GH somehow
        * SIGs SHOULD be planning release work more than one release ahead
        * KEPs are great, but not fully implemented yet
        * SIG PM Charter draft PR:[ https://github.com/kubernetes/community/pull/2068](https://github.com/kubernetes/community/pull/2068)
* Release artifact signing and validation
    * Tim Pepper was going to look at this?
    * Threat model:
        * Not an existing model, but would like one
        * Create and collaborate on a draft
        * How do signed artifacts support cluster operator requirements and use cases?
        * How do we connect with Google peeps working on this?  At KubeCon EU Caleb mentioned work underway to remove the requirement that release branch managers be Googlers.  Whatever automation improvements are underway there tie into the overall release threat model and any signing story.
        * Notary /[ TUF](https://theupdateframework.github.io/) could be very helpful?
        * 
* Scalability pre-submits
    * Stabilized from add a month ago
    * Every PR is being scale tested
        * Can these be made blocking?
            * 500 node kubemark would become the slowest test at 1:20:00
        * Catch ~60% of regressions ahead of time
        * 
* Release cadence discussion
    * 3x? 20x? LTS? 
    * 3 + 2 release idea?
        * Need to figure out how to gate release content
    * 
* What release policies are missing?
    * Documentation as a blocker
        * To whom is this controversial?
        * Alpha/Beta features should not be an “out” for docs
        * if in_features == true ; docs_required
        * label for this?
    * Reverts (in greater detail)
        * SIG vs. Release Team
        * Unmaintained/able vs. policy-violating 
        * 
    * Revisit[ requirements](https://github.com/kubernetes/sig-release/blob/master/release-process-documentation/release-team-guides/release-lead.md#skills-and-experience-required) for the Release Lead
        * 
    * Better define requirements for other Release Team roles
        * [CI Signal lead role / tasks outlined a bit here](https://docs.google.com/document/d/1uDVrlzh9gZZukz-GYHWSyOnFW_2lplZ4JgR3D4tV4EA/edit)
    * How are leads actually elected/selected?
        * Nomination -> ratified by the subproject
        * Tim Pepper!
    * ========= Continue Next Meeting ===========
    * Big features (k/features) vs others (k/k)
    * Is there / should there be a “maximum term” for incumbents?
    * Do leads need to be from a different company each time?
    * How do we replace a release lead (or other position) if:
        * They leave/quit/expire
        * The SIG receives complaints, or the person is not performing the required duties
    * Conformance test discussion / coverage as a blocker for features going to Stable each release
        * PR conformance related tasks into a release role
        * Identify few areas / features to increase conformance coverage per release [Aish]


---

Template:


<table>
  <tr>
   <td>Date:
   </td>
   <td>
   </td>
  </tr>
  <tr>
   <td>Attending:
   </td>
   <td>
<ul>

<li>
</li>
</ul>
   </td>
  </tr>
</table>


**AGENDA**:



* Item 1


---

**RECOVERED NOTES**


---


## 27 February 2018

Agenda


## 16 January 2018

Agenda



* @jdumars working on some process improvements
    * sending out a weekly update to kubernetes-dev
    * documenting all release roles
    * would like to see more investment in strategic improvements beyond the release team
* Master upgrades on GCE/GKE need attention
* @calebamiles working to onboard as 1.10 branch manager
* Possibly looking for a replacement SIG colead for @pwittrock
    * No objections from participants to replace @pwittrock with @jdumars
* Need to find earlier time to accommodate europe
    * Possibly move to asynchronous meeting to replace biweekly Zoom meeting