I think Paulo and I are in-sync on this. For me 4.x is mostly about stability right now and 5.x is more active development; so I have a higher bar for back ports to 4.x than I do to 5.x. There is also the question on “risk” which can be subjective from reviewer to reviewer. Some patches may be seen as low risk to some and high risk to others… and when it comes to performance it also gets to how isolated the change is…. For me I don’t really have a clear definition where my cutoff is, but some examples come to mind
1) adding zstd - this is very isolated and comes with low risk as it adds a new compressor, and you must opt-in to this. A patch like this I am far more flexible adding to 4.x as I deem it low risk. 2) rewrite to core read logic to add caches/buffers - this comes with high risk… I would be open to having in 5.0.x but I would be far more concerned with 4.x. In both cases the users can see some great perf wins, but the risks are different and we are more likely to risk stability with #2 than we are with #1. > On Jan 21, 2025, at 12:47 PM, Paulo Motta <pa...@apache.org> wrote: > > 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 > <mailto: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
