-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
🌱 improve how do we perform issue triage and milestone management #6828
🌱 improve how do we perform issue triage and milestone management #6828
Conversation
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
This should be a big improvement for signalling what's coming in a new release - big +1
- Code freeze is in effect 72 hours (3 days) before a release. | ||
- Cluster API uses [GitHub milestones](https://github.com/kubernetes-sigs/cluster-api/milestones) to track work | ||
for minor releases. | ||
- Adding an issue to a milestone provides forward visibility on what the next release will be, so, as soon as there |
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.
To clarify, are we aiming to only release when everything in the milestone is done, or are we going to continue to drive toward a release cadence as discussed previously? My only concern here would be committing to a changeset (by saying what the release "will be", as opposed to maybe what the release "might contain") since the work actually getting done by the release deadline will be out of the maintainers' control.
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.
In my opinion we shouldn't wait, except something has been explicitly defined as release-blocking (but this should be only done when really necessary)
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 agree. In that case, it might be worth making this explicit so it's clear to contributors and users that an issue being in the milestone doesn't guarantee inclusion in the release.
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.
+1 to not wait
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.
Updated:
- Adding an issue to the release only imply the issue will be tracked
- We should add to milestone/track only major features/bug fixes specifically targeting a release; everything else will simply merge when ready without additional toil
- There is an item calling out that an issue being in the milestone doesn't guarantee inclusion in the release
Thx for tackling this. I think it's a good step to reduce toil for maintainers |
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
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: vincepri 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 |
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
As per 27th July office hours discussion lazy consensus set for EOW (29th of July) |
37c0279
to
8984cd2
Compare
Commit squashed |
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
Thx for tackling this! Big improvement in my opinion /lgtm |
What this PR does / why we need it:
Proposing a change to how we perform issue triage and milestone management:
/hold
for community discussion
/cc @CecileRobertMichon @enxebre @vincepri @sbueringer