search

kubernetes / sig-release

Repo for SIG release
Apache License 2.0
521 stars 379 forks source link

Playbook for communications between release team and contributors #1040

Closed alejandrox1 closed 3 years ago

alejandrox1 commented 4 years ago

The last wee of the 1.18 release presented the release team with interesting scenarios that we had not completely planned for. There were a handful of cherry picks into 1.18 that were done past the cherry-pick deadline for 1.18 and these all presented potential delays for the release of 1.18. One of these issues was actually discovered the day of the release and led to a one day delay of the release.

For context - it is important to look back and observe the exchanges we had and how we arrived at decisions - these are the issues that showed up last minute in 1.18

We were able to discover these issues due to the hard work and diligence of many contributors who ping the sig release channel and informed us of these release-blocking issues. The problem is that the release team was unaware of these issues for weeks and this is where I want to propose some changes to prevent this in future releases.

Proposal

These issues showed us that we need to have a conversation with contributors. The Kubernetes ecosystem is large and complex, it is not a reasonable expectation to assume that members of the release team will have all the information needed to know whether an issue is release-blocking or not and it is equally possible for contributors to not have all the information.

One proposed change is to ask on all kind/bug issues and PRs in kubernetes/kubernetes that are either in the current milestone or that have been opened since the last code thaw the following questions:

Again, these questions should be asked for all issues and PRs labeled as kind/bug whether they are in the current milestone or if they have been opened since the last code thaw. The later requirement because it is possible for a release-blocking bug to be found but not be in the current milestone because contributors who created the issue or PR are not milestone maintainers and none of the reviewers applied the milestone or had access to do so.

Alternatives Some alternatives that have been discussed in some mediums is to enforce the application of a milestone. All issues and PRs would be automatically labeled with something like needs-milestone and would only be applied to a milestone by having the authors or reviewers of an issue or PR provide all the information that we asked above. For this to be effective, the release team would have to also go through the issues lacking a milestone, otherwise we run the risk of missing important bug fixes because no one applied or requested the milestone.

Additional Details A playbook containing the above questions should also include other conditional such as

/sig release /cc @kubernetes/release-team /priority important-soon /milestone v1.19 /kind documentation

alejandrox1 commented 4 years ago

ping @onlydole :waffle:

LappleApple commented 4 years ago

Hi, I'm wondering if diagramming this first instead of writing it out in narrative format could be simpler and user-friendlier? @saschagrunert has been working on some great diagrams, and he and I (and other RT members) have been talking about how diagramming the release team "Happy Path" could be very valuable for clarifying key processes and workflows. This issue focuses on a critical aspect of the RT workflow. Would be great to collaborate on mapping out how it ideally works and what related communications (using succinct taglines/cues) need to happen at each step

tpepper commented 3 years ago

Relates to https://github.com/kubernetes/sig-release/issues/320 and https://github.com/kubernetes/community/issues/4289

LappleApple commented 3 years ago

From prioritisation session: Should we bring back the release-blocker tag?

alejandrox1 commented 3 years ago

@bai let's chat about this one :smile: ptal

alejandrox1 commented 3 years ago

@bai I think last time we talked we mentioned that the aim for this issue would be to tweak the message that bug triage team sends to issues and PRs with the goal to improve (if needed) communication. Using a message i saw on an issue as example

Hey wave Bug Triage here. Just wanted to post a friendly reminder that the code freeze is starting 12.11.2020 (about 3-4 weeks from now) and while there is still plenty of time, we want to ensure that each PR has a chance to be merged on time.

As the PR is tagged for 1.20, is it still planned for this release?

I think the above is the standard type of message that we see in releases. One possible improvement I could think is a preamble talking about the current release, what code freeze is, and why it matters for the PR to be merged in time.

From started, the bug triage team is most well known by some people but mostly by sig release. I think that it would help people put the message into context if the intro said something like "Hey, we are from the Kubernetes release team for the 1.20 release...". Otherwise the message could be from some other team just doing bug triage so the sense of urgency or importance of the deadlines may be lost.

The next thing I can think of is: what is code freeze? This, is something that I also think that it is well known by sig release but not very well known by all contributors. Making it mention of code freeze without some explanation of what it is or why it matters (i.e., is this isue a must have as soon as possible? is this PR needed right now or can it wait for N weeks more to be merged?).

Overall, thinking about refraiming the message to start a conversation and inform the author(s) of an issue or PR. @bai , what do you think?

/assign @bai @alejandrox1

alejandrox1 commented 3 years ago

/milestone v1.21

alejandrox1 commented 3 years ago

AI: let's add more docs like https://github.com/kubernetes/sig-release/pull/1347

fejta-bot commented 3 years ago

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale

fejta-bot commented 3 years ago

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle rotten

saschagrunert commented 3 years ago

@alejandrox1 are you still working on this or do you think we should close out this issue?

fejta-bot commented 3 years ago

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community. /close

k8s-ci-robot commented 3 years ago

@fejta-bot: Closing this issue.

In response to [this](https://github.com/kubernetes/sig-release/issues/1040#issuecomment-834188423): >Rotten issues close after 30d of inactivity. >Reopen the issue with `/reopen`. >Mark the issue as fresh with `/remove-lifecycle rotten`. > >Send feedback to sig-contributor-experience at [kubernetes/community](https://github.com/kubernetes/community). >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.