Update l10n branching strategy #13859
Conversation
k8s-ci-robot
added
cncf-cla: yes
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: If they are not already assigned, you can assign the PR to them by writing The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
language/en
|
Deploy preview for kubernetes-io-master-staging ready! Built with commit 72e119a https://deploy-preview-13859--kubernetes-io-master-staging.netlify.com |
|
@zacharysarah It is okay to move the changes in this PR to #13850. I just opened this PR to share my idea. |
| @@ -128,7 +128,7 @@ Localizations must use English files from the most recent release as their sourc | |||
| To find source files for the most recent release: | |||
|
|
|||
| 1. Navigate to the Kubernetes website repository at https://github.com/kubernetes/website. | |||
| 2. Select the `release-1.X` branch for the most recent version. | |||
| 2. Select the most recent localization development branch or open it. Usually a team member of [@kubernetes/sig-docs-l10n-admins] opens the development branch from `master` branch on https://github.com/kubernetes/website. The `master` branch will be merged onto the most recent release branch eventually. See the [branching strategy](#branching-strategy) for more information. | |||
There was a problem hiding this comment.
@gochist This section deals with finding source files in English, so it doesn't make sense to add instructions here about opening a development branch. I think your changes on line 172 👇 make a better place for this sort of expansion.
|
|
||
| Repeat steps 1-4 as needed until the localization is complete. For example, subsequent German development branches would be: `dev-1.12-de.2`, `dev-1.12-de.3`, etc. | ||
|
|
||
| Teams must merge localized content into the same release branch from which the content was sourced. For example, a development branch sourced from {{< release-branch >}} must be based on {{< release-branch >}}. | ||
|
|
||
| An approver must maintain a development branch by keeping it current with its source branch and resolving merge conflicts. The longer a development branch stays open, the more maintenance it typically requires. Consider periodically merging development branches and opening new ones, rather than maintaining one extremely long-running development branch. | ||
|
|
||
| While only approvers can merge pull requests, anyone can open a pull request for a new development branch. No special permissions are required. | ||
| On the beginning of every team milestone, a team member usually opens an issue to update outdated contents by comparing upstream changes between the previous development branch and the current development branch. |
There was a problem hiding this comment.
@gochist Do you have a gist of the script you use for comparison? Would you please provide a link?
There was a problem hiding this comment.
To explain how sig-docs-ko-owners team works in real for #13850
/cc @zacharysarah