-
Notifications
You must be signed in to change notification settings - Fork 10
Add release tracker issue template #47
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.
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
base: main
Are you sure you want to change the base?
Conversation
dhiller
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd appreciate having the lane bump as a separate action item.
Also the stabilization should be done per SIG, probably a check as reminder will help.
e618f51 to
f18527a
Compare
|
@fossedihelm we can also add an action-item to create a new release directory under api testdata during the code-freeze. |
dhiller
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably name the sigs that own the action items. WDYT?
dhiller
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
Thank you @fossedihelm
@dhiller We can, but still not sure how, trying to keep the template lightweight. WDYT about a followup? |
f18527a to
bc3a481
Compare
Agree, let's capture that thought in a follow up and then we should be good to go. /lgtm |
bc3a481 to
a26d375
Compare
9b42163 to
ea80d52
Compare
dhiller
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/approve
/hold to let others chime in, feel free to remove when we are good to go with this.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: dhiller 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:
Approvers can indicate their approval by writing |
| - [ ] Mandatory pre-submit lanes. | ||
| - [ ] Non-standard lanes (i.e. migrations, multus, ipv6) have been bumped by stakeholders. | ||
| - [ ] Begin casual observation of issues, CI signal, test flakes, and critical PRs. | ||
| - [ ] Notify SIGs and about upcoming Code Freeze Deadline. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At this point we could enforce merge of specific PRs only with a change to the tide configuration for kubevirt/kubevirt.
As an example kubernetes/kubernetes also does it by only allowing PRs with a specific milestone attached to merge: https://github.com/kubernetes/test-infra/pull/35171/files
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This would be good. Thanks Daniel
|
Do we still need the hold? |
ea80d52 to
15c9185
Compare
|
New changes are detected. LGTM label has been removed. |
15c9185 to
8650bd6
Compare
Signed-off-by: fossedihelm <[email protected]>
8650bd6 to
c779fa2
Compare
|
I made the changes performed during release cycle 1.7. |
aburdenthehand
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great stuff @fossedihelm
I have some feedback but this looks solid and very helpful.
Thanks for putting this together and apologies for the delay in review from my end.
|
|
||
| ### 1. Before the start of the Release Cycle | ||
|
|
||
| - [ ] Captured feedback from the previous release cycle retro and planned to incorporate it into the release cycle. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When/where does this happen? I know some of the unconf's have had a retro but they're always prior to the release itself.
| ### 2. First weeks of the release cycle up to Virtualization Enhancements Proposal Freeze | ||
|
|
||
| - [ ] Release schedule finalized. | ||
| - [ ] Announce schedule blog post. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| - [ ] Announce schedule blog post. | |
| - [ ] Announce schedule. |
Better communicating over mailing list and social media accounts but we can leave this open.
|
|
||
| **A week before Virtualization Enhancements Proposal Freeze:** | ||
|
|
||
| - [ ] Remind the community about Virtualization Enhancements Freeze. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should probably be part of the second point actually. At the moment I think it's necessary to highlight the VEP freeze date on a weekly basis.
| - [ ] Begin casual observation of issues, CI signal, test flakes, and critical PRs. | ||
| - [ ] Notify SIGs about upcoming Code Freeze Deadline. | ||
| - [ ] Bring exceptions to [kubevirt-dev](https://groups.google.com/forum/#!forum/kubevirt-dev). | ||
| - [ ] Code Freeze: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is quite a big list. Should we split Code Freeze and After Code Freeze into their own dedicated sections?
What this PR does / why we need it:
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)format, will close the issue(s) when PR gets merged):Fixes #
Special notes for your reviewer:
Checklist
This checklist is not enforcing, but it's a reminder of items that could be relevant to every PR.
Approvers are expected to review this list.
Release note: