Improve the handbook with feedback from the 1.4 Release Retro #537
Conversation
We had discussed that it would help visibility if there's a single tracking issue for the release, and not only tracking issues for each WG. Signed-off-by: Kimonas Sotirchos <kimwnasptd@arrikto.com>
Expose information like the RCs that will be cut between the different phases. Signed-off-by: Kimonas Sotirchos <kimwnasptd@arrikto.com>
Encourage WGs to enforce contirbutors to also have docs PRs in parallel with feature PRs. This will help the docs effort since we will have a better understanding of what PRs still need to be merged for a release. Signed-off-by: Kimonas Sotirchos <kimwnasptd@arrikto.com>
Signed-off-by: Kimonas Sotirchos <kimwnasptd@arrikto.com>
Signed-off-by: Kimonas Sotirchos <kimwnasptd@arrikto.com>
google-oss-prow
bot
requested review from
annajung,
jbottum and
shannonbradshaw
|
/approve cancel |
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
| | 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) | |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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:
Feature Freezedoes not stop at that time, it continues through the subsequent phases- We cut the RC1 because we are preparing for
Manifests Testing, and not becauseFeature Freezestops [which doesn't happen]. We want the Manifests leads to use an RC before they start their testing
WDYT?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
I believe https://github.com/kubeflow/community/tree/master/releases/release-1.5#timeline will be fixed with #538.
| **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 |
There was a problem hiding this comment.
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"?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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. :)
| **Success Criteria:** | ||
| * Release team selected | ||
| * Schedule sent to kubeflow-discuss | ||
| * All release team members have the proper permissions and are meeting regularly |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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:
- In the internal-acl repo and github team
- Part of the
kubeflow-discussmailing list, in order to have access to the assets (drive, notes, recordings) of the release team
WDYT?
There was a problem hiding this comment.
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!
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
I'm augmenting the release handbook to include discussion points from the 1.4 release retro we had https://github.com/kubeflow/community/blob/master/releases/retrospectives/release-1.4.md
Points addressed:
I also think that we should look into breaking the handbook into some smaller files, like
roles,timelineetc. It's currently a huge 300+ lines and will keep getting bigger./cc @annajung
/cc @shannonbradshaw
/cc @jbottum