/lgtm
/hold for any more reviewsers if needed!

/lgtm

with Stepehen's changes.

/lgtm
/approve

Let's set a lazy consensus timeout for Thursday, May 21, EOD US ET.

/lgtm
from SIG Testing assuming either outcome of the retroactive support question

If we're trying to go by the letter of the law, this needs Graduation Criteria and a tracking issue to make the Enhancements Freeze cut tomorrow.

If we're being squishy about this, I'd rather leave it open until lazy consensus for "are we extending this retroactively for 1.16" and update the Implementation History accordingly

I'm not entirely happy with having to choose between the squish and the letter, but want to note there's discussion of possible policy clarification for this type of non-feature KEP case over in #1783 "KEP Types: Feature vs Policy vs ???".

FWIW I suspect there's some amount of work that's going to be done as part of this release cycle to implement this policy, regardless of whether it's docs updates for 1.19-going-forward, and/or retroactive work to support 1.16 longer than assumed.

So I think the letter of the law fits here.

The tracking issue is already open here thanks to @youngnick:
#1498

What are folks thoughts on what a "graduation criteria" should be for a binary-mostly (we're doing it / we're not doing it) enhancement? @spiffxp is more needed than what is written in the KEP currently and focused on declaring an consensus for 1.19 and forward (https://github.com/kubernetes/enhancements/tree/master/keps/sig-release/1498-kubernetes-yearly-support-period#graduation-criteria)?

This does leave explicitly as a parallel discussion the question of whether "implementable" can also be true for 1.16/1.17/1.18. To me the separation feels reasonable in case the discussion of that bogs down, so we could still move forward with the 1.19 milestoned issue and KEP while still finalizing the actual shape of implementation for 1.16/1.17/1.18. Am I making things too complicated?

I expect "Graduation Criteria" are "some version has 13ish months of support and has all the bits (extra skew tests, etc.)"

My understanding of what you said, @tpepper, is that you think we should merge this as implementable, making 1.19 the first release to officially get a year of support, and then decide if we extend backwards (keeping in mind that the changed release schedule thanks to coronavirus will mean that three releases ~= a year or so anyway).

That sounds pretty good to me.

@spiffxp @jberkus does https://github.com/kubernetes/enhancements/blob/b4723b0dfeb0615f68fd31f4c25a19b1ddba4940/keps/sig-release/1498-kubernetes-yearly-support-period/README.md#graduation-criteria better capture what you're expecting for Graduation Criteria statement?

/lgtm

/lgtm

publicly documented to have a year of patch support

Yes, I think that's what I was looking for, thank you

/lgtm

Echoing my ML approval for both 1.19 and the retroactive 1.16, 1.17, and 1.18 support expansion.

(That note was also an exception request to the @kubernetes/release-team.)

/lgtm
/approve

/lgtm

The latest push includes clarifying text based on k-dev discussion around support.

Also based on that discussion it appears there is lazy consensus that the KEP is implementable, as drafted for the 1.19 milestone. But there are remaining details to sort out, especially around dependency management policy to potentially resolve concerns for retroactively giving longer support to 1.18, 1.17, and 1.16.

@tpepper -- Some minor nits, but the overall plan LGTM.

I believe each of these was addressed. Can you re-confirm?

This is ready to merge, implementable for 1.19, with the retroactive discussion to continue.
/lgtm
/approve
/hold cancel

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: justaugustus, tpepper

The full list of commands accepted by this bot can be found here.

The pull request process is described here