From db01d9c43bbf768867452c84264d111f8e512cab Mon Sep 17 00:00:00 2001 From: Nikhita Raghunath Date: Thu, 1 Oct 2020 12:51:45 +0530 Subject: Move incubator.md from root to archive --- archive/incubator.md | 160 +++++++++++++++++++++++++++++++++++++++++++++++++++ incubator.md | 160 --------------------------------------------------- 2 files changed, 160 insertions(+), 160 deletions(-) create mode 100644 archive/incubator.md delete mode 100644 incubator.md diff --git a/archive/incubator.md b/archive/incubator.md new file mode 100644 index 00000000..750ff0de --- /dev/null +++ b/archive/incubator.md @@ -0,0 +1,160 @@ +# IMPORTANT - The Kubernetes Incubator process is now deprecated and has been superseded by Kubernetes subprojects + +For information on creating a repository for a subproject see: [kubernetes-repositories](/github-management/kubernetes-repositories.md) + +Each SIG should define the process for sponsoring new subprojects in its charter. For information on SIG governance +and charters see: [SIG governance](committee-steering/governance/README.md) + +# Kubernetes Incubator Process + +**Authors:** Brandon Philips , Sarah Novotny , Brian Grant + +## Kubernetes Incubator + +The [Kubernetes Incubator](https://github.com/kubernetes-incubator) is where all new Kubernetes projects should start. Once going through the incubation process explained in this doc they can become full Kubernetes Community Projects. The process is designed to ensure that new projects have correct licensing, up-to-date boilerplate documents, a healthy community process, and are developed using accepted Kubernetes Community practices. + +### Context + +New Kubernetes projects are getting added in an ad-hoc manner leading to confusion; see [this thread as an example](https://groups.google.com/forum/#!topic/kubernetes-dev/o6E1u-orDK8). + +### Status
 + +This process is light on legalese, completely untested, and only works if people act as good neighbors and community members. It will evolve over time and the authors will try keeping the process light, fast, and objective. + +## Does my project need to Incubate? + +### Existing Code in Kubernetes + +New Kubernetes Community Projects can be created by pulling out code from the Kubernetes main repo (except contrib/). For example, the OWNERS of `k8s.io/kubernetes/pkg/cloudprovider/providers/aws` want to start a new project so they can iterate and release faster than k8s itself. To do this the OWNERS of that package can directly graduate to a Kubernetes Community Project with agreement of the existing package OWNERS, agreement of the parent package (e.g. `k8s.io/kubernetes/pkg/cloudprovider`), and an announcement to kubernetes-dev@googlegroups.com. + +### Applications on top of Kubernetes + +If you are building an Open Source application on top of Kubernetes that is unrelated to the development, operation, monitoring, APIs, lifecycle, integration, or other primary concerns of the Kubernetes project there is no reason to become a Kubernetes project. If you are unsure that your project is a good fit try running it by a few Kubernetes Special Interest Groups or kubernetes-dev@googlegroups.com. + +## Entering Incubation + +To create a new project for incubation you must follow these steps: write a proposal, find a champion, gain acceptance into a SIG, and finally get approval of a Sponsor. The Sponsor and Champion cannot be the same person. + +Your proposal should include two items. First, a README which outlines the problem to be solved, an example use case as-if the project existed, and a rough roadmap with timelines. Second, an OWNERS file that outlines the makeup of the initial team developing the project. Initially this can be one person but ideally has 3 or more initial developers representing a few different companies or groups. You can use whatever tool you want to host and revise the proposal until the project is accepted to the Incubator: copy/paste from your text editor, Google Docs, GitHub gist, etc. + +Once the proposal is written you should identify a champion; this person must be listed as either a reviewer or approver in an [OWNERS file](https://git.k8s.io/kubernetes/OWNERS) in the Kubernetes project. Next, reach out to your potential champion via email to ask if they are interested in helping you through the Incubation process. Ideally some significant follow-up discussion happens via email, calls, or chat to improve the proposal before announcing it to the wider community. + +The next discussion should be on a relevant Special Interest Group mailing list. You should post the proposal to the SIG mailing list and wait for discussion for a few days. Iterate on the proposal as needed and if there is rough consensus that the project belongs in the chosen SIG then list that SIG in the proposal README. If consensus isn't reached then identify another SIG and try again; repeat until a SIG is identified. + +The final process is to email kubernetes-dev@googlegroups.com to announce your intention to form a new Incubator project. Include your entire proposal in the body of the email and prefix the Subject with [Incubator]. Include links to your discussion on the accepted SIG mailing list to guide the discussion. + +Acceptance of the project into the Kubernetes Incubator happens once a Sponsor approves. Anyone listed as an approver in the top-level pkg [OWNERS file](https://git.k8s.io/kubernetes/pkg/OWNERS) can sponsor a project by replying to the kubernetes-dev discussion with LGTM. + +## Creation of the Incubator Project + +Once your project is accepted someone will create a new GitHub repo for your project to use in the [kubernetes-incubator](https://github.com/kubernetes-incubator) organization. The first order of business is to add the following files to the repo: + +- a README from the accepted proposal +- an OWNERS from the accepted proposal +- a CONTRIBUTING file based on kubernetes/kubernetes +- a code-of-conduct.md based on kubernetes/code-of-conduct.md +- a LICENSE file with the Apache 2.0 license +- a RELEASE.md file that talks about the process for releases + +To start your project with these files can be found here at [template project](https://github.com/kubernetes/kubernetes-template-project) + +## Exiting Incubation + +An Incubator Project must exit 12 months from the date of acceptance in one of these three ways: + +- Graduate as a new Kubernetes Project +- Merge with another Kubernetes Project +- Retirement + +### Graduation + +Both time and traction are required to graduate to becoming a new Kubernetes Community Project. It is expected that from the time that your project is accepted to a request for graduation the following criteria are met: + +- **Documented users:** the project tracks evidence from downloads, mailing lists, Twitter, blogs, GitHub issues, etc that the project has gained a user base +- **Regular releases:** the project is making releases at least once every 3 months; although release should happen more often +- **Incubation time:** a minimum of 6 months has passed since +- **Healthy community:** a healthy number of users, contributors, and/or OWNERS outside of your own company have participated in the project. The Sponsor and Champion can make this call. +- **Roadmap:** A roadmap for the next release is maintained; this can be in the form of a doc, GitHub milestones, or any other tool but it must be documented in the README + +When the OWNERS of the Incubator project determine they have met the criteria to graduate they should contact their Champion and Sponsor to discuss. If both the Sponsor and Champion agree that the above criteria have been met the project can graduate to become a Kubernetes Community Project and exit the Kubernetes Incubator. + +An announcement of graduation must be sent to the kubernetes-dev@googlegroups.com mailing list by the Champion. + +### Merge + +At any point during Incubation a project can exit by merging the project with another Incubator Project or Kubernetes Community Project. The process to merge includes: + +1. Incubator Project OWNERS notifying the project Champion and Sponsor +2. Once the Champion and Sponsor have been informed then email kubernetes-dev@googlegroups.com about the intention to exit through a merge + +### Retirement + +If a project doesn't merge or graduate within 12 months it is retired. If a project fails to make a release for 6 months it is retired. Retired repos are moved to the github.com/kubernetes-incubator-retired organization. A warning email will be sent 3 weeks before the move to all people listed in the root OWNERS file, the Champion, and the Sponsor. A project can be re-incubated after retirement but must go through the process of Incubation Entry from the beginning, the same as any new project. + +## FAQ + +**Q: What is the role of a Champion?** + +**A:** Potential Champions come from the set of all Kubernetes approvers and reviewers with the hope that they will be able to teach the Incubator Project about Kubernetes community norms and processes. The Champion is the primary point of contact for the Incubator Project team; and will help guide the team through the process. The majority of the mentorship, review, and advice will come from the Champion. Being a Champion is a significant amount of work and active participation in the sponsored project is encouraged. + +**Q: What is the role of the Sponsor?** + +**A:** Potential Sponsors come from the very small set of Kubernetes contributors that can approve any PR because they are listed as approvers in the `kubernetes/pkg` OWNERS file or the top-level OWNERS file. The idea is that by relying on this small set of Kubernetes Community members to make a determination on Incubator projects we will ensure that there is consistency around new projects joining the Incubator. Being a Sponsor is a minor advisory role. + +## Existing Repos + +Based on the above process there are a number of repos under github.com/kubernetes we should handle through either grandfathering, a move to incubation, or retirement. This list is a rough draft, if you feel strongly about something being miscategorized please comment. + +**Projects to Make "Kubernetes Community Projects"** + +These are grandfathered in as full projects: + +- Kubernetes +- Heapster +- cAdvisor (in-progress move to github.com/kubernetes) +- github.com/kubernetes/kubernetes.github.io +- github.com/kubernetes/test-infra +- github.com/kubernetes/community +- github.com/kubernetes/release +- github.com/kubernetes/features +- github.com/kubernetes/kube-state-metrics +- github.com/kubernetes/pr-bot - move from mungebot, etc from contrib, currently running in "prod" on github.com/kubernetes +- github.com/kubernetes/dashboard +- github.com/kubernetes/helm (Graduated from incubator on Feb 2017) +- github.com/kubernetes/minikube (Graduated from incubator on Feb 2017) +- github.com/kubernetes/kops (Graduated from incubator in Jun 2017) + +**Project to Incubate But Not Move** + +These projects are young but have significant user facing docs pointing at their current github.com/kubernetes location. Lets put them through incubation process but leave them at github.com/kubernetes. + +- github.com/kubernetes/charts + +**Projects to Move to Incubator** + +- github.com/kubernetes/kube2consul +- github.com/kubernetes/frakti +- github.com/kubernetes/application-images +- github.com/kubernetes/rktlet +- github.com/kubernetes/horizontal-self-scaler +- github.com/kubernetes/node-problem-detector +- github.com/kubernetes/kubernetes/contrib/mesos -> github.com/kubernetes-incubator/kube-mesos-framework + +**Projects to Retire** + +- github.com/kubernetes/kube-ui +- github.com/kubernetes/contrib - new projects could be created from the code in this repo, issue to move +- github.com/kubernetes/kubedash +- github.com/kubernetes/kubernetes-docs-cn +- github.com/kubernetes/md-check + +## Thank You + +Large portions of this process and prose are inspired by the Apache Incubator process. + +## Original Discussion +https://groups.google.com/d/msg/kubernetes-dev/o6E1u-orDK8/SAqal_CeCgAJ + +## Future Work + +- Expanding potential sources of champions outside of Kubernetes main repo diff --git a/incubator.md b/incubator.md deleted file mode 100644 index 750ff0de..00000000 --- a/incubator.md +++ /dev/null @@ -1,160 +0,0 @@ -# IMPORTANT - The Kubernetes Incubator process is now deprecated and has been superseded by Kubernetes subprojects - -For information on creating a repository for a subproject see: [kubernetes-repositories](/github-management/kubernetes-repositories.md) - -Each SIG should define the process for sponsoring new subprojects in its charter. For information on SIG governance -and charters see: [SIG governance](committee-steering/governance/README.md) - -# Kubernetes Incubator Process - -**Authors:** Brandon Philips , Sarah Novotny , Brian Grant - -## Kubernetes Incubator - -The [Kubernetes Incubator](https://github.com/kubernetes-incubator) is where all new Kubernetes projects should start. Once going through the incubation process explained in this doc they can become full Kubernetes Community Projects. The process is designed to ensure that new projects have correct licensing, up-to-date boilerplate documents, a healthy community process, and are developed using accepted Kubernetes Community practices. - -### Context - -New Kubernetes projects are getting added in an ad-hoc manner leading to confusion; see [this thread as an example](https://groups.google.com/forum/#!topic/kubernetes-dev/o6E1u-orDK8). - -### Status
 - -This process is light on legalese, completely untested, and only works if people act as good neighbors and community members. It will evolve over time and the authors will try keeping the process light, fast, and objective. - -## Does my project need to Incubate? - -### Existing Code in Kubernetes - -New Kubernetes Community Projects can be created by pulling out code from the Kubernetes main repo (except contrib/). For example, the OWNERS of `k8s.io/kubernetes/pkg/cloudprovider/providers/aws` want to start a new project so they can iterate and release faster than k8s itself. To do this the OWNERS of that package can directly graduate to a Kubernetes Community Project with agreement of the existing package OWNERS, agreement of the parent package (e.g. `k8s.io/kubernetes/pkg/cloudprovider`), and an announcement to kubernetes-dev@googlegroups.com. - -### Applications on top of Kubernetes - -If you are building an Open Source application on top of Kubernetes that is unrelated to the development, operation, monitoring, APIs, lifecycle, integration, or other primary concerns of the Kubernetes project there is no reason to become a Kubernetes project. If you are unsure that your project is a good fit try running it by a few Kubernetes Special Interest Groups or kubernetes-dev@googlegroups.com. - -## Entering Incubation - -To create a new project for incubation you must follow these steps: write a proposal, find a champion, gain acceptance into a SIG, and finally get approval of a Sponsor. The Sponsor and Champion cannot be the same person. - -Your proposal should include two items. First, a README which outlines the problem to be solved, an example use case as-if the project existed, and a rough roadmap with timelines. Second, an OWNERS file that outlines the makeup of the initial team developing the project. Initially this can be one person but ideally has 3 or more initial developers representing a few different companies or groups. You can use whatever tool you want to host and revise the proposal until the project is accepted to the Incubator: copy/paste from your text editor, Google Docs, GitHub gist, etc. - -Once the proposal is written you should identify a champion; this person must be listed as either a reviewer or approver in an [OWNERS file](https://git.k8s.io/kubernetes/OWNERS) in the Kubernetes project. Next, reach out to your potential champion via email to ask if they are interested in helping you through the Incubation process. Ideally some significant follow-up discussion happens via email, calls, or chat to improve the proposal before announcing it to the wider community. - -The next discussion should be on a relevant Special Interest Group mailing list. You should post the proposal to the SIG mailing list and wait for discussion for a few days. Iterate on the proposal as needed and if there is rough consensus that the project belongs in the chosen SIG then list that SIG in the proposal README. If consensus isn't reached then identify another SIG and try again; repeat until a SIG is identified. - -The final process is to email kubernetes-dev@googlegroups.com to announce your intention to form a new Incubator project. Include your entire proposal in the body of the email and prefix the Subject with [Incubator]. Include links to your discussion on the accepted SIG mailing list to guide the discussion. - -Acceptance of the project into the Kubernetes Incubator happens once a Sponsor approves. Anyone listed as an approver in the top-level pkg [OWNERS file](https://git.k8s.io/kubernetes/pkg/OWNERS) can sponsor a project by replying to the kubernetes-dev discussion with LGTM. - -## Creation of the Incubator Project - -Once your project is accepted someone will create a new GitHub repo for your project to use in the [kubernetes-incubator](https://github.com/kubernetes-incubator) organization. The first order of business is to add the following files to the repo: - -- a README from the accepted proposal -- an OWNERS from the accepted proposal -- a CONTRIBUTING file based on kubernetes/kubernetes -- a code-of-conduct.md based on kubernetes/code-of-conduct.md -- a LICENSE file with the Apache 2.0 license -- a RELEASE.md file that talks about the process for releases - -To start your project with these files can be found here at [template project](https://github.com/kubernetes/kubernetes-template-project) - -## Exiting Incubation - -An Incubator Project must exit 12 months from the date of acceptance in one of these three ways: - -- Graduate as a new Kubernetes Project -- Merge with another Kubernetes Project -- Retirement - -### Graduation - -Both time and traction are required to graduate to becoming a new Kubernetes Community Project. It is expected that from the time that your project is accepted to a request for graduation the following criteria are met: - -- **Documented users:** the project tracks evidence from downloads, mailing lists, Twitter, blogs, GitHub issues, etc that the project has gained a user base -- **Regular releases:** the project is making releases at least once every 3 months; although release should happen more often -- **Incubation time:** a minimum of 6 months has passed since -- **Healthy community:** a healthy number of users, contributors, and/or OWNERS outside of your own company have participated in the project. The Sponsor and Champion can make this call. -- **Roadmap:** A roadmap for the next release is maintained; this can be in the form of a doc, GitHub milestones, or any other tool but it must be documented in the README - -When the OWNERS of the Incubator project determine they have met the criteria to graduate they should contact their Champion and Sponsor to discuss. If both the Sponsor and Champion agree that the above criteria have been met the project can graduate to become a Kubernetes Community Project and exit the Kubernetes Incubator. - -An announcement of graduation must be sent to the kubernetes-dev@googlegroups.com mailing list by the Champion. - -### Merge - -At any point during Incubation a project can exit by merging the project with another Incubator Project or Kubernetes Community Project. The process to merge includes: - -1. Incubator Project OWNERS notifying the project Champion and Sponsor -2. Once the Champion and Sponsor have been informed then email kubernetes-dev@googlegroups.com about the intention to exit through a merge - -### Retirement - -If a project doesn't merge or graduate within 12 months it is retired. If a project fails to make a release for 6 months it is retired. Retired repos are moved to the github.com/kubernetes-incubator-retired organization. A warning email will be sent 3 weeks before the move to all people listed in the root OWNERS file, the Champion, and the Sponsor. A project can be re-incubated after retirement but must go through the process of Incubation Entry from the beginning, the same as any new project. - -## FAQ - -**Q: What is the role of a Champion?** - -**A:** Potential Champions come from the set of all Kubernetes approvers and reviewers with the hope that they will be able to teach the Incubator Project about Kubernetes community norms and processes. The Champion is the primary point of contact for the Incubator Project team; and will help guide the team through the process. The majority of the mentorship, review, and advice will come from the Champion. Being a Champion is a significant amount of work and active participation in the sponsored project is encouraged. - -**Q: What is the role of the Sponsor?** - -**A:** Potential Sponsors come from the very small set of Kubernetes contributors that can approve any PR because they are listed as approvers in the `kubernetes/pkg` OWNERS file or the top-level OWNERS file. The idea is that by relying on this small set of Kubernetes Community members to make a determination on Incubator projects we will ensure that there is consistency around new projects joining the Incubator. Being a Sponsor is a minor advisory role. - -## Existing Repos - -Based on the above process there are a number of repos under github.com/kubernetes we should handle through either grandfathering, a move to incubation, or retirement. This list is a rough draft, if you feel strongly about something being miscategorized please comment. - -**Projects to Make "Kubernetes Community Projects"** - -These are grandfathered in as full projects: - -- Kubernetes -- Heapster -- cAdvisor (in-progress move to github.com/kubernetes) -- github.com/kubernetes/kubernetes.github.io -- github.com/kubernetes/test-infra -- github.com/kubernetes/community -- github.com/kubernetes/release -- github.com/kubernetes/features -- github.com/kubernetes/kube-state-metrics -- github.com/kubernetes/pr-bot - move from mungebot, etc from contrib, currently running in "prod" on github.com/kubernetes -- github.com/kubernetes/dashboard -- github.com/kubernetes/helm (Graduated from incubator on Feb 2017) -- github.com/kubernetes/minikube (Graduated from incubator on Feb 2017) -- github.com/kubernetes/kops (Graduated from incubator in Jun 2017) - -**Project to Incubate But Not Move** - -These projects are young but have significant user facing docs pointing at their current github.com/kubernetes location. Lets put them through incubation process but leave them at github.com/kubernetes. - -- github.com/kubernetes/charts - -**Projects to Move to Incubator** - -- github.com/kubernetes/kube2consul -- github.com/kubernetes/frakti -- github.com/kubernetes/application-images -- github.com/kubernetes/rktlet -- github.com/kubernetes/horizontal-self-scaler -- github.com/kubernetes/node-problem-detector -- github.com/kubernetes/kubernetes/contrib/mesos -> github.com/kubernetes-incubator/kube-mesos-framework - -**Projects to Retire** - -- github.com/kubernetes/kube-ui -- github.com/kubernetes/contrib - new projects could be created from the code in this repo, issue to move -- github.com/kubernetes/kubedash -- github.com/kubernetes/kubernetes-docs-cn -- github.com/kubernetes/md-check - -## Thank You - -Large portions of this process and prose are inspired by the Apache Incubator process. - -## Original Discussion -https://groups.google.com/d/msg/kubernetes-dev/o6E1u-orDK8/SAqal_CeCgAJ - -## Future Work - -- Expanding potential sources of champions outside of Kubernetes main repo -- cgit v1.2.3 From c23c61872559400107e0863600ecf898841299ea Mon Sep 17 00:00:00 2001 From: Nikhita Raghunath Date: Thu, 1 Oct 2020 12:53:23 +0530 Subject: Remove references to kubernetes-incubator Since the kubernetes-incubator org has now been retired, this commit removes references to the org from our docs. Note that this commit does NOT remove references in the following docs: * design proposals * meeting notes * docs/notes from old events --- .../devel/sig-node/container-runtime-interface.md | 8 ++++---- github-management/README.md | 2 +- github-management/kubernetes-repositories.md | 19 ------------------- github-management/new-membership-procedure.md | 2 +- github-management/org-owners-guide.md | 3 --- sig-cluster-lifecycle/README.md | 5 ----- sig-instrumentation/charter.md | 4 ++-- sig-service-catalog/charter.md | 16 ++++++++-------- sigs.yaml | 5 ----- 9 files changed, 16 insertions(+), 48 deletions(-) diff --git a/contributors/devel/sig-node/container-runtime-interface.md b/contributors/devel/sig-node/container-runtime-interface.md index 3941c942..38881da5 100644 --- a/contributors/devel/sig-node/container-runtime-interface.md +++ b/contributors/devel/sig-node/container-runtime-interface.md @@ -58,12 +58,12 @@ proposals. We are working on adding more documentation for the API. - [Exec/attach/port-forward streaming requests](https://docs.google.com/document/d/1OE_QoInPlVCK9rMAx9aybRmgFiVjHpJCHI9LrfdNM_s/edit?usp=sharing) - [Container stdout/stderr logs](https://github.com/kubernetes/kubernetes/blob/release-1.5/docs/proposals/kubelet-cri-logging.md) -## Work-In-Progress CRI runtimes +## CRI runtimes - - [cri-o](https://github.com/kubernetes-incubator/cri-o) - - [rktlet](https://github.com/kubernetes-incubator/rktlet) + - [cri-o](https://github.com/cri-o/cri-o) + - [rktlet](https://github.com/kubernetes-retired/rktlet) - [frakti](https://github.com/kubernetes/frakti) - - [cri-containerd](https://github.com/kubernetes-incubator/cri-containerd) + - [cri-containerd](https://github.com/containerd/cri) - [singularity-cri](https://github.com/sylabs/singularity-cri) ## [Status update](#status-update) diff --git a/github-management/README.md b/github-management/README.md index 8ccb566b..ba5024e2 100644 --- a/github-management/README.md +++ b/github-management/README.md @@ -72,7 +72,6 @@ project | [kubernetes](https://github.com/kubernetes) | Core | | [kubernetes-client](https://github.com/kubernetes-client) | API Client Libraries | | [kubernetes-csi](https://github.com/kubernetes-csi) | Container Storage Interface Components | -| [kubernetes-incubator](https://github.com/kubernetes-incubator) | Legacy Incubator Projects | | [kubernetes-retired](https://github.com/kubernetes-retired) | Retired/Archived Projects | | [kubernetes-security](https://github.com/kubernetes-security) | Private Security Fix Mirror | | [kubernetes-sigs](https://github.com/kubernetes-sigs) | SIG-related Projects | @@ -86,6 +85,7 @@ project | [kubernetes-extensions](https://github.com/kubernetes-extensions) | | | [kubernetes-federation](https://github.com/kubernetes-federation) | | | [kubernetes-graveyard](https://github.com/kubernetes-graveyard) | kubernetes-retired should be used instead going forward | +| [kubernetes-incubator](https://github.com/kubernetes-incubator) | Earlier used for legacy incubator projects | | [kubernetes-incubator-retired](https://github.com/kubernetes-incubator-retired) | kubernetes-retired should be used instead going forward | | [kubernetes-providers](https://github.com/kubernetes-providers) | | | [kubernetes-sidecars](https://github.com/kubernetes-sidecars) | | diff --git a/github-management/kubernetes-repositories.md b/github-management/kubernetes-repositories.md index c6b074f4..e326bc11 100644 --- a/github-management/kubernetes-repositories.md +++ b/github-management/kubernetes-repositories.md @@ -164,25 +164,6 @@ circumstances (e.g. a code of conduct violation). ## FAQ -**My project is currently in kubernetes-incubator, what is going to happen to -it?** - -Nothing. We’ll grandfather existing projects and they can stay in the incubator -org for as long as they want to. We expect/hope that most projects will either -move out to ecosystem, or into SIG or Core repositories following the same -approval process described below. - -**My project wants to graduate from incubator, how can it do that?** - -Either approval from a SIG to graduate to a SIG repository, or approval from -SIG-Architecture to graduate into the core repository. - -**My incubator project wants to go GA, how can it do that?** - -For now, the project determines if and when it is GA. For the future, we may -define a cross Kubernetes notion of GA for core and sig repositories, but that’s -not in this proposal. - **My project is currently in core, but doesn’t seem to fit these guidelines, what’s going to happen?** diff --git a/github-management/new-membership-procedure.md b/github-management/new-membership-procedure.md index f48f1df0..ce844d1c 100644 --- a/github-management/new-membership-procedure.md +++ b/github-management/new-membership-procedure.md @@ -47,7 +47,7 @@ required to be eligible to sponsor a new member. These requirements are: - Sponsors must be a member of the org they are attempting to sponsor for. - For example, if the membership being requested is for kubernetes-incubator, + For example, if the membership being requested is for kubernetes-sigs, then the sponsor should be a member of either that org, or main Kubernetes org (as members of the main org have implicit membership in other orgs). diff --git a/github-management/org-owners-guide.md b/github-management/org-owners-guide.md index 272c7cea..ea284b52 100644 --- a/github-management/org-owners-guide.md +++ b/github-management/org-owners-guide.md @@ -75,9 +75,6 @@ for all orgs going forward. Notable discrepancies at the moment: `kubernetes-sig-foo-pr-reviews` teams and are intended mostly as a fallback notification mechanism when requested reviewers are being unresponsive. Ideally OWNERS files can be used in lieu of these teams. -- `admins-foo` and `maintainers-foo` teams as used by the kubernetes-incubator - org. This was a mistake that swapped the usual convention, and we would like - to rename the team ### Structure and Process diff --git a/sig-cluster-lifecycle/README.md b/sig-cluster-lifecycle/README.md index 21c0995d..c07fd08c 100644 --- a/sig-cluster-lifecycle/README.md +++ b/sig-cluster-lifecycle/README.md @@ -139,11 +139,6 @@ The following [subprojects][subproject-definition] are owned by sig-cluster-life - **Meetings:** - kops Office Hours: [Fridays at 09:00 PT (Pacific Time)](https://zoom.us/j/97072789944?pwd=VVlUR3dhN2h5TEFQZHZTVVd4SnJUdz09) (biweekly). [Convert to your timezone](http://www.thetimezoneconverter.com/?t=09:00&tz=PT%20%28Pacific%20Time%29). - [Meeting notes and Agenda](https://docs.google.com/document/d/12QkyL0FkNbWPcLFxxRGSPt_tNPBHbmni3YLY-lHny7E/edit). -### kube-aws -- **Owners:** - - https://raw.githubusercontent.com/kubernetes-incubator/kube-aws/master/OWNERS -- **Contact:** - - Slack: [#kube-aws](https://kubernetes.slack.com/messages/kube-aws) ### kube-up - **Owners:** - https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/OWNERS diff --git a/sig-instrumentation/charter.md b/sig-instrumentation/charter.md index 2de868be..45602991 100644 --- a/sig-instrumentation/charter.md +++ b/sig-instrumentation/charter.md @@ -28,8 +28,8 @@ APIs). [List of subprojects](https://github.com/kubernetes/community/tree/master/sig-instrumentation#subprojects) -- Components required for any Kubernetes cluster in regards to observability. Also referred to as the [core metrics pipeline][core-metrics-pipeline], meaning metrics that are to be consumed by the scheduler, kubectl and autoscaling. ([kubernetes-incubator/metrics-server](https://github.com/kubernetes-incubator/metrics-server), [kubernetes/heapster](https://github.com/kubernetes/heapster)) -- Interfaces/API definitions required for any Kubernetes cluster in regards to observability. These the APIs defined in order to interface external system (such as Prometheus, Stackdriver, etc.) to be exposed to Kubernetes as a common interface, in order for Kubernetes to be able to treat metric sources as a generic metrics API. ([kubernetes/metrics](https://github.com/kubernetes/metrics), [kubernetes-incubator/custom-metrics-apiserver](https://github.com/kubernetes-incubator/custom-metrics-apiserver)) +- Components required for any Kubernetes cluster in regards to observability. Also referred to as the [core metrics pipeline][core-metrics-pipeline], meaning metrics that are to be consumed by the scheduler, kubectl and autoscaling. ([kubernetes-sigs/metrics-server](https://github.com/kubernetes-sigs/metrics-server), [kubernetes/heapster](https://github.com/kubernetes/heapster)) +- Interfaces/API definitions required for any Kubernetes cluster in regards to observability. These the APIs defined in order to interface external system (such as Prometheus, Stackdriver, etc.) to be exposed to Kubernetes as a common interface, in order for Kubernetes to be able to treat metric sources as a generic metrics API. ([kubernetes/metrics](https://github.com/kubernetes/metrics), [kubernetes-sigs/custom-metrics-apiserver](https://github.com/kubernetes-sigs/custom-metrics-apiserver)) - Well established but optional components or adapters for Kubernetes clusters, if endorsed by members. Each component must have two or more members as maintainers. ([kubernetes/kube-state-metrics](https://github.com/kubernetes/kube-state-metrics), not yet officially owned by SIG-Instrumentation, but an example prospect for this category: [DirectXMan12/k8s-prometheus-adapter](https://github.com/DirectXMan12/k8s-prometheus-adapter)) #### Cross-cutting and Externally Facing Processes diff --git a/sig-service-catalog/charter.md b/sig-service-catalog/charter.md index 6ecd0dfe..39852e24 100644 --- a/sig-service-catalog/charter.md +++ b/sig-service-catalog/charter.md @@ -25,8 +25,8 @@ This SIG’s main goals are: ### Code, Binaries and services -- [Source Repository](https://github.com/kubernetes-incubator/service-catalog) - - See [OWNERS](https://raw.githubusercontent.com/kubernetes-incubator/service-catalog/master/OWNERS) for who has access. +- [Source Repository](https://github.com/kubernetes-sigs/service-catalog) + - See [OWNERS](https://raw.githubusercontent.com/kubernetes-sigs/service-catalog/master/OWNERS) for who has access. - [Image Repository](https://quay.io/organization/kubernetes-service-catalog) - Canary builds are published on pushes to master. - Release builds (and latest) are published on tags. @@ -44,7 +44,7 @@ This SIG’s main goals are: - Files hosted on Azure blob storage. - Azure account managed by Carolyn Van Slyck (Microsoft) and Aaron Schlesinger (Microsoft). -- [Travis](https://travis-ci.org/kubernetes-incubator/service-catalog) +- [Travis](https://travis-ci.org/kubernetes-sigs/service-catalog) - Runs the CI builds. - Maintainers have access. - [Jenkins](https://service-catalog-jenkins.appspot.com/) @@ -61,7 +61,7 @@ This SIG's charter deviates from the [sig-governance](https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md) roles. We do not have the Tech Lead role, and have a honorary Emeritus Chair role. -- [Maintainers](https://github.com/orgs/kubernetes-incubator/teams/maintainers-service-catalog/members) +- [Maintainers](https://github.com/orgs/kubernetes-sigs/teams/service-catalog-maintainers/members) - Maintainer is equivalent to the standard [Kubernetes definition of Approver](https://github.com/kubernetes/community/blob/master/community-membership.md#approver). - Responsible for reviewing pull requests, and approving pull requests for merge. @@ -115,7 +115,7 @@ roles. We do not have the Tech Lead role, and have a honorary Emeritus Chair rol - Must accept and adhere to the Kubernetes [Embargo Policy](https://git.k8s.io/security/private-distributors-list.md#embargo-policy). - Defined in - [SECURITY_CONTACTS](https://github.com/kubernetes-incubator/service-catalog/blob/master/SECURITY_CONTACTS) + [SECURITY_CONTACTS](https://github.com/kubernetes-sigs/service-catalog/blob/master/SECURITY_CONTACTS) file. ## Organizational management @@ -129,7 +129,7 @@ roles. We do not have the Tech Lead role, and have a honorary Emeritus Chair rol reports, deep dives, etc.) should make their slides available for perusal and feedback at least 2 week in advance. - [Working - groups](https://github.com/kubernetes-incubator/service-catalog/wiki/Working-Groups) + groups](https://github.com/kubernetes-sigs/service-catalog/wiki/Working-Groups) can be initiated by any member. To create a new one, add the topic to the weekly call’s agenda for discussion. - These are not the same as cross-SIG working groups. @@ -137,7 +137,7 @@ roles. We do not have the Tech Lead role, and have a honorary Emeritus Chair rol members can meet to discuss and solve problems for our SIG. ### Project management -- [Milestones](https://github.com/kubernetes-incubator/service-catalog/milestones) +- [Milestones](https://github.com/kubernetes-sigs/service-catalog/milestones) are defined by SIG maintainers. - Anyone is free to request a discussion of the milestones/plans during a weekly call. @@ -147,7 +147,7 @@ roles. We do not have the Tech Lead role, and have a honorary Emeritus Chair rol - Major releases are planned and discussed among the SIG members during regular weekly calls. - The release process is defined - [here](https://github.com/kubernetes-incubator/service-catalog/wiki/Release-Process). + [here](https://github.com/kubernetes-sigs/service-catalog/wiki/Release-Process). - Anyone can request to work on an issue by commenting on it with `#dibs`. diff --git a/sigs.yaml b/sigs.yaml index 8de385bd..15d78a59 100644 --- a/sigs.yaml +++ b/sigs.yaml @@ -1024,11 +1024,6 @@ sigs: frequency: biweekly url: https://zoom.us/j/97072789944?pwd=VVlUR3dhN2h5TEFQZHZTVVd4SnJUdz09 archive_url: https://docs.google.com/document/d/12QkyL0FkNbWPcLFxxRGSPt_tNPBHbmni3YLY-lHny7E/edit - - name: kube-aws - contact: - slack: kube-aws - owners: - - https://raw.githubusercontent.com/kubernetes-incubator/kube-aws/master/OWNERS - name: kube-up owners: - https://raw.githubusercontent.com/kubernetes/kubernetes/master/cluster/OWNERS -- cgit v1.2.3