Define roles and processes for Patch Release Management Team

[nikhita]

The release team is moving from the role of a Patch Release Manager to a Patch Release Management Team: https://github.com/kubernetes/sig-release/tree/master/release-team#kubernetes-release-team-roles.

The current handbook defines processes and suggestions for a patch release manager.

We need to now define processes for the Patch Release Management Team instead. This can include (but not limited to) how many roles this team should have, what responsibilities these roles would entail, etc.

It is important to do this soon, given that we would starting the selection process for the 1.14 release team (#368).

/assign @justaugustus @tpepper @aleksandra-malinowska

[nikhita]

/kind design
/priority important-soon

cc @spiffxp @jberkus @calebamiles

[justaugustus]

As an aside, the Patch Release Team and Branch Manager roles in the Release Team will become extensions of the to-be-formed Release Engineering subproject within SIG Release.

[yue9944882]

how about linking this document to patch team handbook too? highlighting that patch releases are meant for fixing production-impacting bugs

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#patch-releases

[ttousai]

To summarize #408. Patch release manager should be renamed patch release management team for 1.14.

cc @spiffxp @tpepper @aleksandra-malinowska

[tpepper]

We need to make it explicit what is the holiday coverage plan. Traditionally the project slows down dramatically during major holidays. Folks should know they can continue to trust in patch managers being appropriately reachable during these periods, especially the security team in the event of needing handling on critical vulnerabilities. This hasn't been a problem generally, but coverage expectations should be made more clear.

[spiffxp]

/milestone v1.14

If this isn't something we can feasibly define in the v1.14 timeframe, we'll punt from the milestone.

[tpepper]

It's my intention to finish 1.14 with this well defined and with it better defined move forward spreading it into a team effort, so perfect to add to milestone.

[aleksandra-malinowska]

@justaugustus is the discussion going on somewhere about Release Engineering subproject? If so, does it make this issue obsolete?

[justaugustus]

@aleksandra-malinowska -- It's on the backlog, but we haven't actively started discussing it. I was planning on using what you and Tim draft as part of the basis for that conversation.

[aleksandra-malinowska]

Thanks. It sounds like we may be out of sync then. To be honest, I'm not sure if whatever is drafted based on the assumption that there'd be a PRM team will be useful if we're extrapolating it to other roles. For example, it may be a feasible option to have one patch release team manage all supported minor releases, but if we want to merge this role with branch manager, would there have to be a team per release? What are the constraints?

[aleksandra-malinowska]

I'm putting together a draft to use as starting point/explore the possibilities and I was wondering if my understanding of the problem we're trying to solve here is accurate. Right now it seems to me that concerns mentioned revolve mostly around:

• unclear/arbitrary decision making process,
• possibility of inconsistent decisions across branches,
• single point of failure/bottleneck per branch.

What else is there? @justaugustus @nikhita @tpepper

[nikhita]

@aleksandra-malinowska I think that's a great gist of the main concerns right now. 👍

single point of failure/bottleneck per branch.

One more point slightly related to this - lack of shadows for patch release managers. This means we end up with lots of tribal knowledge. Having leads + shadows like other roles would be nice IMO.

[spiffxp]

Opened #553 for v1.14

[justaugustus]

/unassign
/priority critical-urgent
/remove-priority important-soon
/milestone v1.15
/area release-eng release-team

[justaugustus]

/milestone v1.16

[idealhack]

FYI we have a new PR addressing this issue #782 (comment)

[justaugustus]

Closed via #369.
/close

[k8s-ci-robot]

@justaugustus: Closing this issue.

In response to this:

Closed via #369.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.