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 mail
> Of note, it's been 13 months since 5.0 GA. :)
On a scale of 1-10, I'm a 10 out of 10 for being wrong here. It's been 13
months *since we initially intended to release 5.0*. Stabilization of CI and
some bugs took us to mid 2024. So it's not as bad as all that. Thanks to those
that pointed this
>> That is ... 6 branches at once. We were there, 3.0, 3.11, 4.0, 4.1, 5.0,
trunk. If there was a bug in 3.0, because we were supporting that, we had
to put this into 6 branches
My idea is not to increase the number of support branches (it is
definitely not what I want to, I am more a fan of releas
On Thu, Jan 23, 2025 at 3:20 PM Dmitry Konstantinov
wrote:
> Hi Stefan,
>
> Thank you a lot for the detailed feedback! Few comments:
>
> >> I think this is already the case, more or less. We are not doing perf
> changes in older branches.
> Yes, I understand the idea about stability of older bran
Hi Stefan,
Thank you a lot for the detailed feedback! Few comments:
>> I think this is already the case, more or less. We are not doing perf
changes in older branches.
Yes, I understand the idea about stability of older branches, the primary
issue for me is that if I contribute even a small impro
I think the current guidelines are sensible.
Going through your suggestions:
1) I think this is already the case, more or less. We are not doing perf
changes in older branches. This is what we see in CASSANDRA-19429, a user
reported that it is a performance improvement, and most probably he is
ri
Agree 100% with Brandon here.
On 22/1/25 13:56, Brandon Williams wrote:
On Tue, Jan 21, 2025 at 2:10 PM Jordan West wrote:
We currently have guidelines published:
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=199530302#Patching,versioning,andLTSreleases-Wheretoapplypatches.
> When we speak about minor releases - it looks like the release process is
> much slower and not so predictable, it can be a year or even more before I
> can get any minor release which includes a change, and nobody can say even a
> preliminary date for it.
This is one of the reasons I keep agi
On Tue, Jan 21, 2025 at 2:10 PM Jordan West wrote:
> 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
> i
Hi all,
I am one of the contributors for the recent perf changes, like:
https://issues.apache.org/jira/browse/CASSANDRA-20165
https://issues.apache.org/jira/browse/CASSANDRA-20226
https://issues.apache.org/jira/browse/CASSANDRA-19557
...
My motivation: I am currently using 4.1.x and planning to a
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 exceptionsOn Jan 22, 2025, at 3:36 AM, Jordan West wrote:Thanks for the initial feedback. I hear a couple different themes / POVs. David/Paulo, it sounds like maybe a gui
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
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 t
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 imp
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
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
16 matches
Mail list logo
