Move process for creating/removing repos to org owners guide
The process is only meant for org admins so move to that doc and decouple the process from the rules and guidelines for repos, which are meant for everyone.
This commit is contained in:
Nikhita Raghunath
parent
c60fd9d366
commit
61fb3d431d
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -137,7 +137,99 @@ 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 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](#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
|
||||
* 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.
|
||||
|
||||
[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]: #sig-repositories
|
||||
|
|
|
|||
Loading…
Reference in New Issue