Define a etcd backport criteria

[serathius]

What would you like to be added?

We should define a clear backport criteria so it's easier to decide when a backport is needed.

My suggestion would be to require all the fixes to have a test, at least a unit test, best an e2e or integration test that confirms that backport will be done correctly and prevent regression.

Based on discussion in #17518

Why is this needed?

Ensure maintain high quality of previous releases.

[ahrtr]

• There is already doc on this. I believe it's clear to all that usually only bugs and CVEs are supposed to be backported to stable releases.
• I think It's common sense to have a test for each fix.

But we shouldn't be too dogmatic on these rules.

[jmhbnz]

We actually have a second place in our existing docs where we attempt to determine what should meet backport criteria: https://github.com/etcd-io/etcd/blob/main/Documentation/contributor-guide/release.md#patch-version-release

To request a backport, developers submit cherry-pick PRs targeting the release branch. The commits should not include merge commits. The commits should be restricted to bug fixes and security patches.

I think the challenge is due to the amount of things we have in scope for 3.6.0 and the time it has been since 3.5.0 was released then we have historically relaxed these guidelines and also backported minor features to release-3.5 as that has been our only vehicle of getting requested functionality out to users in a timely fashion due to how far away 3.6.0 is.

Given this situation we are in, I agree that we can't simply say the only backports we will accept will be security or bug fixes, as then we lose any way of being timely/responsive to our users for a new feature that is hotly requested that could be quite low impact & risk from backport perspective.

However I do completely agree that we should update the docs to make it clear we expect backports to have coverage with unit and ideally e2e or integration tests. Do we think https://github.com/etcd-io/etcd/blob/main/Documentation/contributor-guide/branch_management.md#stable-branches would be the best place to update that?

[serathius]

cc @liggitt for his experience on Kubernetes backport criteria.

[liggitt]

I think the challenge is due to the amount of things we have in scope for 3.6.0 and the time it has been since 3.5.0 was released then we have historically relaxed these guidelines and also backported minor features to release-3.5 as that has been our only vehicle of getting requested functionality out to users in a timely fashion due to how far away 3.6.0 is.

Should 3.6.0 scope be reduced to get out of this situation while keeping maintenance branches super low risk (extremely well understood bugfixes and security fixes only)?

Given this situation we are in, I agree that we can't simply say the only backports we will accept will be security or bug fixes, as then we lose any way of being timely/responsive to our users for a new feature that is hotly requested that could be quite low impact & risk from backport perspective.

It is often difficult to be certain a change is low-impact.

[ahrtr]

Should 3.6.0 scope be reduced

Yes, I have been thinking the same thing. I will propose to release 3.6 in a proper timing, of course clarify the scope of what should be included and what shouldn't.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions.