First iteration of the Release Hanbook

[kimwnasptd]

This is a first iteration in order to convert and commit the Release Handbook from a Google Doc to markdown https://docs.google.com/document/d/1mDk0lFc_4LHd71N-RZ2AjjZVF_rMou9GJrSaSaWyk5Y/edit. I also added some extra info based on some proposed comments, like further defining the roles in the release team.

Since the release team has been formed and we need to move on with providing the exact time schedule I'd like to put a maximum time cap for the review process of this PR. I think one week is a good limit.

Of course we will continue to iterate on this doc with further PRs, but I want to at least have the first iteration merged quickly so that we can start the release process based on the committed doc.

cc @RFMVasconcelos @DavidSpek @kubeflow/wg-automl-leads @kubeflow/wg-deployment-leads @kubeflow/wg-manifests-leads @kubeflow/wg-notebooks-leads @kubeflow/wg-pipeline-leads @kubeflow/wg-serving-leads @mkbhanda @annajung @castrojo @shannonbradshaw @jbottum @cvenets @theadactyl

[kimwnasptd]

/remove-approve

[DavidSpek]

Thanks for putting in the time and effort to create this document. I have some initial thoughts regarding some sections, but I will write those up in a more detailed review. They are mainly regarding the roles and responsibilities, which is actually what I wanted to discuss in the release team meeting last Monday that was cancelled. We should postpone merging this PR until after it has been discussed in the release team meeting, as I find synchronous discussion is usually more effective than commenting back and forth.

[annajung]

Just leaving a few feedback, not a blocker! thank you for putting this together!

[mkbhanda]

Some edits and clarifications suggested.
Good work @kimwnasptd !

[mkbhanda]

bumping to next major release would violate semantic versioning? Typically a major release carries with it features that might break backwards compatibility

[castrojo]

Just a note to remind ourselves: Are any kubeflow components following semantic versioning? Wondering if this is a project-level issue to file instead of a handbook problem?

[DavidSpek]

This highlights the importance of consensus for the versioning of the Kubeflow components and how that should relate to the (overall) Kubeflow version. If this can be clearly defined, almost the entire release process should be automatable (bump Kubeflow version to X, because component Y was updated to version Z, update manifest repository with new manifests for component Y, etc).

[DavidSpek]

Here are my initial comments related to the People and Roles section.
Also, shouldn't this be Roles and Responsibilities, since no people are actually defined, but rather the different roles and their responsibilities?

[DavidSpek]

We should probably also consider if this handbook should be in the manifest repository, update the existing handbook, or be added to the community repository and have the Roles and Responsibilities section integrate with the existing structure used by the working groups (since it is turning into something closely resembling a working group at this point).

[thesuperzapper]

I think the release guide/handbook should live in kubeflow/community (under a new folder with new OWNERS), untill we inevitably setup a "WG Release", after which it might live in their repo, perhaps: kubeflow/release

[DavidSpek]

Sorry for the late reply, I've had an unexpectedly busy weekend. Here are my remaining comments for the Process and Timeline.

[kimwnasptd]

As I also mentioned in the description I want to have this first iteration merged within this week, and we can further iterate with PRs on the merged document.

Looking at its current state all of the review comments have been addressed and we've opened follow up issues to keep track of interesting discussions that flourished from this review #1922 #1921. If I missed a point please feel free to open an issue about it to further discuss it.

@yanniszark this should conclude our effort with having a first release retrospective and handbook that captures the process and tries to improve it. Feel free to take a look as well and we should be good to merge the first iteration

[yanniszark]

Thank you very much for this effort @kimwnasptd! The document captures a lot of the items we brought up in the retro.

Really looking forward to next steps!
/lgtm
/approve

[yanniszark]

Hmmm for some reason the bot is not picking up

/lgtm
/approve

[google-oss-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: yanniszark

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:

• OWNERS [yanniszark]

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