kubearmor-community Release Maker (RM) role

[nyrahul]

KubeArmor release cycle is roughly 1 month i.e., every 1 month we intend to release a new version.
Creating a new version requires one to identify if all the issues and PRs in the corresponding version milestones are handled.
Someone needs to followup with individual PR owners and reviewers about finishing their work.
Secondly, the release process has to be followed that involves creating a new branch, and updating the STABLE-RELEASE if needed.
This process demands a role in the community.

This issue defines what that role would entail. The role would be called as a Release Maker (RM) role.

Who can be an RM?

• The role can be handled by anyone who is versed with the kubearmor development process and has atleast one merged PR to their name.
• Typically, the maintainers of the project can wear this hat.
• The hat should be rotated. The person who wears this hat can be decided in the biweekly community meeting.
• The person needs to understand the kubearmor version/branching/release strategy.

When is the RM identified?

• A release typically takes a month or more. A RM must be assigned couple of weeks before the actual release is made.

Responsibilities of an RM

• Check the release milestone and identify all the PRs and issues that could make it as part of the milestone.
• Remove an issue or PR that cannot be handled in the release milestone.
• Connect to PR owners and check if the review comments can be handled in time for the release to make. Raise a red flag on community slack channel if there is a risk about specific PR. Re-request reviews where necessary.
• Identify tests that have to be manually handled. Not all the tests are automated in CI due to cost reasons. In some cases, we might have PRs that might impact the execution in specific managed clusters (for e.g., GKE, EKS) and we do not have automated tests today to handle it. Such tests needs to be identified, a separate issue needs to be created for that release and tracked to closure before the release is upgraded to STABLE-RELEASE.
• Handle the release flow
  • create a new branch
  • update the STABLE-RELEASE if necessary
• Getting the version release blog prepared (check sample)

[nyrahul]

Closing the issue since this process is now stabilized over a period of months involving several releases.