Also I meant to quickly clarify: This isn't specific to 15452 and I think discussion of 15452 should happen on a separate thread, if at all. I personally haven't come to an opinion myself and hadn't planned to broach that subject yet. It was one example of where this discussion had come up between community members and I wanted to bring it to the broader mailing list is all.
On Tue, Jan 21, 2025 at 6:35 PM Jordan West <jw...@apache.org> wrote: > 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 >> >>
