Changing kubernetes/kubernetes default branch name to main

[justaugustus]

Enhancement Description

• One-line enhancement description (can be used as a release note): Changing kubernetes/kubernetes default branch name to main
• Kubernetes Enhancement Proposal:
• Discussion Link:
  • https://groups.google.com/a/kubernetes.io/g/steering/c/8fy8omuKdpM
  • Changing default branch names to main org#2222
• Primary contact(s) (assignee):
  • @justaugustus
  • @cpanato
• Responsible SIGs: @kubernetes/sig-release-admins @kubernetes/wg-naming
• Enhancement target (which target equals to which milestone):
  • Alpha release target (x.y): v1.24
  • Beta release target (x.y): N/A
  • Stable release target (x.y): N/A
• Alpha
  • KEP (k/enhancements) update PR(s):
  • Code (k/k) update PR(s):
  • Docs (k/website) update PR(s):

Please keep this description up to date. This will help the Enhancement Team to track the evolution of the enhancement efficiently.

[justaugustus]

/assign @justaugustus @cpanato
/sig release
/area release-eng
/wg naming
/milestone v1.24

[liggitt]

What's the downstream impact of tools and processes and developers using the master branch? Will GitHub redirect those automatically or will they all need to be modified?

[cpanato]

when we make the branch rename, all PRs that point to the master branch will be updated automatically to the main branch

for the local dev the users will need to update the branch to point to the new one, GitHub have a page to explain in how to do that https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/renaming-a-branch#updating-a-local-clone-after-a-branch-name-changes

[liggitt]

what about all CI flows, sync flows, and downstream consumers of the kubernetes/kubernetes repo?

[cpanato]

ci/sync flows on our side we will make the changes and we can monitor issues

for downstream consumers will be more tricky, we will communicate the change but not sure how to deal with that

in the GitHub UI when you access the fork GH notifies the branch changed in the upstream, so users can notice that

[liggitt]

for downstream consumers will be more tricky, we will communicate the change but not sure how to deal with that

It's important to understand the scope of that impact for the highest-use repo we have. Is there a way to quantify or survey how much would break on this rename?

[cpanato]

I don't know how we can do that, maybe we can send an announcement to our mailing list and spread the word via social media?
Also, GitHub give some alerting https://github.com/github/renaming

• Show a notice to repository contributors, maintainers, and admins on the repository homepage with instructions to update local copies of the repository
• Show a notice to contributors who git push to the old branch
• Redirect web requests for the old branch name to the new branch name
• Return a "Moved Permanently" response in API requests for the old branch name

[BenTheElder]

Is there a way to quantify or survey how much would break on this rename?

https://github.com/kubernetes/kubernetes/graphs/traffic gives some idea I guess (the git clones metrics), but automation vs manual clones is not clear, and not to which branch etc...

Renaming breaks git workflows that explicitly use master. It's possible to avoid this and detect the default branch but doing so is a bit clunky and not widespread.

For Kubernetes most of our CI jobs are configured such that this requires no changes, because we do the following:

• presubmit and postsubmit configurations exclude release branches, or target a specific release branch, rather than targeting master
• periodic jobs largely consume binary builds from the build job, via GCS, without talking to GitHub at all

A handful of periodic jobs will need upating.

Downstream consumers will need to switch over themselves, but most downstreams are likely consuming release branches / tagged releases, for folks consuming HEAD of master I'd expect most of them to be in our developer mailinglists.

For workflows other than git automation, (inbound web links etc.), github will do a redirect from the renamed branch to the new name anyhow, so nothing should really break there. For manual clones this will just be the new default.

For local existing git clones, you just need to get in the habit of referencing main instead of master.

Shell git aliases can be updated to use one of the detection tricks (we can email out guidance, IIRC @cblecker shared a robust one some time back).

EDIT: we actually provide this in the rename issue repo template kubernetes/kubernetes#105601, https://www.kubernetes.dev/resources/rename/#just-before-rename

[BenTheElder]

Git workflows also could avoid explicitly naming the default branch since a simple git clone will clone and checkout the default branch, we should really update to do this ourselves kubernetes/test-infra#20667 & kubernetes/test-infra#20672

[cpanato]

/remove-lifecycle stale

[cprivitere]

What's holding this up at this point? Should we just rip off the band-aid (with announcements and messaging similar to the switch from k8s.gcr.io to registry.k8s.io)?

I think we've all done a ton of these now and it's really not the end of the world...

[BenTheElder]

What's holding this up at this point? Should we just rip off the band-aid (with announcements and messaging similar to the switch from k8s.gcr.io to registry.k8s.io)?

Bandwidth. Nobody has fleshed out a plan => sent out notices etc.
The previous proposal wasn't widely communicated and didn't include discussion with involved parties e.g. SIG Testing.
An updated proposal needs discussing with the relevant SIGs.

I think we've all done a ton of these now and it's really not the end of the world...

Nobody said it was. But we do have a LOT of things pointed at this repo, particularly CI jobs galore.
There needs to be a little more coordination than our smaller repos (and those are still not done ...).
It's doable, but everyone maintaining the project has a lot to deal with, so issues without an active champion fall on the ever growing backlog.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[neolit123]

/remove-lifecycle rotten
still planned AFAIK

[cpanato]

@neolit123 yes, thanks

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[cpanato]

/remove-lifecycle rotten

[BenTheElder]

Most of the details are #2853 (comment) but this still needs more details worked out, it would probably be good to survey the project's automation for any other gaps and think about what a reasonable timeline would look like.

That said, I think most of the folks contributing to the project's automation really have their hands full with basic patching and preparing to migrate the remainder of it to run under sig-k8s-infra instead of assorted company-internal resources.

I don't think this is all that hard, but it needs a communicated and agreed timeline, and some prep to minimize leaving behind broken CI etc cloning the wrong branch.

Most current CI is already ready, but there's a long tail of barely looked after stuff that is cloning the default of "master" using old scripts and would be broken without preparing to handle that, off the top of my head (bootstrap.py etc) aside from anywhere anyone's explicitly configured to clone from "master".

This repo has a LOT of automated workflows pointed at it. It's too bad github can't handle this as a transparent alias with both names for some period ..?

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle rotten
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle rotten

[k8s-triage-robot]

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue, marking it as "Not Planned".

In response to this:

The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.

This bot triages issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Reopen this issue with /reopen
• Mark this issue as fresh with /remove-lifecycle rotten
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/close not-planned

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.