Thanks for the initial feedback. I hear a couple different themes / POVs. David/Paulo, it sounds like maybe a guide for perf backports + mailing list consensus when necessary + clear documentation of this could be a way forward. I agree that each change comes with stability risks but at the same time the greatest stability risk with Cassandra historically has been major version upgrades (although we have made great improvements here). For folks who want only the performance improvements, we are asking them to take greater risk by upgrading a major version or to maintain a fork. The fork is reasonable for some of the larger operators but not others. That said, I do agree we need to use judgement. Not all changes are worth backporting and some may incur too much risk. We could also add to the guide suggestions of how to de-risk a change (e.g. code is isolated, config to turn it off / off by default, etc).
Jeff, I agree 1% wins aren't worth it if they are invasive and in risky areas. Not all of the improvements are that minor. Jordan On Tue, Jan 21, 2025 at 1:57 PM Jeff Jirsa <jji...@gmail.com> wrote: > We expect users to treat patch and minor releases as low risk. Changing > something deep in the storage engine to be 1% faster is not worth the risk, > because most users will skip the type of qualification that finds those one > in a billion regressions. > > Patch releases are for bug fixes not perf improvements. > > > On Jan 21, 2025, at 9: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 > >
