[LFX] Release Process Rework Overview

[rexagod]

Under the Automate the Release Process LFX listing, here's a verbose description of what the candidate's expectations will entail:

• Drive a proposal that will outline the release process that fits for all sub-projects that come under the SIG, starting with KSM as the initial proof of work.
  • The candidate will need to coordinate with SIG Release during this phase to ensure that the best practices are being followed across our workflows, so that we can leverage existing machinery to the fullest extent.
  • The candidate will need to coordinate with SIG Instrumentation members that maintain other sub-projects and gather their opinion on the proposal (the proposed tooling changes).
• The candidate will need to coordinate with SIG Security, if needed, to ensure we migrate as many workflows as possible to Prow. Any workflows that still rely on GitHub actions should never, directly or indirectly, work with any environment variables whatsoever. Ideally all workflows will need to be migrated to Prow (k/test-infra)
• The candidate will need to track their work product in a GitHub gist.
• Preferably cut a release to get a firsthand experience of how the current release process works.

/assign @Rishab87
cc @mrueg

---

Refer #2711 for the original issue. Current efforts towards this are:

• [LFX] Design Proposal for Automating the Release Process #2756
• chore: Prepare v2.17.0 #2757

[k8s-ci-robot]

@rexagod: GitHub didn't allow me to assign the following users: Rishab87.

Note that only kubernetes members with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time.
For more information please see the contributor guide

In response to this:

Under the Automate the Release Process LFX listing, here's a verbose description of what the candidate's expectations will entail:

• Drive a proposal that will outline the release process that fits for all sub-projects that come under the SIG, starting with KSM as the initial proof of work.
• The candidate will need to coordinate with SIG Release during this phase to ensure that the best practices are being followed across our workflows, so that we can leverage existing machinery to the fullest extent.
• The candidate will need to coordinate with SIG Instrumentation members that maintain other sub-projects and gather their opinion on the proposal (the proposed tooling changes).
• The candidate will need to coordinate with SIG Security, if needed, to ensure we migrate as many workflows as possible to Prow. Any workflows that still rely on GitHub actions should never, directly or indirectly, work with any environment variables whatsoever. Ideally all workflows will need to be migrated to Prow (k/test-infra)
• The candidate will need to track their work product in a GitHub gist.
• Preferably cut a release to get a firsthand experience of how the current release process works.

/assign @Rishab87
cc @mrueg

---

Refer #2711 for the original issue.

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.

[k8s-ci-robot]

This issue is currently awaiting triage.

If kube-state-metrics contributors determine this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

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.