Enhancements: KEP: Enhance the KEP implementation

Created on 29 Sep 2018  路  24Comments  路  Source: kubernetes/enhancements

Kubernetes Enhancement Proposal Implementation

  • One-line feature description (can be used as a release note): A standardized process for describing / presenting / delivering enhancements to the Kubernetes ecosystem
  • Primary contact (assignee): @justaugustus
  • Responsible SIGs:
    /sig pm architecture
  • KEP link(s): KEP-1a, KEP-1
  • Link to e2e and/or unit tests: N/A
  • Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred: @jdumars @calebamiles
  • Approver (likely from SIG/area to which feature belongs): @bgrant0607 @jbeda
  • Feature target (which target equals to which milestone):

    • Beta release target (1.13)

    • Stable release target (1.14 / 1.15 - tentative)

/kind feature
/milestone v1.13

Project tracking board

https://github.com/orgs/kubernetes/projects/5

High-level implementation plan

Define

  • Refine existing KEP documentation
  • Define KEP [DACI]
  • Glossary of terms (enhancement, KEP, feature, etc.)
  • KEP Workflow

    • KEP states

    • Entry / exit criteria

Organize

  • Move KEPs from flat-files to a directory structure:
  • Move existing KEPs into [k/features]
  • Create a kind/kep label for [k/community] and [k/features]

    • For k/community:

    • Label incoming KEPs as kind/kep

    • Enable searches of org:kubernetes label:kind/kep, so we can identify active PRs to k/community and reroute the PR authors to k/enhancements (depending on the state)

    • For k/enhancements (fka k/features):

    • Label incoming KEPs as kind/kep

    • Classify KEP submissions / tracking issues as kind/kep, differentiating them from kind/feature

  • Move existing design proposals into [k/features]
  • Move existing architectural documents into [k/features] (process TBD)
  • Deprecate design proposals
  • Rename [k/features] to [k/enhancements]
  • Create tombstones / redirects to [k/enhancements]
  • Prevent new KEPs and design proposals from landing in [k/community]
  • Remove kind/kep from [k/community] once KEP migration is complete
  • Correlate existing Feature tracking issues with links to KEPs
  • Fix [KEP numbering races] by using the GitHub issue number of the KEP tracking issue
  • Coordination of existing KEPs to use new directory structure (with SIG PM guidance per SIG)

Visibility and Automation

  • Create tooling to:
areenhancements kinfeature kinkep siarchitecture stagbeta trackeout-of-tree
Source
picture justaugustus
👍4

All 24 comments

/assign @justaugustus @calebamiles @jdumars

justaugustus picture justaugustus on 29 Sep 2018

/stage beta

justaugustus picture justaugustus on 29 Sep 2018

...because the label exists now:
/kind kep
:)

justaugustus picture justaugustus on 2 Oct 2018

Why not go all the way and move them to a database? That's pretty clearly where we're eventually going. And it would solve the autonumbering problem.

jberkus picture jberkus on 2 Oct 2018

This sort of falls in-line with trying to use more tooling / programmatically interact with the KEPs better, but there are many small inconsistencies with the current KEPs beyond multiple KEPs using the same number. Some will omit attributes if empty, others will put 'N/A' or TBD. Others will sort of follow their own schema.

For tooling (and the eventual KEP website), having consistently formatted data will make it much easier to display everything correctly. Some of this is enumerated and spelled out in 0001a-meta-kep-implementation.md, but I wanted to include some examples of the inconsistencies encountered so far in attempting to list and sort the KEPs for the WIP contributor site.

Having a clearly defined schema and cleaning up the current data will make working with the information much easier.

mrbobbytables picture mrbobbytables on 24 Oct 2018
❤1

/milestone clear
I'd like for us to consider milestoning keps into something other than v1.14, just so I can keep that milestone focused on enhancements that will land as part of kubernetes. ie: totally fine with a "kep" milestone, or "keps-q1" milestone etc.

spiffxp picture spiffxp on 10 Jan 2019
👍1

We need to think about project capacity and backlog management, also. The reality is that we don't have the capacity to do all worthwhile things at the same time.

https://medium.com/uswitch-labs/proposing-an-enhancement-to-kubernetes-the-story-of-a-kep-f652656d0628

bgrant0607 picture bgrant0607 on 16 Jan 2019

@bgrant0607 -- I've created a project tracking board for this some time ago: https://github.com/orgs/kubernetes/projects/5

We've also identified several PMs in this week's SIG PM call interested in assisting with this effort.

justaugustus picture justaugustus on 16 Jan 2019

@spiffxp -- created keps-beta and keps-ga milestones.
/milestone keps-beta

justaugustus picture justaugustus on 21 Jan 2019

@justaugustus I was referring to the backlog of KEPs in flight (per SIG or per subproject) rather than the backlog for implementing the KEP process.

SIG Arch was maintaining a review backlog manually:
https://github.com/kubernetes-sigs/architecture-tracking/projects/2

I just left a comment on https://github.com/kubernetes/enhancements/issues/619 about this

bgrant0607 picture bgrant0607 on 25 Jan 2019
👍1

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

fejta-bot picture fejta-bot on 29 Apr 2019

/remove-lifecycle stale
/lifecycle frozen

justaugustus picture justaugustus on 17 May 2019

Enhancement issues opened in kubernetes/enhancements should never be marked as frozen.
Enhancement Owners can ensure that enhancements stay fresh by consistently updating their states across release cycles.

/remove-lifecycle frozen

fejta-bot picture fejta-bot on 17 May 2019

Hi @justaugustus, @jdumars, & @calebamiles I'm the 1.16 Enhancement Shadow. Is this feature going to be graduating alpha/beta/stable stages in 1.16? Please let me know so it can be added to the 1.16 Tracking Spreadsheet. If not's graduating, I will remove it from the milestone and change the tracked label.

Once coding begins or if it already has, please list all relevant k/k PRs in this issue so they can be tracked properly.

Milestone dates are Enhancement Freeze 7/30 and Code Freeze 8/29.

Thank you.

rbitia picture rbitia on 12 Jul 2019

Hey @rbitia! No code is landing in k/k. It's tracking a process change, so no need to track this one.

justaugustus picture justaugustus on 30 Jul 2019

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

fejta-bot picture fejta-bot on 28 Oct 2019

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

fejta-bot picture fejta-bot on 27 Nov 2019

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

fejta-bot picture fejta-bot on 27 Dec 2019

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

k8s-ci-robot picture k8s-ci-robot on 27 Dec 2019

Why is this still open? Is there more work?

thockin picture thockin on 7 Feb 2020

Looking over the points, it looks like much of this is done. (Perhaps checkboxes could be clearer)
Would this graduate the KEP process from _beta_?

vbatts picture vbatts on 9 Jun 2020

Hey @vbatts! :)

We've still got some work to do here before I'd consider the process stable:

  • qualify what it means for the process to be stable
  • full validation of KEP metadata
  • a KEP website
  • tooling to support the process

That said, you're right, we should get this issue updated! Will handle.
/unassign @calebamiles @jdumars
/assign @mrbobbytables @jeremyrickard @johnbelamaric

justaugustus picture justaugustus on 10 Jun 2020

Right on!

vbatts picture vbatts on 10 Jun 2020
🚀1

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

fejta-bot picture fejta-bot on 8 Sep 2020
Was this page helpful?
0 / 5 - 0 ratings

Related issues

justinsb picture justinsb  路  11Comments
euank picture euank  路  13Comments
povsister picture povsister  路  5Comments
AndiLi99 picture AndiLi99  路  13Comments
majgis picture majgis  路  5Comments