Broken release maintenance promises

[serathius]

Etcd versioning policy states The etcd project maintains release branches for the current version and two minor releases, 3.5, 3.4 and 3.3 currently. however I haven't see any active release management done for v3.3 and v3.4 since I joined the project. For example #11321 is still not backported to v3.4

Fact that majority of the release work is done for v3.5 is understandable as this is relatively new release, however no one looked into any backports for v3.4 and bugs reported for v3.4 are not worked on at all. This can be further exemplified by lack of active release managers for those releases https://github.com/etcd-io/etcd/blob/main/RELEASE.md#release-management. Looks like majority of work was pushed on @hexfusion, so with him no longer active no work is being done.

Problem: Without active release managers we break our promise to users about those releases still being actively supported.

Goal: Align the documentation with factual maintenance work.

Requirements:

• Maintenance work should be distributed between maintainers
• It should be clear to decide if maintenance work is being done

Proposal:

• Drop support for v3.3 release as over 4 years since the release we no longer have maintainers with expertise about it. It already creates issues due to how outdated it is Disable SemaphoreCI #13448
• Nominate release managers for v3.4 and v3.5 (happy to take v3.5 role)
• Define a clear set of responsibilities for release manager and a process of nominating a replacement.

cc @ptabor @spzala

[ptabor]

Red Hat used to be committed maintaining 2 historical minor releases and I think it's the main reason fur such declaration and I think it was limited to back-porting significant security patches only. We should check what's RH plans going forward.

[hexfusion]

cc @wallylewis @hasbro17

[spzala]

• As far as I remember, that's the version support always provided by the project. @hexfusion and @gyuho were fantastic release managers (and so is @serathius), and I think the patch releases for previous releases specially for the oldest releases, the release cut was done on need base. I think, considering etcd stability, people don't upgrade to newer version quickly, and that's why the version support for previous two releases.
• If I still remember correctly, RH supports the previous three releases in OpenShift (per a related email discussion among maintainers sometime back). +1 to @ptabor on asking RH (thanks @hexfusion for the ping already here. I will try to follow up with a direct ping if GH notification go unnoticed.) and to the community via email in ML and see if there are any comments on dropping support of previous two releases to one.
• +1 on sharing release work among maintainers. I would like to take responsibility here as well. We may want to think on having a dedicated releases team to reduce the load on maintainers if that sounds good?. As we look for more contributors, we may find contributors interested in being part of the release management team instead of other project-wide contributions.

[hasbro17]

Just chiming in from Red Hat's side: v3.3 is not part of any supported OpenShift release so I think we would be okay with dropping support for that release.
Unfortunately we've been slowed down by some recent staffing issues on our team but I'm hopeful once we can ramp up again we can soon start contributing again towards 3.4, 3.5, and more general maintenance.

[serathius]

Just chiming in from Red Hat's side: v3.3 is not part of any supported OpenShift release so I think we would be okay with dropping support for that release. Unfortunately we've been slowed down by some recent staffing issues on our team but I'm hopeful once we can ramp up again we can soon start contributing again towards 3.4, 3.5, and more general maintenance.

Based on that we should update the documentation and drop support to v3.3. We should not provide users with false promise of support if really no one is working on it.

• As far as I remember, that's the version support always provided by the project. @hexfusion and @gyuho were fantastic release managers (and so is @serathius), and I think the patch releases for previous releases specially for the oldest releases, the release cut was done on need base. I think, considering etcd stability, people don't upgrade to newer version quickly, and that's why the version support for previous two releases.

We should be able to revise it all the time to provide users with guarantees that we can provide and users can trust. Current document give uses false promise that issues on old releases will be fixed allowing users to justify not upgrading. Promises about support should be clear, correct and relevant to users.

[serathius]

I think we should also start actively looking for v3.4 release manager. I'm seeing more and more cases like #13206 where work on backporting to v3.4 is forgotten and abandoned.

cc @ahrtr as person that did the most to help triage issues in v3.4.

[ahrtr]

I think the top priority for now is to make the 3.4 pipeline green.

Proposed actions:

1. Upgrade the golang version to 1.15.x (in go.mod and pipeline test), and drop the support of golang 1.12;
2. Fix all pipeline errors

If it's OK, then I will evaluate the effort and fix all low hang fruit in the first step. And afterwards, I may raise issues asking for help if needed, so that we can leverage the community to get them resolved;

[lavacat]

FYI, @serathius @ahrtr I've started looking at 3.4 pipeline for our internal build, so I can be release manager.

[serathius]

Thanks @lavacat for help. Waiting for PR with fixes.

[serathius]

Based on great work by @ahrtr on #14105 (comment) I want to propose him to become the release manager v3.4.

@ahrtr is this ok with you?

[ahrtr]

Based on great work by @ahrtr on #14105 (comment) I want to propose him to become the release manager v3.4.

@ahrtr is this ok with you?

YES, thanks. Also big thanks to @lavacat

[serathius]

I think the situation is much better now. We have agreed to support 2 releases and manager for both of them. We still need to work on defining responsibilities, but this can be done as a follow up.