Re: [VOTE] Release dtest-api 0.0.17

[Doug Rohrer]

Vote passes with 6 binding a 4 non-binding (accidentally added myself to the 
“binding” count before).

Thanks all. I’ll get the release out ASAP.

Doug

> On Sep 11, 2024, at 5:32 PM, Doug Rohrer  wrote:
> 
> As it stands, the vote passes with 7 binding and 3 non-binding +1s. Dinesh 
> pointed out that we usually allow 72 hours for votes (and the Apache Release 
> Policy says that the “SHOULD” last 72 hours), but all previous dtest-api 
> votes I saw were only 24, which is why I left this one at 24 as well.
> 
> Given the standard is 72 hours (even though it is a “SHOULD” not a “MUST”), 
> I’m inclined to extend this vote for another 48 hours (which would mean it 
> would close Friday of this week). Any objections? Also, do we have any 
> historical reason why these are only 24 hours vs. 72?
> 
> Thanks,
> 
> Doug
> 
>> On Sep 10, 2024, at 5:16 PM, Doug Rohrer  wrote:
>> 
>> It was pointed out that auto-correct removed the “d” from “dtest” so just 
>> responding to this with a correct title in case “test-api” wasn’t clear. 
>> Vote will still close at the initial 24-hour period as I don’t think this 
>> has prevented folks from finding and voting so far.
>> 
>> Doug
>> 
>>> On Sep 10, 2024, at 1:33 PM, Francisco Guerrero  wrote:
>>> 
>>> +1 (nb)
>>> 
>>> On 2024/09/10 14:34:48 Doug Rohrer wrote:
 Proposing the test build of in-jvm dtest API 0.0.17 for release
 
 Repository:
 https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git
 
 Candidate SHA:
 https://github.com/apache/cassandra-in-jvm-dtest-api/commit/85b538ca8259dedc2aded8a633cf3174f551f664
 Tagged with 0.0.17
 
 Artifacts:
 https://repository.apache.org/content/repositories/orgapachecassandra-1343/org/apache/cassandra/dtest-api/0.0.17/
 
 Key signature: 9A648E3DEDA36EE374C4277B602ED2C52277
 
 Changes since last release:
 * CASSANDRA-19783 - In-jvm dtest to detect InstanceClassLoaderLeaks
 * CASSANDRA-19239 - jvm-dtests crash on java 17
 
 The vote will be open for 24 hours. Everyone who has tested the build
 is invited to vote. Votes by PMC members are considered binding. A
 vote passes if there are at least three binding +1s.
>> 
> 

Re: [DISCUSS] CASSANDRA-13704 Safer handling of out of range tokens

[Caleb Rackliffe]

The patches for this issue have gotten a +1 from Mick, and that meets our
strict 2 committer rule, but I'm posting them here in case anyone else
wants take a look:

4.0: https://github.com/apache/cassandra/pull/3526
4.1: https://github.com/apache/cassandra/pull/3539
5.0: https://github.com/apache/cassandra/pull/3544

On Sun, Sep 15, 2024 at 10:21 AM Brandon Williams  wrote:

> +1 for declaring things like this in the vote/release emails.
>
> Kind Regards,
> Brandon
>
> On Sun, Sep 15, 2024 at 10:17 AM Michael Shuler 
> wrote:
> >
> > I've stated this same opinion prior, fix was in NEWS.txt and users had a
> > bad day with a behavior change. Perhaps this kind of inclusion needs
> > more exposure. This is exactly the sort of change may *also* be best
> > stated clearly in the vote/release emails, ala:
> >
> > 
> > ==
> > This release contains a relatively major change you should be aware of,
> > with xyz fix, new default, and with the behavior change, here are the
> > new defaults, how to disable, etc...
> > ==
> > kthxbai.
> >
> > Just do everything possible to convey what operators need to know,
> > wherever we can, if we include the fix. Link to NEWS.txt is insufficient
> > in this sort of case.
> >
> > Warm regards,
> > Michael
> >
> > On 9/12/24 13:16, Abe Ratnofsky wrote:
> > > Expressing another vote in favor of rejection-by-default. If a user
> doesn't want to lose sleep for data loss while on-call, they can read
> NEWS.txt and disable rejection.
> > >
>

[DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

[Štefan Miklošovič]

We are using a library called Chronicle Queue (1) and its dependencies and
we ship them in the distribution tarball.

The version we use in 5.0 / trunk as I write this is 2.23.36. If you look
closely here (2), there is one more release like this, 2.23.37 and after
that all these releases have "ea" in their name.

"ea" stands for "early access". The project has changed the versioning /
development model in such a way that "ea" releases act, more or less, as
glorified snapshots which are indeed released to Maven Central but the
"regular" releases are not there. The reason behind this is that "regular"
releases are published only for customers who pay to the company behind
this project and they offer commercial support for that.

"regular" releases are meant to get all the bug fixes after "ea" is
published and they are official stable releases. On the other hand "ea"
releases are the ones where the development happens and every now and then,
once the developers think that it is time to cut new 2.x, they just publish
that privately.

I was investigating how this all works here (3) and while they said that, I
quote (4):

"In my experience this is consumed by a large number of open source
projects reliably (for our other artifacts too). This development/ea branch
still goes through an extensive test suite prior to release. Releases from
this branch will contain the latest features and bug fixes."

I am not completely sure if we are OK with this. For the record, Mick is
not overly comfortable with that and Brandon would prefer to just replace
it / get rid of this dependency (comments / reasons / discussion from (5)
to the end)

The question is if we are OK with how things are and if we are then what
are the rules when upgrading the version of this project in Cassandra in
the context of "ea" versions they publish.

If we are not OK with this, then the question is what we are going to
replace it with.

If we are going to replace it, I very briefly took a look and there is
practically nothing out there which would hit all the buttons for us.
Chronicle is just perfect for this job and I am not a fan of rewriting this
at all.

I would like to have this resolved because there is CEP-12 I plan to
deliver and I hit this and I do not want to base that work on something we
might eventually abandon. There are some ideas for CEP-12 how to bypass
this without using Chronicle but I would like to firstly hear your opinion.

Regards

(1) https://github.com/OpenHFT/Chronicle-Queue
(2) https://repo1.maven.org/maven2/net/openhft/chronicle-core/
(3) https://github.com/OpenHFT/Chronicle-Core/issues/668
(4)
https://github.com/OpenHFT/Chronicle-Core/issues/668#issuecomment-2322038676
(5)
https://issues.apache.org/jira/browse/CASSANDRA-18712?focusedCommentId=17878254&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17878254

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

[Jordan West]

Thanks for the sleuthing Stefan! This definitely is a bit unfortunate. It
sounds like a replacement is not really practical so I'll ignore that
option for now, until a viable alternative is proposed. I am -1 on us
writing our own without strong, strong justification -- primarily because I
think the likelihood is we introduce more bugs before getting to something
stable.

Regarding the remaining options, mostly some thoughts:

- it would be nice to have some specific evidence of other projects using
the EA versions and what their developers have said about it.
- it sounds like if we go with the EA route, the onus to test for
correctness / compatibility increases. They do test but anything marked
"early access" I think deserves more scrutiny from the C* community before
release. That could come in the form of more tests (or showing that we
already have good coverage of where its used).
- i assume each time we upgrade we would pick the most recently released EA
version

Jordan


On Mon, Sep 16, 2024 at 1:46 PM Štefan Miklošovič 
wrote:

> We are using a library called Chronicle Queue (1) and its dependencies and
> we ship them in the distribution tarball.
>
> The version we use in 5.0 / trunk as I write this is 2.23.36. If you look
> closely here (2), there is one more release like this, 2.23.37 and after
> that all these releases have "ea" in their name.
>
> "ea" stands for "early access". The project has changed the versioning /
> development model in such a way that "ea" releases act, more or less, as
> glorified snapshots which are indeed released to Maven Central but the
> "regular" releases are not there. The reason behind this is that "regular"
> releases are published only for customers who pay to the company behind
> this project and they offer commercial support for that.
>
> "regular" releases are meant to get all the bug fixes after "ea" is
> published and they are official stable releases. On the other hand "ea"
> releases are the ones where the development happens and every now and then,
> once the developers think that it is time to cut new 2.x, they just publish
> that privately.
>
> I was investigating how this all works here (3) and while they said that,
> I quote (4):
>
> "In my experience this is consumed by a large number of open source
> projects reliably (for our other artifacts too). This development/ea branch
> still goes through an extensive test suite prior to release. Releases from
> this branch will contain the latest features and bug fixes."
>
> I am not completely sure if we are OK with this. For the record, Mick is
> not overly comfortable with that and Brandon would prefer to just replace
> it / get rid of this dependency (comments / reasons / discussion from (5)
> to the end)
>
> The question is if we are OK with how things are and if we are then what
> are the rules when upgrading the version of this project in Cassandra in
> the context of "ea" versions they publish.
>
> If we are not OK with this, then the question is what we are going to
> replace it with.
>
> If we are going to replace it, I very briefly took a look and there is
> practically nothing out there which would hit all the buttons for us.
> Chronicle is just perfect for this job and I am not a fan of rewriting this
> at all.
>
> I would like to have this resolved because there is CEP-12 I plan to
> deliver and I hit this and I do not want to base that work on something we
> might eventually abandon. There are some ideas for CEP-12 how to bypass
> this without using Chronicle but I would like to firstly hear your opinion.
>
> Regards
>
> (1) https://github.com/OpenHFT/Chronicle-Queue
> (2) https://repo1.maven.org/maven2/net/openhft/chronicle-core/
> (3) https://github.com/OpenHFT/Chronicle-Core/issues/668
> (4)
> https://github.com/OpenHFT/Chronicle-Core/issues/668#issuecomment-2322038676
> (5)
> https://issues.apache.org/jira/browse/CASSANDRA-18712?focusedCommentId=17878254&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17878254
>

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

[Benedict]

Don’t we essentially just use it as a file format for storing a couple of kinds of append-only data?I was never entirely clear on the value it brought to the project.On 16 Sep 2024, at 22:11, Jordan West  wrote:Thanks for the sleuthing Stefan! This definitely is a bit unfortunate. It sounds like a replacement is not really practical so I'll ignore that option for now, until a viable alternative is proposed. I am -1 on us writing our own without strong, strong justification -- primarily because I think the likelihood is we introduce more bugs before getting to something stable. Regarding the remaining options, mostly some thoughts:- it would be nice to have some specific evidence of other projects using the EA versions and what their developers have said about it.- it sounds like if we go with the EA route, the onus to test for correctness / compatibility increases. They do test but anything marked "early access" I think deserves more scrutiny from the C* community before release. That could come in the form of more tests (or showing that we already have good coverage of where its used).- i assume each time we upgrade we would pick the most recently released EA versionJordanOn Mon, Sep 16, 2024 at 1:46 PM Štefan Miklošovič  wrote:We are using a library called Chronicle Queue (1) and its dependencies and we ship them in the distribution tarball.The version we use in 5.0 / trunk as I write this is 2.23.36. If you look closely here (2), there is one more release like this, 2.23.37 and after that all these releases have "ea" in their name."ea" stands for "early access". The project has changed the versioning / development model in such a way that "ea" releases act, more or less, as glorified snapshots which are indeed released to Maven Central but the "regular" releases are not there. The reason behind this is that "regular" releases are published only for customers who pay to the company behind this project and they offer commercial support for that."regular" releases are meant to get all the bug fixes after "ea" is published and they are official stable releases. On the other hand "ea" releases are the ones where the development happens and every now and then, once the developers think that it is time to cut new 2.x, they just publish that privately.I was investigating how this all works here (3) and while they said that, I quote (4):"In my experience this is consumed by a large number of open source projects reliably (for our other artifacts too). This development/ea branch still goes through an extensive test suite prior to release. Releases from this branch will contain the latest features and bug fixes."I am not completely sure if we are OK with this. For the record, Mick is not overly comfortable with that and Brandon would prefer to just replace it / get rid of this dependency (comments / reasons / discussion from (5) to the end)The question is if we are OK with how things are and if we are then what are the rules when upgrading the version of this project in Cassandra in the context of "ea" versions they publish.If we are not OK with this, then the question is what we are going to replace it with.If we are going to replace it, I very briefly took a look and there is practically nothing out there which would hit all the buttons for us. Chronicle is just perfect for this job and I am not a fan of rewriting this at all. I would like to have this resolved because there is CEP-12 I plan to deliver and I hit this and I do not want to base that work on something we might eventually abandon. There are some ideas for CEP-12 how to bypass this without using Chronicle but I would like to firstly hear your opinion.Regards(1) https://github.com/OpenHFT/Chronicle-Queue(2) https://repo1.maven.org/maven2/net/openhft/chronicle-core/(3) https://github.com/OpenHFT/Chronicle-Core/issues/668(4) https://github.com/OpenHFT/Chronicle-Core/issues/668#issuecomment-2322038676(5) https://issues.apache.org/jira/browse/CASSANDRA-18712?focusedCommentId=17878254&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17878254

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

[Josh McKenzie]

I think it's FQLTool only right now; I bumped into it recently doing the JDK21 
compat work.

I'm not concerned about current usage / dependency, but if our usage expands 
this could start to become a problem and that's going to be a hard thing to 
track and mange.

So reading through those issues Stefan, I think it boils down to:
 • The latest ea is code identical to the stable release
 • Subsequent bugfixes get applied to the customer-only stable branch *and one 
release forward*
 • Projects running ea releases would need to cherry-pick those bugfixes back 
or run on the next branch's ea, which could introduce the project to API 
changes or other risks
Assuming that's the case... blech. Our exposure is low, but that seems like a 
real pain.

On Mon, Sep 16, 2024, at 5:16 PM, Benedict wrote:
> 
> Don’t we essentially just use it as a file format for storing a couple of 
> kinds of append-only data?
> 
> I was never entirely clear on the value it brought to the project.
> 
> 
>> On 16 Sep 2024, at 22:11, Jordan West  wrote:
>> 
>> Thanks for the sleuthing Stefan! This definitely is a bit unfortunate. It 
>> sounds like a replacement is not really practical so I'll ignore that option 
>> for now, until a viable alternative is proposed. I am -1 on us writing our 
>> own without strong, strong justification -- primarily because I think the 
>> likelihood is we introduce more bugs before getting to something stable. 
>> 
>> Regarding the remaining options, mostly some thoughts:
>> 
>> - it would be nice to have some specific evidence of other projects using 
>> the EA versions and what their developers have said about it.
>> - it sounds like if we go with the EA route, the onus to test for 
>> correctness / compatibility increases. They do test but anything marked 
>> "early access" I think deserves more scrutiny from the C* community before 
>> release. That could come in the form of more tests (or showing that we 
>> already have good coverage of where its used).
>> - i assume each time we upgrade we would pick the most recently released EA 
>> version
>> 
>> Jordan
>> 
>> 
>> On Mon, Sep 16, 2024 at 1:46 PM Štefan Miklošovič  
>> wrote:
>>> We are using a library called Chronicle Queue (1) and its dependencies and 
>>> we ship them in the distribution tarball.
>>> 
>>> The version we use in 5.0 / trunk as I write this is 2.23.36. If you look 
>>> closely here (2), there is one more release like this, 2.23.37 and after 
>>> that all these releases have "ea" in their name.
>>> 
>>> "ea" stands for "early access". The project has changed the versioning / 
>>> development model in such a way that "ea" releases act, more or less, as 
>>> glorified snapshots which are indeed released to Maven Central but the 
>>> "regular" releases are not there. The reason behind this is that "regular" 
>>> releases are published only for customers who pay to the company behind 
>>> this project and they offer commercial support for that.
>>> 
>>> "regular" releases are meant to get all the bug fixes after "ea" is 
>>> published and they are official stable releases. On the other hand "ea" 
>>> releases are the ones where the development happens and every now and then, 
>>> once the developers think that it is time to cut new 2.x, they just publish 
>>> that privately.
>>> 
>>> I was investigating how this all works here (3) and while they said that, I 
>>> quote (4):
>>> 
>>> "In my experience this is consumed by a large number of open source 
>>> projects reliably (for our other artifacts too). This development/ea branch 
>>> still goes through an extensive test suite prior to release. Releases from 
>>> this branch will contain the latest features and bug fixes."
>>> 
>>> I am not completely sure if we are OK with this. For the record, Mick is 
>>> not overly comfortable with that and Brandon would prefer to just replace 
>>> it / get rid of this dependency (comments / reasons / discussion from (5) 
>>> to the end)
>>> 
>>> The question is if we are OK with how things are and if we are then what 
>>> are the rules when upgrading the version of this project in Cassandra in 
>>> the context of "ea" versions they publish.
>>> 
>>> If we are not OK with this, then the question is what we are going to 
>>> replace it with.
>>> 
>>> If we are going to replace it, I very briefly took a look and there is 
>>> practically nothing out there which would hit all the buttons for us. 
>>> Chronicle is just perfect for this job and I am not a fan of rewriting this 
>>> at all. 
>>> 
>>> I would like to have this resolved because there is CEP-12 I plan to 
>>> deliver and I hit this and I do not want to base that work on something we 
>>> might eventually abandon. There are some ideas for CEP-12 how to bypass 
>>> this without using Chronicle but I would like to firstly hear your opinion.
>>> 
>>> Regards
>>> 
>>> (1) https://github.com/OpenHFT/Chronicle-Queue
>>> (2) https://repo1.maven.org/maven2/net/openhft/chronicle-core/
>>> (3) https:

Re: [DISCUSS] Chronicle Queue's development model and a hypothetical replacement of the library

[Brandon Williams]

My concern is that we have to keep making sure it's not phoning home(1,2).

(1) https://issues.apache.org/jira/browse/CASSANDRA-18538
(2) https://issues.apache.org/jira/browse/CASSANDRA-19656

Kind Regards,
Brandon

On Mon, Sep 16, 2024 at 7:53 PM Josh McKenzie  wrote:
>
> I think it's FQLTool only right now; I bumped into it recently doing the 
> JDK21 compat work.
>
> I'm not concerned about current usage / dependency, but if our usage expands 
> this could start to become a problem and that's going to be a hard thing to 
> track and mange.
>
> So reading through those issues Stefan, I think it boils down to:
>
> The latest ea is code identical to the stable release
> Subsequent bugfixes get applied to the customer-only stable branch and one 
> release forward
> Projects running ea releases would need to cherry-pick those bugfixes back or 
> run on the next branch's ea, which could introduce the project to API changes 
> or other risks
>
> Assuming that's the case... blech. Our exposure is low, but that seems like a 
> real pain.
>
> On Mon, Sep 16, 2024, at 5:16 PM, Benedict wrote:
>
>
> Don’t we essentially just use it as a file format for storing a couple of 
> kinds of append-only data?
>
> I was never entirely clear on the value it brought to the project.
>
>
> On 16 Sep 2024, at 22:11, Jordan West  wrote:
>
> 
> Thanks for the sleuthing Stefan! This definitely is a bit unfortunate. It 
> sounds like a replacement is not really practical so I'll ignore that option 
> for now, until a viable alternative is proposed. I am -1 on us writing our 
> own without strong, strong justification -- primarily because I think the 
> likelihood is we introduce more bugs before getting to something stable.
>
> Regarding the remaining options, mostly some thoughts:
>
> - it would be nice to have some specific evidence of other projects using the 
> EA versions and what their developers have said about it.
> - it sounds like if we go with the EA route, the onus to test for correctness 
> / compatibility increases. They do test but anything marked "early access" I 
> think deserves more scrutiny from the C* community before release. That could 
> come in the form of more tests (or showing that we already have good coverage 
> of where its used).
> - i assume each time we upgrade we would pick the most recently released EA 
> version
>
> Jordan
>
>
> On Mon, Sep 16, 2024 at 1:46 PM Štefan Miklošovič  
> wrote:
>
> We are using a library called Chronicle Queue (1) and its dependencies and we 
> ship them in the distribution tarball.
>
> The version we use in 5.0 / trunk as I write this is 2.23.36. If you look 
> closely here (2), there is one more release like this, 2.23.37 and after that 
> all these releases have "ea" in their name.
>
> "ea" stands for "early access". The project has changed the versioning / 
> development model in such a way that "ea" releases act, more or less, as 
> glorified snapshots which are indeed released to Maven Central but the 
> "regular" releases are not there. The reason behind this is that "regular" 
> releases are published only for customers who pay to the company behind this 
> project and they offer commercial support for that.
>
> "regular" releases are meant to get all the bug fixes after "ea" is published 
> and they are official stable releases. On the other hand "ea" releases are 
> the ones where the development happens and every now and then, once the 
> developers think that it is time to cut new 2.x, they just publish that 
> privately.
>
> I was investigating how this all works here (3) and while they said that, I 
> quote (4):
>
> "In my experience this is consumed by a large number of open source projects 
> reliably (for our other artifacts too). This development/ea branch still goes 
> through an extensive test suite prior to release. Releases from this branch 
> will contain the latest features and bug fixes."
>
> I am not completely sure if we are OK with this. For the record, Mick is not 
> overly comfortable with that and Brandon would prefer to just replace it / 
> get rid of this dependency (comments / reasons / discussion from (5) to the 
> end)
>
> The question is if we are OK with how things are and if we are then what are 
> the rules when upgrading the version of this project in Cassandra in the 
> context of "ea" versions they publish.
>
> If we are not OK with this, then the question is what we are going to replace 
> it with.
>
> If we are going to replace it, I very briefly took a look and there is 
> practically nothing out there which would hit all the buttons for us. 
> Chronicle is just perfect for this job and I am not a fan of rewriting this 
> at all.
>
> I would like to have this resolved because there is CEP-12 I plan to deliver 
> and I hit this and I do not want to base that work on something we might 
> eventually abandon. There are some ideas for CEP-12 how to bypass this 
> without using Chronicle but I would like to firstly hear your opi