I'd be happy to volunteer to take a backport of this feature out to production if that helps push this more towards being "prod-ready." I see enough value in this feature that I would want to either way, even if we ultimately decide to not merge it into a stable branch. That said, I can still be sympathetic to how this is different from auto-repair in terms of demand for the feature if that ultimately is the deciding factor for whether or not to backport.
On Fri, Feb 20, 2026 at 10:04 AM Josh McKenzie <[email protected]> wrote: > Fair point on it not being widely used in a prod environment yet (unless > someone wants to step forward and advocate for it). It does open the door > for questions around our stance on backporting isolated features flagged as > experimental to existing GA branches and whether that's any different than > backporting features we advertise as prod ready. > > I really don't want us to regress when it comes to our stance on stability > as being priority #1, but our releases are very long-lived and some of > these things we're adding to GA branches are kind of "ecosystem technical > debt", in that we're some years behind on making industry standard features > and tooling available to users. > > On Thu, Feb 19, 2026, at 6:33 PM, Štefan Miklošovič wrote: > > Up to you guys! I believe your judgement here. I am just saying, as a > fact, that I am not sure there are a lot of precedents when it comes to > backporting a feature which was not released yet. > > Repairs are something else. It runs in production already, I believe, for > some users. I am just not 100% comfortable with backporting something we do > not know how it will be received or if it has some gaps or issues. We think > it does not. > > Anyway proceed as you see fit :) I am only happy that you think we did > such a great feature that it begs for backporting even if it was not > released yet .. > > On Thu, Feb 19, 2026 at 2:48 PM Josh McKenzie <[email protected]> > wrote: > > > Flipping through the PR, it looks like the vast majority of the 2k patch > is test code and docs with some very small (10 lines or so) additions of > API endpoints to various services + the new async service at ~ 500. This > looks like a backport candidate with very low risk to users who don't > enable it. > > We could backport it and doc / flag it as an experimental feature on older > branches if we're worried the profiler integration when combined w/the C* > code is unstable or could cause slowdown or outage. > > I'm +1 on backporting, marked experimental or not. Seems useful and very > low risk. > > On Wed, Feb 18, 2026, at 11:15 PM, Štefan Miklošovič wrote: > > I would wait until 6.0 is out and it has more exposure. It has to be used > for a while so we are confident and comfortable that backporting is okay. > Maybe some issues or improvements will be done and then we would need to > backport that too? Let's just mature it first before making that jump. > > On Fri, Feb 13, 2026 at 4:44 PM Bernardo Botella < > [email protected]> wrote: > > Hi everyone! > > We added async profiling to Cassandra via nodetool command on this commit: > Initial async-profiler Nodetool implementation · apache/cassandra@7c3c3a1 > <https://github.com/apache/cassandra/commit/7c3c3a1d86782a515583f89c6f17fb30e7f5e41e> > github.com > <https://github.com/apache/cassandra/commit/7c3c3a1d86782a515583f89c6f17fb30e7f5e41e> > [image: apple-touch-icon-180x180-a80b8e11abe2.png] > <https://github.com/apache/cassandra/commit/7c3c3a1d86782a515583f89c6f17fb30e7f5e41e> > > With a bug fix in this commit: > [image: d1b4ddc32acd8328f83ea7b5dd5a8cd3437ded04.png] > Fix JMXFeatureTest failure due to disabled AsyncProfiler · > apache/cassandra@d1b4ddc > <https://github.com/apache/cassandra/commit/d1b4ddc32acd8328f83ea7b5dd5a8cd3437ded04> > github.com > <https://github.com/apache/cassandra/commit/d1b4ddc32acd8328f83ea7b5dd5a8cd3437ded04> > I think this feature will be useful for other branches as well. It is > pretty self contained, and I see low risk on back porting it. > > I wanted to pick the community collective brain on this one to understand > if there would be any concerns for this to be back ported, or I can start > working on it. > > Thanks! > Bernardo > > > >
