Patch Release: update team process documentation #782
Conversation
We've shifted from a set of managers for individual patch releases to a combined, collaborative Patch Release Team. Update docs to match. Signed-off-by: Tim Pepper <[email protected]>
k8s-ci-robot
added
cncf-cla: yes
|
@kubernetes/patch-release-team FYI Also this should represent closure on #369 |
k8s-ci-robot
requested review from
aleksandra-malinowska,
dougm,
feiskyer,
hoegaarden and
idealhack
GitHub doesn't enable concise tracking of the evolving state of PRs as they shuffle along towards meeting merge criteria on a branch. During the past 9 months we've evolved a process for this in the patch release team so we can collaborate on triaging inbound cherry picks and driving consensus on whether to accept them on a branch. This new documentation attempts to capture the current process. It reads a lot more complicated than it is, although better tooling would nevertheless be very welcome. Signed-off-by: Tim Pepper <[email protected]>
tpepper
force-pushed
the
prt_process_docs
branch
from
e4e96aa
to
c1de138
Compare
| patch release. Within each of these sections, cherry picks are | ||
| listed in reverse PR number order, newest on top. To add a notation | ||
| for a newly inbound cherry pick, add a row above the current newest | ||
| row. |
There was a problem hiding this comment.
how often do patch release team members enter or modify new items?
There was a problem hiding this comment.
Depends. I guess less often, after we cut a patch, more often just before we cut a patch. I think I had times where I did check on cherry pick PR only once a week and I had times where I checked and updated cherry pick PRs more then once a day. Not sure how other's on the team handle that though.
There was a problem hiding this comment.
Over in kubernetes/community#4081 I note we scrub things about weekly, but more often just before release.
| ### Future Work | ||
|
|
||
| * It would be awesome to replace this manual stateful review workflow with a | ||
| tool. Such a tool appears to need invented. |
There was a problem hiding this comment.
what are some features or specs for such a tool? if it's needed very much, let's start to think about it.
There was a problem hiding this comment.
No spec exists, but automation in support of the manual inspect, triage, share thoughts, discuss, form consensus would be useful. As I write that...It almost sounds like Gerrit. /me ducks from the thrown tomatoes.
|
/lgtm |
k8s-ci-robot
added
the
lgtm
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hoegaarden, tpepper 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 |
Add description of how we are working together as a team now to track the evolving state of cherry pick PRs and arrive at consensus on whether or not to approve each for merge.