KEP-2853: Branch rename for k/k

[cpanato]

• One-line PR description: Changing kubernetes/kubernetes default branch name to main

• Issue link: Changing kubernetes/kubernetes default branch name to main #2853

• Other comments:

@saschagrunert @justaugustus @puerco @xmudrii @Verolop
@kubernetes/release-engineering

[saschagrunert]

Thanks for laying out the KEP, I left a few review suggestions 🙏

[justaugustus]

/assign @justaugustus @saschagrunert

[saschagrunert]

Just a few nits, otherwise LGTM :)

[xmudrii]

Have we done any research on how is it going to affect us (speaking of Release Engineering)? For example:

• What changes we might need to do to krel and the release tooling?
• What about the release notes tool?
• What about the version markers (could they be affected by this)?

[cpanato]

What changes we might need to do to krel and the release tooling?
What about the release notes tool?

we will need to update some default const we have to use main, or do some fallback if fail, like try master and if fail go to main, or otherwise

What about the version markers (could they be affected by this)?

regarding this maybe @saschagrunert or @justaugustus can give some opinion, I'm not expert in this topic :(

[saschagrunert]

Any tooling would require to be adapted. So there is a risk we miss some of them, which can be mitigated by grepping with multiple eyes :)

[cpanato]

will add this as a risk and mitigation plans

[xmudrii]

I'm wondering should the survey cover the upstream consumers as well. For example, there might be SIGs and/or projects under kubernetes* orgs that are affected by this change. IMO, we also want to be sure that they can migrate by the start of the v1.25 release cycle. We should also note that the upstream consumers might be affected by the enhancements and code freeze.

[cpanato]

we can as well.
I already did the first check in the jobs that use k/k and update those to support both branches when using the master name.
but in some jobs we will need to update after the change.

however, if a project uses k/k that is not set in a prow job we will need to discover those and while we are doing the survey can be a good time for that :)

[justaugustus]

@cpanato -- Great work here!

Let's merge and iterate over any remaining feedback, since this is still in provisional state.
/lgtm
/approve

That said, consider a shorter file name?

keps/sig-release/2853-kubernetes-kubernetes-repository-branch-rename/README.md --> keps/sig-release/2853-k-core-branch-rename/README.md

/hold if you want to address that now

[cpanato]

did the rename of the directory @justaugustus, PTAL

/hold cancel

[justaugustus]

Thanks again for working on this, Carlos!
/lgtm
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cpanato, justaugustus

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:

• keps/sig-release/OWNERS [cpanato,justaugustus]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[BenTheElder]

In the future I would bring a KEP to participating SIGs before merging it.
This will have impact well beyond SIG Release.

[BenTheElder]

This is an incomplete answer due to periodics. They don’t listen to a branch, only time, but they must explicitly configure a branch to clone. Thankfully many of them consume a CI build instead, but not remotely all of them.