search

etcd-io / etcd

Distributed reliable key-value store for the most critical data of a distributed system
https://etcd.io
Apache License 2.0
47.97k stars 9.79k forks source link

Define a etcd backport criteria #17579

Open serathius opened 8 months ago

serathius commented 8 months ago

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 https://github.com/etcd-io/etcd/pull/17518

Why is this needed?

Ensure maintain high quality of previous releases.

ahrtr commented 8 months ago

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

jmhbnz commented 3 months ago

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 commented 1 month ago

cc @liggitt for his experience on Kubernetes backport criteria.

liggitt commented 1 month ago

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 commented 1 month ago

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.