Thanks for starting this discussion Jordan. Even though I'm not familiar with the specific changes proposed by CASSANDRA-15452, see my comments on generally allowing performance improvements to old branches.
> I believe they should target every active branch because performance is a major selling point of Cassandra. While performance is a major selling point of Cassandra, so is stability. Backporting nontrivial performance improvements potentially hurts stability, since there's a risk the performance improvement introduces a correctness error. > Also, there will be exceptions: patches that are too large, invasive, risky, or complicated to backport. For these, we rely on the contributor and reviewer’s judgment and the mailing list. So, I’m proposing an allowance to backport to active branches, not a requirement to merge them. I might be wrong but suspect there is already some leniency on allowing performance backports to GA branches (ie. 5.X) via lazy consensus request to mailing list? Perhaps we can better clarify these scenarios? One example to me where this would be acceptable is if there is a fundamental performance flaw in a recently released feature that is still in early adoption phase. Regarding backport to stable branches (ie. 4.X), I think this should only be done exceptionally, when the performance fix can be considered a bugfix. Otherwise I'd say we should prioritize stability in stable branches. Also adding performance improvements to trunk has the nice benefit of encouraging users to upgrade to newer versions. Users that can't or don't want to upgrade can always perform their own backports on downstream forks. Thanks, Paulo On Tue, Jan 21, 2025 at 3:10 PM Jordan West <jw...@apache.org> wrote: > Hi folks, > > A topic that’s come up recently is what branches are valid targets for > performance improvements. Should they only go into trunk? This has come up > in the context of BTI improvements, Dmitry’s work on reducing object > overhead, and my work on CASSANDRA-15452. > > We currently have guidelines published: > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302#Patching,versioning,andLTSreleases-Wheretoapplypatches. > But there’s no explicit discussion of how to handle performance > improvements. We tend to discuss whether they’re “bugfixes”. > > I’d like to discuss whether performance improvements should target more > than just trunk. I believe they should target every active branch because > performance is a major selling point of Cassandra. It’s not practical to > ask users to upgrade major versions for simple performance wins. A major > version can be deployed for years, especially when the next one has major > changes. But we shouldn’t target non-supported major versions, either. > Also, there will be exceptions: patches that are too large, invasive, > risky, or complicated to backport. For these, we rely on the contributor > and reviewer’s judgment and the mailing list. So, I’m proposing an > allowance to backport to active branches, not a requirement to merge them. > > I’m curious to hear your thoughts. > Jordan >
