Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve the handbook with feedback from the 1.4 Release Retro #537

Closed
wants to merge 5 commits into from
Closed

Improve the handbook with feedback from the 1.4 Release Retro #537

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
bab59eb
handbook: Add concrete step for tracking issue
kimwnasptd Nov 22, 2021
8de526e
handbook: Add more details to the timeline table
kimwnasptd Nov 22, 2021
de54466
handbook: Features PR should have docs PRs
kimwnasptd Nov 22, 2021
7c5b6cc
handbook: Add release selection process
kimwnasptd Nov 22, 2021
7cf0dd9
git: Add a gitignore file for vim
kimwnasptd Nov 22, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 7 additions & 0 deletions releases/.gitignore
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,7 @@
# vim
[._]*.s[a-v][a-z]
!*.svg # comment out if you don't need vector files
[._]*.sw[a-p]
[._]s[a-rt-v][a-z]
[._]ss[a-gi-z]
[._]sw[a-p]
66 changes: 44 additions & 22 deletions releases/handbook.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -155,26 +155,25 @@ The manifests repo will be following the release process below:


## Timeline

| Week | Events |
| --- | --- |
| 1 | Development |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| 10 | |
| 11 | Feature Freeze, Documentation |
| 12 | |
| 13 | Manifests testing week |
| 14 | Distributions testing |
| 15 | |
| 16 | |
| 17 | Release |
| **Week** | **Who** | **What** |
| -------- | ------- | -------- |
| Week 0 | Release Manager | [Preparation](#preparation) |
| Week 1 | Release Manager | Start of Release Cycle |
| Week 1 | Community | [Development](#development-10-weeks) |
| Week 10 | Release Team | [Feature Freeze](#feature-freeze-2-weeks) |
| Week 10 | Manifest WG | [rc.0 Released](#feature-freeze-2-weeks) |
| Week 10 | Docs Lead | [Documentation](#documentation) |
| Week 10 | Manifest WG | [rc.1 Released](#feature-freeze-2-weeks) |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

According to the handbook, I believe rc.1 is released 2 weeks after the feature freeze?

I think rc.1 should happen in week 12 since there is a schedule for rc.0 during week 10 already.

Copy link
Member Author

@kimwnasptd kimwnasptd Nov 23, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice catch! Yes you are right, it should happen on week 12 which is before the Manifests Testing starts.

I think I'll need to rephrase this sentence in the Feature Freeze (handbook)

On the last day of feature freeze, cut a new vX.Y-rc.1 RC tag on the vX.Y-branch release branch.

To make it clear that:

  1. Feature Freeze does not stop at that time, it continues through the subsequent phases
  2. We cut the RC1 because we are preparing for Manifests Testing, and not because Feature Freeze stops [which doesn't happen]. We want the Manifests leads to use an RC before they start their testing

WDYT?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh and also I think we'll need to fix the week 10 -> week 12 in this one as well
https://github.com/kubeflow/community/tree/master/releases/release-1.5#timeline

I'll push a commit with this as well

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds good!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe https://github.com/kubeflow/community/tree/master/releases/release-1.5#timeline will be fixed with #538.

| Week 12 | Release Team | [Manifests Testing](#manifests-testing-1-week) |
| Week 13 | Docs Lead | End of [Documentation](#documentation) |
| Week 13 | Release Team | End of [Manifests Testing](#manifests-testing-1-week) |
| Week 13 | Manifest WG | [rc.2 Released](#manifests-testing-1-week) |
| Week 14 | Release Team and Distribution Representative | [Distribution Testing](#distribution-testing-3-weeks) |
| Week 17 | Release Team and Distribution Representative | End of [Distribution Testing](#distribution-testing-3-weeks) |
| Week 17 | Manifest WG | (optional) [rc.3 Released](#distribution-testing-3-weeks) |
| Week 17 | Release Team | [Release Day](#release) |
| Week 17 | Release Team | Publish Release Blog |
| TBD | Community | Release Retrospective |


### Preparation
Expand All @@ -194,15 +193,38 @@ Criteria for timeline that the team needs to consider
- Kubecon dates - let’s not hard block on events, but keep them in mind since we know community members might get doublebooked.
- Associated events (aka. AI Day at Kubecon, Tensorflow events) - we want to keep them in mind.

**Success Criteria:** Release team selected, schedule sent to kubeflow-discuss, all release team members have the proper permissions and are meeting regularly.
**Success Criteria:**
* Release team selected
* Schedule sent to kubeflow-discuss
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we rephrase this to "send out release timeline proposal PR to kubeflow-discuss to receive feedback from the community"? and maybe during the week 1 phase, we have success criteria of "Send out the finalized release schedule to kubeflow-discuss"?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since there are the following checkboxes in the preparation phase above the success criteria:

[ ] Publish draft schedule to kubeflow-discuss, with actual dates
[ ] Get lazy consensus on the release schedule from the WG leads

WDYT about just replacing Schedule sent to kubeflow-discuss with your proposed Send out the finalized release schedule to kubeflow-discuss sentence there?

Currently the Preparation phase does not have a deadline, but from your comment about week 1 I understand you'd like to start defining this phase more concretely?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah okay, if it's already in the preparation phase I think it's okay to leave it as it is. No need to rephrase. I wanted to make sure that the release timeline was proposed to the community for feedback before finalizing. :)

* All release team members have the proper permissions and are meeting regularly
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be helpful to list where the new release team members need to be added for permission. For example, the release GitHub team needs to be updated kubeflow/internal-acls#511 and you mentioned a new member need to join kubeflow-discuss mailing group. Can we add those here and is there anything else that we can specify here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've mentioned that everyone needs to be part of the internal-acl repo, although it's a hyperlink, in the list of checkboxes for the preparation phase.

I'll make it more explicit by adding sub-checks in that step to note that release team mambers need to be:

  1. In the internal-acl repo and github team
  2. Part of the kubeflow-discuss mailing list, in order to have access to the assets (drive, notes, recordings) of the release team

WDYT?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

again, totally missed the preparation phase.

I think the only item missing is being part of the kubeflow-discuss. I think just adding that should be sufficient!

* A tracking issue for the release has been created in kubeflow/community

#### Release Team Selection

The leads of the current release team will be selecting their successors for
the next release. This should also take place before the current release team
holds the release retrospective, in order for the new team to be able to
provide feedback.

The process for selecting shadows and members will be different though. In this
case we want to welcome as many members as possible to join the release team.
The release team should make an outreach via the available channels,
mailing-list, slack, GitHub, and ask for volunteers that would like to
participate in the release team.

We currently don't have a limit on how many consecutive times someone can be a
release manager, but it is hightly recommended that this role is rotated. This
will allow us to further evolve our process and handbook.

### Development (10 weeks)

Normal development in the different WGs and in the <https://github.com/kubeflow/manifests> repo.

**Success Criteria:**
* (Optional but encouraged): Issues tracking new features should also provide information on whether the docs should be updated for that feature
* (Optional but encouraged): Issues tracking new features should also have a
corresponding docs PR that gets developed in parallel with the feature.
This will help keep track of PRs at risk during the Feature Freeze phase as
well as evaluate the docs effort early.


### Feature Freeze (2 weeks)
Expand Down