Skip to content

Latest commit

 

History

History
221 lines (186 loc) · 7.76 KB

0001a-meta-kep-implementation.md

File metadata and controls

221 lines (186 loc) · 7.76 KB
Raw
kep-number title authors owning-sig participating-sigs reviewers approvers editor creation-date last-updated status see-also replaces superseded-by
1a
Meta KEP Implementation
@justaugustus
@calebamiles
@jdumars
sig-pm
sig-architecture
@erictune
@idvoretskyi
@spiffxp
@timothysc
@bgrant0607
@jbeda
2018-09-08
2018-09-29
implementable
KEP-1

Meta KEP Implementation

Table of Contents

Summary

Drive KEP adoption through improved process, documentation, visibility, and automation.

Motivation

The KEP process is the standardized structure for proposing changes to the Kubernetes project.

In order to graduate KEPs to GA, we must iterate over the implementation details.

This KEP seeks to define actionable / delegable items to move the process forward.

Finally, by submitting a KEP, we gain an opportunity to dogfood the process and further identify areas for improvement.

Why another KEP?

As KEP-1 is currently de facto for the project, we must be careful to make changes to it in an iterative and atomic fashion.

When proposing a KEP, we action over some unit of work, usually some area of code.

In this instance, we treat KEP-1 as the unit of work. That said, this would be considered a meta-KEP of the meta-KEP.

Non-Goals

  • API Review process
  • Feature request triage
  • Developer guide

Proposal

Implementation Details / Notes / Constraints

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:
├── keps # top-level directory
│   ├── sig-beard # SIG directory
|   |   ├── 9000-beard-implementation-api # KEP directory
|   |   |   ├── kep.md (required) # KEP (multi-release work)
|   |   |   ├── experience_reports (required) # user feedback
|   |   |   │   ├── alpha-feedback.md
|   |   |   │   └── beta-feedback.md
|   |   |   ├── features # units of work that span approximately one release cycle
|   |   |   │   ├── feature-01.md
|   |   |   │   ├── ...
|   |   |   │   └── feature-n.md
|   |   |   ├── guides
|   |   |   |   ├── guide-for-developers.md (required)
|   |   |   |   ├── guide-for-teachers.md (required)
|   |   |   |   ├── guide-for-operators.md (required)
|   |   |   |   └── guide-for-project-maintainers.md
|   |   |   ├── index.json (required) # used for site generation e.g., Hugo
|   |   |   ├── metadata.yaml (required) # used for automation / project tracking
|   |   └── └── OWNERS
│   ├── sig-foo
|   ├── ...
|   └── sig-n

metadata.yaml would contain information that was previously in a KEP's YAML front-matter:

---
authors: # required
  - "calebamiles" # just a GitHub handle for now
  - "jbeda"
title: "Kubernetes Enhancement Proposal process"
number: 42 # required
owning-sig: "sig-pm" # required
participating-sigs:
  - "sig-architecture"
  - "sig-contributor-experience"
approvers: # required
  - "bgrant0607" # just a GitHub handle for now
reviewers:
  - "justaugustus"  # just a GitHub handle for now
  - "jdumars"
editors:
  - null # generally omit empty/null fields
status: "active" # required
github:
  issues:
    - null # GitHub url
  pull_requests:
    - null # GitHub url
  projects:
    - project_id: null
      card_id: null
releases: # required
  - k8s_version: v1.9
    kep_status: "active"
    k8s_status: "alpha" # one of alpha|beta|GA
  - k8s_version: v1.10
    kep_status: "active"
    k8s_status: "alpha"
replaces:
  - kep_location: null
superseded-by:
  - kep_location: null
created: 2018-01-22 # in YYYY-MM-DD
updated: 2018-09-04
  • 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

Constraints

  • Preserve git history
  • Preserve issues
  • Preserve PRs

Graduation Criteria

Throughout implementation, we will be reaching out across the project to SIG leadership, approvers, and reviewers to capture feedback.

While graduation criteria has not strictly been defined at this stage, we will define it in future updates to this KEP.

Implementation History

  • 2018-08-20: (@timothysc) Issue filed about repo separation: kubernetes#2565
  • 2018-08-30: SIG Architecture meeting mentioning the need for a clearer KEP process - https://youtu.be/MMJ-zAR_GbI
  • 2018-09-06: SIG Architecture meeting agreeing to move forward with a KEP process improvement effort to be co-led with SIG PM (@justaugustus / @jdumars) - https://youtu.be/fmlXkN4DJy0
  • 2018-09-10: KEP-1a submitted for review
  • 2018-09-25: Rationale discussion in SIG PM meeting
  • 2018-09-28: Merged as provisional
  • 2018-09-29: KEP implementation started
  • 2018-09-29: KEP Implementation Tracking issue created
  • 2018-09-29: KEP Implementation Tracking board created
  • 2018-09-29: Submitted as implementable