Review of the Release Engineering backlog

[xmudrii]

In the search for something to work on, I've gone through the Release Engineering backlog. However, I've noticed a couple of issues that:

• haven't been updated for a long time
• are stale or rotten and close to being closed by the bot

Some of those issues are potentially not relevant anymore (as things are changing quite fast nowadays), but some are still relevant.

I've decided to build a list with affected issues along with a proposed action and explanation. I hope this will help to tidy the backlog a bit, as well as, that we don't lose any relevant issue.

Candidates for closing

Some of those issues already has lifecycle/rotten and will be closed soon

• Testing bash scripts: PR feedback (Testing bash scripts: PR feedback release#855)
  • Status: closed
  • lifecycle/rotten along with help wanted (and mentioned as good for associates)
  • Proposed action: close.
  • This is an older issue about testing our bash scripts. As we are switching to Go and krel, and with anago being deprecated, is it worth investing time into this?
• gcbmgr release frequently fails at "push git objects" (gcbmgr release frequently fails at "push git objects" release#933)
  • Status: closed
  • lifecycle/rotten
  • Proposed action: close.
  • AFAIK, we have got ridden of gcbmgr.
• [anago] Potential improvements for logging k/release repo information ([krel] Allow krel to interpret an arbitrary k/release git reference instead of just branches (TOOL_BRANCH) release#1028)
  • lifecycle/rotten and help wanted
  • Proposed action: close (@justaugustus -- leave open, I left a comment)
  • Status 8/5: Relevant for krel. Should we update the issue title/description to mention this?
  • As anago is deprecated and we are going towards Go tools, is this something we want to touch? Although, this is something that still might be useful, so I'm on the fence on this one.

Candidates for closing or freeze

• RFC -- Investigate concourse for release pipelines (RFC -- Investigate concourse for release pipelines release#848)
  • Status: closed
  • lifecycle/rotten
  • Proposed action: lifecycle/frozen or close.
  • I think that we have got quite experienced GCB over the time, it works well for us, and we are sponsored by Google for infra. While I love experimenting with the new stuff, I think this would require a lot of time-wise investment, so we should eventually leave it aside for now until we don't finish the main tooling-related tasks.
• Consider using RPM spec with debbuild for creating Debian packages (Consider using RPM spec with debbuild for creating Debian packages release#996)
  • lifecycle/rotten
  • This looks like a nice idea. Although the debbuild project doesn't seem to be a popular one, so it might be harder to find someone with the experience or some project that's already using it. That introduces a little bit of a risk.

Issues that are stale but shouldn't be

• Analyze current release tooling (Analyze current release tooling release#837)
  • Status: closed
  • lifecycle/rotten
  • I think this is something that might be very useful. We should check in what state this is in and eventually update and expand it.

Frozen issues that are candidates to be worked on

• Add check to verify-boilerplate (Add check to verify-boilerplate release#777)
  • It's still unclear what's the status of repo-infra, but it seems like copying from it is an okay approach. If that's right, I think we should attempt to fix what can be fixed and then create a follow-up issue to use repo-infra when it becomes possible.

---

So far, I've just looked at issues with no one assigned (by using the no:assignee filter). If this is something that seems useful to you or that you like, I can also take a look at issues with assignees and ping them to check for the status. After that, I can create a similar report as well.

/assign @justaugustus @xmudrii

[xmudrii]

I'll try to label the issue, please fix it if I make some mistake.

/sig release
/area release-eng
/kind cleanup

I'd say that priority is important-soon, but I'd leave it on @justaugustus or someone else with more experience.

[markjacksonfishing]

Awesome work @xmudrii I will ping you to help

[Conan-Kudo]

From @xmudrii:

This looks like a nice idea. Although the debbuild project doesn't seem to be a popular one, so it might be harder to find someone with the experience or some project that's already using it. That introduces a little bit of a risk.

Depends on how you judge popularity. If you're judging it by contributions on GitHub, it's probably not considered very popular.

However, it is used by a fair number of projects, such as Microsoft's Linux procdump, Red Hat's Spacewalk project, Fedora's Cobbler project, the KIWI project, and Datto's dattobd kernel module.

There's also a fair number of random packages using it on the openSUSE Build Service since OBS supports building Debian/Ubuntu packages using debbuild.

[xmudrii]

The last time I've gone through the unassigned issues in the backlog. After the positive feedback, I've decided to go through all issues in the backlog.

Right now, there are 28 issues in the backlog. Just like the last time, I've highlighted some relevant issues and proposed the action. I haven't mentioned some issues that are newly added or work-in-progress.

Issues in the v1.18 milestone

There are a couple of issues with the v1.18 milestone. Since v1.18 has been released a couple of weeks ago, we should move those issues to another milestone.

• Signing releases with GPG keys (Signing releases with GPG keys release#914)
  • Status: moved to the v1.19 milestone
• Support for Debian Buster (Support for Debian Buster release#728)
  • Status: moved to the v1.19 milestone
• kubernetes yum repository using remote paths with ../../pool and odd filenames (kubernetes yum repository using remote paths with ../../pool and odd filenames release#689)
  • Status: moved from v1.18 to the v1.19 milestone
• Should release-notify script send from GCB? (Should release-notify script send from GCB? release#959)
  • Status: moved to the v1.19 milestone and removed the lifecycle/rotten label, and assigned
• Build release notes for alpha.0 and beta.0 releases (Build release notes for alpha.0 and beta.0 releases release#1119)
  • Status: moved to the v1.19 milestone

Issues with the lifecycle/frozen label

There are a couple of issues with the lifecycle/frozen label in the backlog. We should reconsider are some issues still frozen.

• Eliminate the docker load from the production (Eliminate the docker load from the production kubernetes#24123)
  • Status: closed

Other issues

Issues that we should keep an eye on them.

• Alternatives to GCR hosted images for building/testing k8s (Alternatives to GCR hosted images for building/testing k8s kubernetes#78679)
  • Status: assigned

Good first issues

• Evaluate github.com/tallclair/mdtoc as replacement for our implementation (Evaluate mdtoc as replacement for our implementation release#1010)
  • Status: assigned; last activity 19 days ago; received an update
  • Taken action: removed good first issue and help wanted labels

Community-wide issues

The community-wide issues include issues that affect multiple SIGs and may require a lot of discussions. For example, an LTS release is considered a community-wide issue. There are about 6 community-wide issues.

• [umbrella issue] bash in kubernetes ([umbrella issue] bash in kubernetes kubernetes#78702)
  • Status 8/5: At risk of being closed soon, but it still seems relevant.
• Increase Kubernetes support window to one year (Increase Kubernetes support window to one year enhancements#1498)

[xmudrii]

I've noticed that the number of issues in the backlog and other columns has got decreased compared to the last week. I've gone through the project activity and collected all issues that got closed by the bot in the last couple of days. I thought this might be useful, so we don't lose potentially relevant issues.

Backlog issues that got closed recently

Candidates for reopening

All those issues still seem relevant to me, so I propose to reopen them.

• Separate binary publishing from latest release marker file update (Separate binary publishing from latest release marker file update #390)
  • priority/important-longterm
• Document GCS buckets and their usage (Document GCS buckets and their usage release#944)
  • priority/important-longterm
• automated build trigger and validation of RPMs/Debs (automated build trigger and validation of RPMs/Debs release#631)
  • priority/important-soon
• Announcement template updates (Announcement template updates release#844)
  • priority/important-longterm

Issues that should remain closed

• [anago] publishing-bot issue creation is noisy ([anago] publishing-bot issue creation is noisy release#712)
  • Since we're switching away from anago, is it worth spending time on it?

Unclear status

• bsdmainutils requirement limits gcbmgr to debian distros (bsdmainutils requirement limits gcbmgr to debian distros release#684)
  • priority/important-soon
  • It's unclear to me is it still relevant or no

To do issues that got closed recently

Candidates for reopening

• Patch release process should update kubernetes/website Kubernetes versions (Patch release process should update kubernetes/website Kubernetes versions #626)
  • priority/important-longterm
  • As far as I know, this issue is still not fixed and it probably still relevant
• cherry pick process enhancements (cherry pick process enhancements #611)
  • This still seems like a relevant issue
• Document current usage of kubernetes version marker files (Document current usage of kubernetes version marker files #759)
  • This still seems like a relevant issue

Unclear status

• bot feedback on PRs for patch release branches (bot feedback on PRs for patch release branches #680)
  • It seems like some tasks are already resolved, but there still might be some tasks to take care of

In progress issues that got closed recently

Unclear status

• More refined guidance for Release Manager Associates (More refined guidance for Release Manager Associates #695)
  • Status 8/5: @justaugustus has announced a sometimes ago that this will happen, but the issue got closed and I'm not aware that this happened yet. This could be a candidate for reopening.
• Unify release notes tooling (Unify release notes tooling release#954)
  • Status 8/5: I'm not sure about this one, but there have been a lot of improvements recently as part of the integration with krel ([krel] Refactor existing bash scripts into go tools release#918).

[lasomethingsomething]

I've updated this list to reflect all items either Closed or Done, and collected the remainder/unresolved items for us to review via a new GitHub issue. There was some slight overlap of issues here and in past retro items so I'll consolidate.