I think the status quo here extends to: operational issues and performance regressions can be considered like bugs in this context, and patches that are very isolated and deemed safe by any pmc member with experience in that area of the code can approve it on the ticket without it going to the mailing list. This falls under common-sense. But if there's any doubt or mention of appropriateness by anyone (committer or contributor) that should always trigger a ml thread, and it never be seen as distrustful or uncollaborative to seek the clarification and approval.
On Wed, 22 Jan 2025 at 10:00, Jeff Jirsa <jji...@gmail.com> wrote: > > I think the status quo is fine - perf goes to trunk, if you think something > is special, it goes to the mailing list to justify exceptions > > > On Jan 22, 2025, at 3:36 AM, 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
