Sig-release: Branch Management Improvements List

[Bubblemelon]

This is a list of TODO items taken out from the branch management handbook.

• [x] Address feedback on https://github.com/kubernetes/sig-release/pull/757
  
  
  
  • [x] (https://github.com/kubernetes/sig-release/pull/852) Add tombstones for Release Manager handbooks in Release Team directory - https://github.com/kubernetes/sig-release/issues/761
  
  
  • [x] (https://github.com/kubernetes/sig-release/pull/852) Move branch creation into its' own section in Branch Management
  
  
  • [x] (https://github.com/kubernetes/sig-release/pull/852) Fix markdown lint warnings in Branch Management handbook
  
  
  • [x] (https://github.com/kubernetes/sig-release/pull/852) Organize test-infra tasks in distinct headings
  
  
  • [x] (https://github.com/kubernetes/sig-release/pull/852) Rearrange Branch Management tasks during branch creation
  
  
  • [x] (https://github.com/kubernetes/sig-release/pull/852) Add reference conventions for Kubernetes releases/milestones
  
  
  • [x] (https://github.com/kubernetes/sig-release/pull/891) Fix SIG Release Testgrid config link (ref: https://github.com/kubernetes/sig-release/pull/757#discussion_r313852658 - @nikhita)
  
  
  • [x] (https://github.com/kubernetes/sig-release/pull/891) Fix headings for merge automation sections (ref: https://github.com/kubernetes/sig-release/pull/757#discussion_r314110054 - @spiffxp)
  
  
  • [x] Documenting post-release tasks
  
  
  • [x] (https://github.com/kubernetes/test-infra/pull/15070) Remove manual-bump-required jobs
  
  
• [x] Address feedback on https://github.com/kubernetes/sig-release/pull/852#pullrequestreview-325132504
  
  
  
  • [x] (https://github.com/kubernetes/sig-release/pull/891) Machine setup
  
  
  • [x] Release Team list is private
  
  
  • Addressed by adding the Release Manager onboarding template (https://github.com/kubernetes/sig-release/pull/880, https://github.com/kubernetes/sig-release/pull/881)
  
  
• [x] Should the Release Manager Associates ~branch manager shadows~ also get at least read access at the beginning? If a shadow is going to exercise the process on behalf of the lead, they will need full read/write access ahead of time [src]
  
  
  
  • This was brought up during the v1.15 retrospective and there are efforts being made to address this, related PRs:
  
  
  • #695 (defined what shadows do/learn)
  
  
  • #689 (providing shadows an associates level of permissions)
  
  
  • Release Manager Associates are now added to k8s-infra-release-viewers@, which grants view access to the relevant SIG Release GCP projects. Added a GH template (https://github.com/kubernetes/sig-release/pull/880, https://github.com/kubernetes/sig-release/pull/881) to onboard new Release Managers.
  
  
• [X] Can the group name be identified here in a clear/transparent way? [src]
  
  
  
  • Marked completed because: Kubernetes Build Admin was created to satisfy this and among other concerns. Before it was instructed to ping only Sumi to build debs/rpms.
  
  
• [x] What guidance can we give on typical failures and triaging? [src]
  
  
  
  • There is a section on how to debug problems with the release tools, is that sufficient?
  
  
  • Current section is sufficient for now. New bugs should be filed and addressed with docs and further tool improvements
  
  
• [x] branchff requires root level permissions, permissions to /usr/local ... [src]
  
  
  
  • This matter with branchff was mentioned in this PR #721 but other concerns with branchff was addressed i.e. assumed dependencies.
  
  
  • Fixed by https://github.com/kubernetes/release/pull/847
  
  

The following improvements are not Branch Manager-specific asks or warranted tracking them separately.
Issues/PRs linked below:

• (https://github.com/kubernetes/sig-release/pull/900) Should the release lead also request some type of read access here for themselves? [[src](https://github.com/kubernetes/sig-release/blame/16f7f25f2de0621b59e9f6630337a14cb23c77b8/release-engineering/role-handbooks/branch-manager.md#L58)]
• (https://github.com/kubernetes/release/issues/631) Automate debs and rpm packaging
• (https://github.com/kubernetes/release/issues/913) (Release Validation) Is there any scripting which will scan the GCP buckets and confirm all expected artifacts were published? It seems no? Because periodically users report just after a release that some file is missing, as if a sub-copy had failed? Would be nice to have build-published-ok.sh or some such, and even a periodic daily rescan of old builds also as some prior build artifacts have somehow gone missing and needed re-published. [[src](https://github.com/kubernetes/sig-release/blame/16f7f25f2de0621b59e9f6630337a14cb23c77b8/release-engineering/role-handbooks/branch-manager.md#L213)]
• (https://github.com/kubernetes/release/issues/959) Should release-notify script be sending from GCB instead of the local machine, and can it? [[src](https://github.com/kubernetes/sig-release/pull/666#discussion_r296540312)]
• (https://github.com/kubernetes/community/pull/4297) Move Markdown style guide to more visible place
• Discuss version markers and update kubekins-e2e docs moving the variants.yaml info there instead
• (https://github.com/kubernetes/sig-release/issues/901) Release Commands Cheat Sheet link is broken

Items are verbosely copied over for now.

CC: @idealhack @vivektaparia @chrisz100 @SlickNik

FYI: @hoegaarden @tpepper @justaugustus

[spiffxp]

I would suggest that branch management is the role that should handle "what 'channel' (beta/stable1/stable2/stable3) corresponds to which version?"

• the beta channel should only exist after the release-1.y branch is cut, and be unused after the v1.y.0 release is cut (aka during the period that builds being cut have the word beta in them, and the branch manager is running branchff and handling cherry-picks prior to the .0 release)
• the stableN versions are moved forward after the v1.y.0 release is cut, so that stable1 refers to v1.y.0, the most recent stable release, stable2 refers to v1.y-1.0, the previous stable release, etc.
• release teams have forgotten to do this last part since 1.11 (ref: ref: https://github.com/kubernetes/test-infra/pull/13577#issuecomment-514833136), so we're in a state where the channels don't mean what they should

other ideas include:

• cut release-1.y super early, but branchff at a significantly reduced cadence
  ref: https://github.com/kubernetes/test-infra/pull/13577#issuecomment-51477967
• decide we don't like the stableN nomenclature at all, and adjust job configs and tooling appropriately (we liked this idea in https://groups.google.com/d/msg/kubernetes-sig-release/ABLP6LHIL7s/0RHWTUd9AQAJ but it proved to be trickier to implement than we had hoped (ref: https://github.com/kubernetes/test-infra/pull/12516))

[idealhack]

/sig release
/area release-eng
/priority important-longterm

cc @kubernetes/release-engineering

[idealhack]

As we have way more associates (shadows) in 1.16, we've been saying no to folks who volunteer to help because we can't simply give the powerful accesses to them (in 1.14 and 1.15 too); on the other hand, we are also confused when we want some folks who happen to have those accesses already to help because it's different than what our document looks like.

We need to develop an onboarding policy which is separate from documenting the branch cut activities.

xref: https://github.com/kubernetes/sig-release/issues/695#issuecomment-505762265

[justaugustus]

(assigning myself as well as I've been helping to burndown some of this.)
/assign
/milestone v1.17

[justaugustus]

With the most recent updates to the checklist and recent PRs, I think we've done enough to close this out.
Anything that wasn't specific to Branch Management has been moved to its' own issue and those are linked in the issue description.
/close

[k8s-ci-robot]

@justaugustus: Closing this issue.

In response to this:

With the most recent updates to the checklist and recent PRs, I think we've done enough to close this out.
Anything that wasn't specific to Branch Management has been moved to its' own issue and those are linked in the issue description.
/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.