diff options
Diffstat (limited to 'github-management')
| -rw-r--r-- | github-management/kubernetes-repositories.md | 98 | ||||
| -rw-r--r-- | github-management/org-owners-guide.md | 93 |
2 files changed, 92 insertions, 99 deletions
diff --git a/github-management/kubernetes-repositories.md b/github-management/kubernetes-repositories.md index 803d9b1c..30e2ca5a 100644 --- a/github-management/kubernetes-repositories.md +++ b/github-management/kubernetes-repositories.md @@ -22,12 +22,8 @@ against the kubernetes/org repo. - [Core Repositories](#core-repositories) * [Goals](#goals-2) * [Rules](#rules-1) -- [Creating Repositories](#creating-repositories) - * [Non-staging repositories](#non-staging-repositories) - * [Staging repositories](#staging-repositories) - [Removing Repositories](#removing-repositories) * [Grounds for removal](#grounds-for-removal) - * [Procedure for removal](#procedure-for-removal) - [FAQ](#faq) ## Associated Repositories @@ -137,64 +133,6 @@ ecosystem. Carries the endorsement of the Kubernetes community. Kubernetes steering committee elections. in the Kubernetes community * Repository must be approved by SIG-Architecture -## Creating Repositories - -### Non-staging repositories - -For non-staging repositories, suggestions on how to create -a new repository are described below. - - * Ensure that the repo creation request has appropriate approvals - as per the rules mentioned above. - * Using the organization and repository name mentioned in the repo creation - request, create a new repo with default GitHub settings. - * Set the description as per the repo creation request. - * Clone the newly created repo locally. - * Copy the latest contents of [kubernetes-template-project] and create an - initial commit with the message *Initial commit from the - kubernetes-template-project*. - * Make the following changes in the next commit: - * If the request references a GitHub team to be listed in the `OWNERS` - file, update the `OWNERS_ALIASES` file to remove the steering-committee - alias and add a new alias for the team with members populated as per the - GitHub team. If the request does not reference a GitHub team, remove the - `OWNERS_ALIASES` file. - * Update the OWNERS file as per the request. If the repo is a - [SIG Repository], add a labels entry for the SIG that the repo belongs to. - * Update the `SECURITY_CONTACTS` file as per the request. Note that aliases - cannot be used in this case so expand the GitHub team, if specified. - * Create a new commit with the message *Update OWNERS, OWNERS_ALIASES and - SECURITY_CONTACTS*. - * Push the new commits directly to the master branch. - * If the repo is a [SIG Repository], add a new topic of the form - `k8s-sig-<sig-name-repo-belongs-to>` using the *Manage Topics* option. - * Create a PR against [kubernetes/org] to add teams as per the [team guidance] - for alloting repo admin and write access. - * Once the above PR is merged and the postsubmit has run, the new GitHub teams - will be created. In the *Collaborators and Teams* section in Settings, - assign the new teams appropriate access to the repo. - * Ask the author of the repo creation request to add the repo - as a part of a subproject in [`sigs.yaml`](/sigs.yaml). - -### Staging Repositories - -If the repository is a staging repository, there are some deviations -from the above procedure: - - * The repository **must** have an initial empty commit. The contents of the - repo will be populated from staging by the [publishing-bot]. - * Grant the [@kubernetes/stage-bots] team admin access to the repo. - * Setup branch protection and enable access to the - `stage-bots` team by adding the repo in - [`prow/config.yaml`](https://git.k8s.io/test-infra/prow/config.yaml). See - [kubernetes/test-infra#9292](https://github.com/kubernetes/test-infra/pull/9292) - for an example. - * Once the repo has been created, add the repo to - [`hack/fetch-all-latest-and-push.sh`](https://git.k8s.io/publishing-bot/hack/fetch-all-latest-and-push.sh) - in the [publishing-bot] repo. - -<!-- TODO: Add suggestions for how to migrate existing repos --> - ## Removing Repositories As important as it is to add new repositories, it is equally important to prune @@ -223,31 +161,6 @@ Associated repositories are much more loosely associated with the Kubernetes project and are generally not subject to removal, except under exceptional circumstances (e.g. a code of conduct violation). -### Procedure for removal - -When a repository has been deemed eligible for removal, we take the following -steps: - - * Ownership of the repo is transferred to the [kubernetes-retired] GitHub - organization - * The repo description is edited to start with the phrase "[EOL]" - * All open issues and PRs are closed - * All external collaborators are removed - * All webhooks, apps, integrations or services are removed - * GitHub Pages are disabled - * The repo is marked as archived using [GitHub's archive feature] - * Remove all teams associated with the repo - * Remove the repo from [sigs.yaml] - * The removal is announced on the kubernetes-dev mailing list and community - meeting - -This maintains the complete record of issues, PRs and other contributions, -leaves the repository read-only, and makes it clear that the repository should -be considered retired and unmaintained. - -In case a repository has only the initial commits adding template files -and no additional activity, it can be completely deleted. - ## FAQ **My project is currently in kubernetes-incubator, what is going to happen to @@ -306,14 +219,3 @@ owned by the authors of Kubernetes. Note that you should _never_ modify or remove a third party's copyright notice if you are not authorized by them to do so. - -[GitHub's archive feature]: -https://help.github.com/articles/archiving-a-github-repository/ -[kubernetes-retired]: https://github.com/kubernetes-retired -[kubernetes-template-project]: https://github.com/kubernetes/kubernetes-template-project -[kubernetes/org]: https://github.com/kubernetes/org -[team guidance]: /github-management/org-owners-guide.md#team-guidance -[SIG Repository]: #sig-repositories -[publishing-bot]: https://github.com/kubernetes/publishing-bot -[@kubernetes/stage-bots]: https://github.com/orgs/kubernetes/teams/stage-bots -[sigs.yaml]: /sigs.yaml diff --git a/github-management/org-owners-guide.md b/github-management/org-owners-guide.md index 476c71f5..eec4c38c 100644 --- a/github-management/org-owners-guide.md +++ b/github-management/org-owners-guide.md @@ -41,7 +41,8 @@ managed by the Kubernetes project or use a different name. Due to licensing and CLA issues, prior to transferring software into a Kubernetes managed organization there is some due diligence that needs to occur. -Please contact the steering committee and CNCF prior to moving any code in. +If needed, please contact the steering committee and CNCF prior to moving any +code in. It is easier to start new code in a Kubernetes organization than it is to transfer in existing code. @@ -137,7 +138,97 @@ checking on all contributions. For more details on those please see the Project](https://github.com/kubernetes/kubernetes-template-project), and the [Repository Guidelines](kubernetes-repositories.md) +The process for creating and removing new repositories is detailed below. + +### Creating Repositories + +#### Non-staging repositories + +For non-staging repositories, suggestions on how to create +a new repository are described below. + + * Ensure that the repo creation request has appropriate approvals + as per the rules mentioned above. + * Using the organization and repository name mentioned in the repo creation + request, create a new repo with: + * `Repository Template` as `kubernetes/kubernetes-template-project` + * `Description` as mentioned in the repo creation request + * Clone the newly created repo locally. + * Make the following changes: + * If the request references a team to be listed in the `OWNERS` + file, update the `OWNERS_ALIASES` file to remove the steering-committee + alias and add a new alias for the team with members populated as per the + GitHub team. If the request does not reference a team, remove the + `OWNERS_ALIASES` file. + * Update the OWNERS file as per the request. If the repo is a + [SIG Repository], add a labels entry for the SIG that the repo belongs to. + * Update the `SECURITY_CONTACTS` file as per the request. Note that aliases + cannot be used in this case so expand the team, if specified. + * Create a new commit with the message *Update OWNERS, OWNERS_ALIASES and + SECURITY_CONTACTS*. + * Push the new commit directly to the master branch. + * If the repo is a [SIG Repository], add a new topic of the form + `k8s-sig-<sig-name-repo-belongs-to>` using the *Manage Topics* option. + * Create a PR against [kubernetes/org] to add teams as per the [team guidance](#team-guidance) + for alloting repo admin and write access. + * Once the above PR is merged and the postsubmit has run, the new GitHub teams + will be created. In the *Collaborators and Teams* section in Settings, + assign the new teams appropriate access to the repo. + * Ask the author of the repo creation request to add the repo + as a part of a subproject in [`sigs.yaml`](/sigs.yaml). + +#### Staging Repositories + +If the repository is a staging repository, there are some deviations +from the above procedure: + + * The repository **must** have an initial empty commit. The contents of the + repo will be populated from staging by the [publishing-bot]. + * Grant the [@kubernetes/stage-bots] team admin access to the repo. + * Setup branch protection and enable access to the + `stage-bots` team by adding the repo in + [`prow/config.yaml`](https://git.k8s.io/test-infra/prow/config.yaml). See + [kubernetes/test-infra#9292](https://github.com/kubernetes/test-infra/pull/9292) + for an example. + * Once the repo has been created, add the repo to + [`hack/fetch-all-latest-and-push.sh`](https://git.k8s.io/publishing-bot/hack/fetch-all-latest-and-push.sh) + in the [publishing-bot] repo. + +<!-- TODO: Add suggestions for how to migrate existing repos --> + +### Removing Repositories + +When a repository has been deemed eligible for removal, we take the following +steps: + + * Ownership of the repo is transferred to the [kubernetes-retired] GitHub + organization + * The repo description is edited to start with the phrase "[EOL]" + * All open issues and PRs are closed + * All external collaborators are removed + * All webhooks, apps, integrations or services are removed + * GitHub Pages are disabled + * Remove all teams associated with the repo + * The repo is marked as archived using [GitHub's archive feature] + * Remove the repo from [sigs.yaml] + * The removal is announced on the kubernetes-dev mailing list and community + meeting + +This maintains the complete record of issues, PRs and other contributions, +leaves the repository read-only, and makes it clear that the repository should +be considered retired and unmaintained. + +In case a repository has only the initial commits adding template files +and no additional activity, it can be completely deleted. + [GitHub Administration Team]: /github-management/README.md#github-administration-team +[GitHub's archive feature]: +https://help.github.com/articles/archiving-a-github-repository/ [@kubernetes/owners]: https://github.com/orgs/kubernetes/teams/owners [kubernetes/org]: https://github.com/kubernetes/org +[publishing-bot]: https://github.com/kubernetes/publishing-bot +[@kubernetes/stage-bots]: https://github.com/orgs/kubernetes/teams/stage-bots +[kubernetes-retired]: https://github.com/kubernetes-retired +[kubernetes-template-project]: https://github.com/kubernetes/kubernetes-template-project +[SIG Repository]: /github-management/kubernetes-repositories.md##sig-repositories |