Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Jacek Lewandowski]

>
> If we end up not releasing a final 5.0 artifact by a Cassandra Summit it
> will signal to the community that we’re prioritizing stability and it could
> be a good opportunity to get people to test the beta or RC before we stamp
> it as production ready.
>

I agree with Paulo's comment

czw., 30 lis 2023 o 04:44 Paulo Motta  napisał(a):

> > if any contributor has an opinion which is not technically refuted it
> will usually be backed by a PMC via a binding -1
>
> clarifying a bit my personal view: if any contributor has an opinion
> against a proposal (in this case this release proposal) that is not refuted
> it will usually be backed by a PMC via binding -1
>
> Opinions supporting the proposal are also valuable, provided there are no
> valid claims against a proposal.
>
> On Wed, 29 Nov 2023 at 22:27 Paulo Motta  wrote:
>
>> To me, the goal of a beta is to find unknown bugs. If no new bugs are
>> found during a beta release, then it can be automatically promoted to RC
>> via re-tagging. Likewise, if no new bugs are found during a RC after X
>> time, then it can be promoted to final.
>>
>> If we end up not releasing a final 5.0 artifact by a Cassandra Summit it
>> will signal to the community that we’re prioritizing stability and it could
>> be a good opportunity to get people to test the beta or RC before we stamp
>> it as production ready.
>>
>> WDYT?
>>
>> >  Aaron (and anybody who takes the time to follow this list, really),
>> your opinion matters, that's why we discuss it here.
>>
>> +1, PMC are just officers who endorse community decisions, so if any
>> contributor has an opinion which is not technically refuted it will usually
>> be backed by a PMC via a binding -1 (as seen on this thread)
>>
>> On Wed, 29 Nov 2023 at 20:04 Nate McCall  wrote:
>>
>>>
>>>
>>> On Thu, Nov 30, 2023 at 3:28 AM Aleksey Yeshchenko 
>>> wrote:
>>>
 -1 on cutting a beta1 in this state. An alpha2 would be acceptable now,
 but I’m not sure there is significant value to be had from it. Merge the
 fixes for outstanding issues listed above, then cut beta1.

>>> 
>>>
>>> Agree with Aleksey. -1 on a beta we know has issues with a top-line new
>>> feature.
>>>
>>>
>>>
>>

Re: Downgradability

[guo Maxwell]

Hello everyone :
What is the final conclusion of this discuss ?

As https://issues.apache.org/jira/browse/CASSANDRA-18934 has been created ,
and we know that for system table of different c* version , the schema info
may be different as we may
add or delete column or modify the table properties in different versions.
For 18934 , because I have introduced a new column " compaction_properties"
for compaction_history table in 5.0. So the downgrade test to 4.1 failed at
the 4.1 node startup stage  due to  4.1’s code encountering an incompatible
persisted column "compaction_properties".

So now for me, I might want to know, which solution did everyone finally
decide to use for the sstable ?

1. Are our current downgrades intended to only support specific version
downgrades, like 5.0 -> 4.1 ?
2.Can we modify the low version code now ? that is say , if we add some
feature  for example in 4.1.0 and that means we may only support downgrade
to 4.1.1
3.If we choose to rewrite sstable, please help consider the differences in
system tables between different versions.

Jacek Lewandowski  于2023年3月6日周一 16:58写道：

> A bit of organization - I've created
> https://issues.apache.org/jira/browse/CASSANDRA-18300 epic to track
> tickets related to the downgradability. Please add the tickets you are
> aware of.
>
> thanks
> - - -- --- -  -
> Jacek Lewandowski
>
>
> czw., 23 lut 2023 o 17:47 Benedict  napisał(a):
>
>> Either way, it feels like this has become much more of a big deal than it
>> needed to.
>>
>> I would prefer the pending patches to avoid breaking compatibility, as I
>> think they can do it easily. But, if we agree to block release until we can
>> double back to fix it with versioned writing (which I agree with Jacek are
>> LHF - I think we literally just need a method that chooses the descriptor
>> version) then let’s not further agonise over this.
>>
>> Alternatively I’d be happy to work with the authors to get this done
>> alongside their work, as I don’t think it would hold anything up. We just
>> need something to pick a descriptor besides latest on write, everything
>> else is basically there for these patches.
>>
>>
>> On 23 Feb 2023, at 16:37, Henrik Ingo  wrote:
>>
>> 
>> Right. So I'm speculating everyone else who worked on a patch that breaks
>> compatibility has been working under the mindset "I'll just put this behind
>> the same switch". Or something more vague / even less correct, such as
>> assuming that tries would become the default immediately.
>>
>> At least in my mind when we talk about the "switch to enable tries" I do
>> also consider things like "don't break streaming". So I guess whether one
>> considers "a switch" to exist already or not, might be subjective in this
>> case, because people have different assumptions on the definition of done
>> of such a switch.
>>
>> henrik
>>
>> On Thu, Feb 23, 2023 at 2:53 PM Benedict  wrote:
>>
>>> I don’t think there’s anything about a new format that requires a
>>> version bump, but I could be missing something.
>>>
>>> We have to have a switch to enable tries already don’t we? I’m pretty
>>> sure we haven’t talked about switching the default format?
>>>
>>> On 23 Feb 2023, at 12:12, Henrik Ingo  wrote:
>>>
>>> 
>>> On Thu, Feb 23, 2023 at 11:57 AM Benedict  wrote:
>>>
 Can somebody explain to me why this is being fought tooth and nail,
 when the work involved is absolutely minimal?


>>> I don't know how each individual has been thinking about this, but it
>>> seems to me just looking at all the tasks that at least the introduction of
>>> tries is a major format change anyway - since it's the whole point - and
>>> therefore people working on other tasks may have assumed the format is
>>> changing anyway and therefore something like a switch (is this what is
>>> referred to as the C-8110 solution?) will take care of it for everyone.
>>>
>>> I'm not sure there's consensus that such a switch is a sufficient
>>> resolution to this discussion, but if there were such a consensus, the next
>>> question would be whether the patches that are otherwise ready now can
>>> merge, or whether they will all be blocked waiting for the compatibility
>>> solution first. And possibly better testing, etc. Letting them merge would
>>> be justified by the desire to have more frequent and smaller increments of
>>> work merged into trunk... well, I'm not going to repeat everything from
>>> that discussion but the same pro's and con's apply.
>>>
>>> henrik
>>> --
>>>
>>> Henrik Ingo
>>>
>>> c. +358 40 569 7354
>>>
>>> w. www.datastax.com
>>>
>>>
>>> 
>>> 
>>> 
>>> 

Fwd: Reminder: CFP for Community Over Code Europe is now open

[Paulo Motta]

There will be a Cassandra track at Community Over Code Europe 2024
(formerly known as Apachecon EU) that will happen on Bratislava, Slovakia
on 3 Jun 2024.

If you have any talks proposals about using, deploying or modifying Apache
Cassandra please make a submission before 12 Jan 2024 to speak at a top
European Open Source Software Engineering conference next year.

See information on submitting below.

-- Forwarded message -
From: 
Date: Wed, 29 Nov 2023 at 16:12
Subject: Reminder: CFP for Community Over Code Europe is now open
To: 


The Community track at Community Over Code Europe is currently open,
and will be open for just a little more than another month. We would
appreciate your submissions on all topics related to community at the
ASF. This includes governance, community building, working in and with
companies on ASF projects, policy, and other related topics.

Thanks!

https://sessionize.com/coceu-2024/

--Rich, for the Community Over Code planners


-
To unsubscribe, e-mail: dev-unsubscr...@community.apache.org
For additional commands, e-mail: dev-h...@community.apache.org

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Paulo Motta]

> if any contributor has an opinion which is not technically refuted it
will usually be backed by a PMC via a binding -1

clarifying a bit my personal view: if any contributor has an opinion
against a proposal (in this case this release proposal) that is not refuted
it will usually be backed by a PMC via binding -1

Opinions supporting the proposal are also valuable, provided there are no
valid claims against a proposal.

On Wed, 29 Nov 2023 at 22:27 Paulo Motta  wrote:

> To me, the goal of a beta is to find unknown bugs. If no new bugs are
> found during a beta release, then it can be automatically promoted to RC
> via re-tagging. Likewise, if no new bugs are found during a RC after X
> time, then it can be promoted to final.
>
> If we end up not releasing a final 5.0 artifact by a Cassandra Summit it
> will signal to the community that we’re prioritizing stability and it could
> be a good opportunity to get people to test the beta or RC before we stamp
> it as production ready.
>
> WDYT?
>
> >  Aaron (and anybody who takes the time to follow this list, really),
> your opinion matters, that's why we discuss it here.
>
> +1, PMC are just officers who endorse community decisions, so if any
> contributor has an opinion which is not technically refuted it will usually
> be backed by a PMC via a binding -1 (as seen on this thread)
>
> On Wed, 29 Nov 2023 at 20:04 Nate McCall  wrote:
>
>>
>>
>> On Thu, Nov 30, 2023 at 3:28 AM Aleksey Yeshchenko 
>> wrote:
>>
>>> -1 on cutting a beta1 in this state. An alpha2 would be acceptable now,
>>> but I’m not sure there is significant value to be had from it. Merge the
>>> fixes for outstanding issues listed above, then cut beta1.
>>>
>> 
>>
>> Agree with Aleksey. -1 on a beta we know has issues with a top-line new
>> feature.
>>
>>
>>
>

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Paulo Motta]

To me, the goal of a beta is to find unknown bugs. If no new bugs are found
during a beta release, then it can be automatically promoted to RC via
re-tagging. Likewise, if no new bugs are found during a RC after X time,
then it can be promoted to final.

If we end up not releasing a final 5.0 artifact by a Cassandra Summit it
will signal to the community that we’re prioritizing stability and it could
be a good opportunity to get people to test the beta or RC before we stamp
it as production ready.

WDYT?

>  Aaron (and anybody who takes the time to follow this list, really), your
opinion matters, that's why we discuss it here.

+1, PMC are just officers who endorse community decisions, so if any
contributor has an opinion which is not technically refuted it will usually
be backed by a PMC via a binding -1 (as seen on this thread)

On Wed, 29 Nov 2023 at 20:04 Nate McCall  wrote:

>
>
> On Thu, Nov 30, 2023 at 3:28 AM Aleksey Yeshchenko 
> wrote:
>
>> -1 on cutting a beta1 in this state. An alpha2 would be acceptable now,
>> but I’m not sure there is significant value to be had from it. Merge the
>> fixes for outstanding issues listed above, then cut beta1.
>>
> 
>
> Agree with Aleksey. -1 on a beta we know has issues with a top-line new
> feature.
>
>
>

Re: Pre-commit (devbranch) ci-cassandra.a.o on 5.0 and trunk unavailable

[Ekaterina Dimitrova]

Jenkins Trunk is also not running post commit at the moment - pending
https://issues.apache.org/jira/browse/CASSANDRA-19083

On Wed, 29 Nov 2023 at 3:38, Mick Semb Wever  wrote:

>
> For broader awareness.
>
> The debranch job on ci-cassandra.a.o: that used for pre-commit testing; is
> currently not available for patches against 5.0 and trunk.
>
> Restoring it is part of CASSANDRA-18594.  This was a priority up until
> recently, eta now is early January.
>
> Those that do not have circleci premium plan, or any other CI system, to
> use for testing patches, please reach out to me (or anyone with access) to
> get it run through circleci.
>

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Nate McCall]

On Thu, Nov 30, 2023 at 3:28 AM Aleksey Yeshchenko 
wrote:

> -1 on cutting a beta1 in this state. An alpha2 would be acceptable now,
> but I’m not sure there is significant value to be had from it. Merge the
> fixes for outstanding issues listed above, then cut beta1.
>


Agree with Aleksey. -1 on a beta we know has issues with a top-line new
feature.

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Nate McCall]

> Even though my opinion doesn't really count here, I do feel compelled to
> mention that:
>

Aaron (and anybody who takes the time to follow this list, really), your
opinion matters, that's why we discuss it here.

Cassandra Summit: Engage those networks!

[Patrick McFadin]

Hi everyone,

We are a couple of weeks away from Cassandra Summit. People get busy and
forget to register or miss that there is even a summit happening. Let's
make sure everyone who wants to go gets a chance!

 - If you are going, get on the social media of your choice and let
everyone know you'll be there. Use the hashtag #cassandrasmunnit
 - If you aren't going, you can still remind other folks that it's
happening and the talks you think they should check out.

Either way, here is the basic info to include in your post:

*Schedule:
https://events.linuxfoundation.org/cassandra-summit/program/schedule/
Register:
https://events.linuxfoundation.org/cassandra-summit/register/#register-now
Discount
code: 23CS20*

*One more thing! If you are going and reading this, reply to this email
with a "Going!" or "See you there!" I would love to see who will be there
in two weeks. *


*Patrick*

Nov. 30 Cassandra virtual meetup with MondayDB and PMC Chair

[Melissa Logan]

Tomorrow (Thursday, Nov. 30) please join the Cassandra community for talks
from:

   - mondayDB - Crafting a Database from Scratch with Liran Brimer
   - The State of the Cassandra Development Community with Josh McKenzie,
   Cassandra PMC Chair

How to join: https://www.meetup.com/cassandra-global/events/296224296/

Now available is yesterday's contributor meeting where we discussed 5.0
features, 3.xx, and busted some Cassandra myths:
https://www.youtube.com/watch?v=JSDivLidnOg

See you soon!

-- Forwarded message -
From: Melissa Logan 
Date: Wed, Nov 1, 2023 at 3:37 PM
Subject: November community meetings with mondayDB, PMC chair, and 5.0
To: , dev , <
market...@cassandra.apache.org>


Join us for our virtual community meetings in November including:

   - Tuesday, Nov. 28: 5.0 Release Preview
   - Thursday, Nov. 30: mondayDB - Crafting a Database from Scratch with
   Liran Brimer + The State of the Cassandra Development Community with Josh
   McKenzie

Register: https://www.meetup.com/cassandra-global/

Yesterday's contributor meeting with Piotr Kołaczkowski on the CQL NOT
operator is now available: https://www.youtube.com/watch?v=HMA1usuU888

And here is last week's Cassandra case study with Patrick Lee of Walmart:
https://youtu.be/zIHkSLYVvMM

See you in a few weeks!

Melissa

Re: [DISCUSSION] CASSANDRA-19001 - JRE vs JDK runtime

[Ekaterina Dimitrova]

Thanks, Mick

It seems that no one had objections to your suggestion so I will move
forward with that:

“I suggest, for expediency, to

- put a nice failure message in Sjk.java (e.g. "JDK required for this
nodetool command"),
- add a comment in cassandra.yaml in front of audit_logging_options stating
compatibility with JRE is unknown (referencing the jira issue), and
- add the jdk add-opens and add-exports only when jdk is detected (javac is
on path).”


On Tue, 21 Nov 2023 at 7:05, Mick Semb Wever  wrote:

>
>
>
>> Given we have functionality that depends on a JDK, and all our testing is
>> done with a JDK, I'm in favour of printing a warning that JDK is
>> recommended, from 5.0 onwards.  And before 5.0 just leaving things in the
>> state they are in.
>>
>
>
> Correction: ignore these two sentences.  They should have been deleted
> before I hit send.
>
>

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Caleb Rackliffe]

> So in the context of this thread, if I want to try out SAI for example, I
don't care as much about consistency edge cases around coordinators or
replicas or read repair.

That would apply to 19018, not 19011, which is a critical functionality
issue.

On Wed, Nov 29, 2023 at 12:49 PM Jeremy Hanna 
wrote:

> I want to just follow up with functional versus production-worthy.  If I'm
> a user interested in C* 5 and want to try it out as betas come out, I'm
> looking more for something functional and not perfect.  So in the context
> of this thread, if I want to try out SAI for example, I don't care as much
> about consistency edge cases around coordinators or replicas or read
> repair.  I care a lot about that for a RC or GA release but doing POCs with
> betas that have known edge case issues like that is fine IMO.
>
> I know this is likely a moot point for this release since the fixes are
> almost in, but I think just publishing beta 1 and then a follow up beta 2
> with those fixes would be fine in that context, if I understood the bugs
> correctly.
>
> On Nov 29, 2023, at 12:15 PM, Aaron Ploetz  wrote:
>
> Even though my opinion doesn't really count here, I do feel compelled to
> mention that:
>
>  - No one expects a "beta" release to be perfect, but it does signal that
> it is "close" to being ready.
>  - An "alpha" release is in fact a LOT scarier than a "beta" release.
>
> From a user perspective, if I was coaching dev teams on selecting a build
> based on newly available features, I would help them build up a dev/stage
> cluster based on a beta (and make the "beta" part very clear to them).
> However an alpha version just doesn't convey the same level of confidence.
> When I test out an "alpha" of anything, I fully expect some things to just
> be broken.
>
> As for cutting a beta for the Summit; it makes sense that we'd want to get
> some things fixed up before that. But it would also be great to be at the
> point where we have a beta ready for folks to take a look at. We absolutely
> could tell everyone to download the alpha and give it a spin. But more
> people will be likely to do that for a beta than for an alpha.
>
> Take that however you will.
>
> Thanks,
>
> Aaron
>
>
> On Wed, Nov 29, 2023 at 9:54 AM Aleksey Yeshchenko 
> wrote:
>
>> -1 on cutting a beta1 in this state. An alpha2 would be acceptable now,
>> but I’m not sure there is significant value to be had from it. Merge the
>> fixes for outstanding issues listed above, then cut beta1.
>>
>> With TCM and Accord pushed into 5.1, SAI is the headliner user-visible
>> feature. It is what we want users to test. If we are to drive more people
>> to test SAI, we should resolve the issues that we ourselves know of first.
>> Respect our users’ time and effort - don’t make them bump into known bugs.
>>
>> P.S. I don’t believe that ‘alpha' vs. ‘beta' really makes a significant
>> difference to people’s willingness to try out the build. For most folks
>> both feel too raw to play with, and most of the rest would be equally
>> adventurous enough for an alpha *or* a beta. This is just my gut feeling
>> vs. your gut feeling, in absence of hard data.
>>
>> On 28 Nov 2023, at 21:17, Mick Semb Wever  wrote:
>>
>>
>>
>> So then cutting an alpha2 is possible.
>>>
>>
>>
>> Possible, but still leaves alpha1 as our mitigation plan and alpha2 as
>> our best plan.  Doesn't seem worth it IMHO.
>>
>>
>>
>

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Jeremy Hanna]

I want to just follow up with functional versus production-worthy.  If I'm a 
user interested in C* 5 and want to try it out as betas come out, I'm looking 
more for something functional and not perfect.  So in the context of this 
thread, if I want to try out SAI for example, I don't care as much about 
consistency edge cases around coordinators or replicas or read repair.  I care 
a lot about that for a RC or GA release but doing POCs with betas that have 
known edge case issues like that is fine IMO.

I know this is likely a moot point for this release since the fixes are almost 
in, but I think just publishing beta 1 and then a follow up beta 2 with those 
fixes would be fine in that context, if I understood the bugs correctly.

> On Nov 29, 2023, at 12:15 PM, Aaron Ploetz  wrote:
> 
> Even though my opinion doesn't really count here, I do feel compelled to 
> mention that:
> 
>  - No one expects a "beta" release to be perfect, but it does signal that it 
> is "close" to being ready.
>  - An "alpha" release is in fact a LOT scarier than a "beta" release.
> 
> From a user perspective, if I was coaching dev teams on selecting a build 
> based on newly available features, I would help them build up a dev/stage 
> cluster based on a beta (and make the "beta" part very clear to them). 
> However an alpha version just doesn't convey the same level of confidence. 
> When I test out an "alpha" of anything, I fully expect some things to just be 
> broken.
> 
> As for cutting a beta for the Summit; it makes sense that we'd want to get 
> some things fixed up before that. But it would also be great to be at the 
> point where we have a beta ready for folks to take a look at. We absolutely 
> could tell everyone to download the alpha and give it a spin. But more people 
> will be likely to do that for a beta than for an alpha.
> 
> Take that however you will.
> 
> Thanks,
> 
> Aaron
> 
> 
> On Wed, Nov 29, 2023 at 9:54 AM Aleksey Yeshchenko  > wrote:
>> -1 on cutting a beta1 in this state. An alpha2 would be acceptable now, but 
>> I’m not sure there is significant value to be had from it. Merge the fixes 
>> for outstanding issues listed above, then cut beta1.
>> 
>> With TCM and Accord pushed into 5.1, SAI is the headliner user-visible 
>> feature. It is what we want users to test. If we are to drive more people to 
>> test SAI, we should resolve the issues that we ourselves know of first. 
>> Respect our users’ time and effort - don’t make them bump into known bugs.
>> 
>> P.S. I don’t believe that ‘alpha' vs. ‘beta' really makes a significant 
>> difference to people’s willingness to try out the build. For most folks both 
>> feel too raw to play with, and most of the rest would be equally adventurous 
>> enough for an alpha *or* a beta. This is just my gut feeling vs. your gut 
>> feeling, in absence of hard data.
>> 
>>> On 28 Nov 2023, at 21:17, Mick Semb Wever >> > wrote:
>>> 
>>> 
>>> 
 So then cutting an alpha2 is possible.
>>> 
>>> 
>>> Possible, but still leaves alpha1 as our mitigation plan and alpha2 as our 
>>> best plan.  Doesn't seem worth it IMHO.
>> 

Re: [VOTE] Release Apache Cassandra 5.0-beta1

[Aaron Ploetz]

Even though my opinion doesn't really count here, I do feel compelled to
mention that:

 - No one expects a "beta" release to be perfect, but it does signal that
it is "close" to being ready.
 - An "alpha" release is in fact a LOT scarier than a "beta" release.

>From a user perspective, if I was coaching dev teams on selecting a build
based on newly available features, I would help them build up a dev/stage
cluster based on a beta (and make the "beta" part very clear to them).
However an alpha version just doesn't convey the same level of confidence.
When I test out an "alpha" of anything, I fully expect some things to just
be broken.

As for cutting a beta for the Summit; it makes sense that we'd want to get
some things fixed up before that. But it would also be great to be at the
point where we have a beta ready for folks to take a look at. We absolutely
could tell everyone to download the alpha and give it a spin. But more
people will be likely to do that for a beta than for an alpha.

Take that however you will.

Thanks,

Aaron


On Wed, Nov 29, 2023 at 9:54 AM Aleksey Yeshchenko 
wrote:

> -1 on cutting a beta1 in this state. An alpha2 would be acceptable now,
> but I’m not sure there is significant value to be had from it. Merge the
> fixes for outstanding issues listed above, then cut beta1.
>
> With TCM and Accord pushed into 5.1, SAI is the headliner user-visible
> feature. It is what we want users to test. If we are to drive more people
> to test SAI, we should resolve the issues that we ourselves know of first.
> Respect our users’ time and effort - don’t make them bump into known bugs.
>
> P.S. I don’t believe that ‘alpha' vs. ‘beta' really makes a significant
> difference to people’s willingness to try out the build. For most folks
> both feel too raw to play with, and most of the rest would be equally
> adventurous enough for an alpha *or* a beta. This is just my gut feeling
> vs. your gut feeling, in absence of hard data.
>
> On 28 Nov 2023, at 21:17, Mick Semb Wever  wrote:
>
>
>
> So then cutting an alpha2 is possible.
>>
>
>
> Possible, but still leaves alpha1 as our mitigation plan and alpha2 as our
> best plan.  Doesn't seem worth it IMHO.
>
>
>

Re: [VOTE] Release Harry 0.0.2

[Francisco Guerrero]

+1

On 2023/11/29 11:14:29 Alex Petrov wrote:
> Even though we would like to bring harry in-tree, this is not an immediate 
> priority. Meanwhile, we need to unblock RPM builds for trunk, which means no 
> custom jars. We will have at least one more Harry release with outstanding 
> features to avoid any blocking. 
> 
> Proposing the test build of cassandra-harry 0.0.2 for release, for TCM 
> purposes.
> 
> Repository:
> https://gitbox.apache.org/repos/asf?p=cassandra-harry.git;a=shortlog;h=refs/tags/0.0.2
> 
> Candidate SHA:
> https://github.com/apache/cassandra-harry/commit/37761ce599242a34b027baff520e1185b7a7c3af
> tagged with 0.0.2
> 
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1320
> 
> Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB
> 
> Prominent changes:
> 
> [CASSANDRA-18768] Improvements / changes required for Transactional Metadata 
> testing:
>   * Add an ability to run sequential r/w for more deterministic 
> results
>   * Implement Network Topology Strategy
>   * Add all pds iterator to ops selector
>   * Make sure to log when detecting that a run starts against a dirty 
> table
>   * Fix a concurrency issue with reorder buffer
>   * Add some safety wheels / debugging instruments
>   * Add a pd selector symmetry test
>   * Make it simpler to write and log
>   * Rename sequential rw to write before read
>   * Avoid starving writers by readers and vice versa
>   * Add a minimal guide for debugging falsifications
>   * Fix select peers query for local state checker
>   * Add examples for programmatic configuration
> 
> [CASSANDRA-18318] Implement parsing schema provider
> [CASSANDRA-18315] Trigger exception if we run out of partitions
> [CASSANDRA-17603] Allow selecting subsets of columns and wilcard queries.
> [CASSANDRA-17603] Open API for hand-crafting both mutation and read queries
> [CASSANDRA-17603] Make it possible to run multiple Harry runners concurrently 
> against the same keyspace
> [CASSANDRA-17603] Implement concurrent quiescent checker
> [CASSANDRA-17603] Pull in token util from Cassandra to avoid circular 
> dependency
> [CASSANDRA-17603] Pull in Cassandra concurrent utils until there is a common 
> shared library
> 
> 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: [VOTE] Release Harry 0.0.2

[Josh McKenzie]

+1

On Wed, Nov 29, 2023, at 7:03 AM, Brandon Williams wrote:
> +1
> 
> Kind Regards,
> Brandon
> 
> On Wed, Nov 29, 2023 at 5:15 AM Alex Petrov  wrote:
> >
> > Even though we would like to bring harry in-tree, this is not an immediate 
> > priority. Meanwhile, we need to unblock RPM builds for trunk, which means 
> > no custom jars. We will have at least one more Harry release with 
> > outstanding features to avoid any blocking.
> >
> > Proposing the test build of cassandra-harry 0.0.2 for release, for TCM 
> > purposes.
> >
> > Repository:
> > https://gitbox.apache.org/repos/asf?p=cassandra-harry.git;a=shortlog;h=refs/tags/0.0.2
> >
> > Candidate SHA:
> > https://github.com/apache/cassandra-harry/commit/37761ce599242a34b027baff520e1185b7a7c3af
> > tagged with 0.0.2
> >
> > Artifacts:
> > https://repository.apache.org/content/repositories/orgapachecassandra-1320
> >
> > Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB
> >
> > Prominent changes:
> >
> > [CASSANDRA-18768] Improvements / changes required for Transactional 
> > Metadata testing:
> >   * Add an ability to run sequential r/w for more deterministic 
> > results
> >   * Implement Network Topology Strategy
> >   * Add all pds iterator to ops selector
> >   * Make sure to log when detecting that a run starts against a 
> > dirty table
> >   * Fix a concurrency issue with reorder buffer
> >   * Add some safety wheels / debugging instruments
> >   * Add a pd selector symmetry test
> >   * Make it simpler to write and log
> >   * Rename sequential rw to write before read
> >   * Avoid starving writers by readers and vice versa
> >   * Add a minimal guide for debugging falsifications
> >   * Fix select peers query for local state checker
> >   * Add examples for programmatic configuration
> >
> > [CASSANDRA-18318] Implement parsing schema provider
> > [CASSANDRA-18315] Trigger exception if we run out of partitions
> > [CASSANDRA-17603] Allow selecting subsets of columns and wilcard queries.
> > [CASSANDRA-17603] Open API for hand-crafting both mutation and read queries
> > [CASSANDRA-17603] Make it possible to run multiple Harry runners 
> > concurrently against the same keyspace
> > [CASSANDRA-17603] Implement concurrent quiescent checker
> > [CASSANDRA-17603] Pull in token util from Cassandra to avoid circular 
> > dependency
> > [CASSANDRA-17603] Pull in Cassandra concurrent utils until there is a 
> > common shared library
> >
> > 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: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[Andrés de la Peña]

Congrats Francisco!

On Wed, 29 Nov 2023 at 11:37, Benjamin Lerer  wrote:

> Congratulations!!! Well deserved!
>
> Le mer. 29 nov. 2023 à 07:31, Berenguer Blasi 
> a écrit :
>
>> Welcome!
>> On 29/11/23 2:24, guo Maxwell wrote:
>>
>> Congrats!
>>
>> Jacek Lewandowski  于2023年11月29日周三 06:16写道：
>>
>>> Congrats!!!
>>>
>>> wt., 28 lis 2023, 23:08 użytkownik Abe Ratnofsky  napisał:
>>>
 Congrats Francisco!

 > On Nov 28, 2023, at 1:56 PM, C. Scott Andreas 
 wrote:
 >
 > Congratulations, Francisco!
 >
 > - Scott
 >
 >> On Nov 28, 2023, at 10:53 AM, Dinesh Joshi 
 wrote:
 >>
 >> The PMC members are pleased to announce that Francisco Guerrero
 Hernandez has accepted
 >> the invitation to become committer today.
 >>
 >> Congratulations and welcome!
 >>
 >> The Apache Cassandra PMC members

Re: [DISCUSS] Harry in-tree

[Aleksey Yeshchenko]

+1

> On 29 Nov 2023, at 07:23, Marcus Eriksson  wrote:
> 
> +1!
> 
> /Marcus
> 
> On Fri, Nov 24, 2023 at 04:43:36PM +0100, Alex Petrov wrote:
>> Hi everyone,
>> 
>> With TCM landed, there will be way more Harry tests in-tree: we are using it 
>> for many coordination tests, and there's now a simulator test that uses 
>> Harry. During development, Harry has allowed us to uncover and resolve 
>> numerous elusive edge cases.
>> 
>> I had conversations with several folks, and wanted to propose to move 
>> harry-core to Cassandra test tree. This will substantially 
>> simplify/streamline co-development of Cassandra and Harry. With a new 
>> HistoryBuilder API that has helped to find and trigger [1] [2] and [3], it 
>> will also be much more approachable.
>> 
>> Besides making it easier for everyone to develop new fuzz tests, it will 
>> also substantially lower the barrier to entry. Currently, debugging an issue 
>> found by Harry involves a cumbersome process of rebuilding and transferring 
>> jars between Cassandra and Harry, depending on which side you modify. This 
>> not only hampers efficiency but also deters broader adoption. By merging 
>> harry-core into the Cassandra test tree, we eliminate this barrier.
>> 
>> Thank you,
>> --Alex
>> 
>> [1] https://issues.apache.org/jira/browse/CASSANDRA-19011
>> [2] https://issues.apache.org/jira/browse/CASSANDRA-18993
>> [3] https://issues.apache.org/jira/browse/CASSANDRA-18932

Re: [VOTE] Release Harry 0.0.2

[Brandon Williams]

+1

Kind Regards,
Brandon

On Wed, Nov 29, 2023 at 5:15 AM Alex Petrov  wrote:
>
> Even though we would like to bring harry in-tree, this is not an immediate 
> priority. Meanwhile, we need to unblock RPM builds for trunk, which means no 
> custom jars. We will have at least one more Harry release with outstanding 
> features to avoid any blocking.
>
> Proposing the test build of cassandra-harry 0.0.2 for release, for TCM 
> purposes.
>
> Repository:
> https://gitbox.apache.org/repos/asf?p=cassandra-harry.git;a=shortlog;h=refs/tags/0.0.2
>
> Candidate SHA:
> https://github.com/apache/cassandra-harry/commit/37761ce599242a34b027baff520e1185b7a7c3af
> tagged with 0.0.2
>
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1320
>
> Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB
>
> Prominent changes:
>
> [CASSANDRA-18768] Improvements / changes required for Transactional Metadata 
> testing:
>   * Add an ability to run sequential r/w for more deterministic 
> results
>   * Implement Network Topology Strategy
>   * Add all pds iterator to ops selector
>   * Make sure to log when detecting that a run starts against a dirty 
> table
>   * Fix a concurrency issue with reorder buffer
>   * Add some safety wheels / debugging instruments
>   * Add a pd selector symmetry test
>   * Make it simpler to write and log
>   * Rename sequential rw to write before read
>   * Avoid starving writers by readers and vice versa
>   * Add a minimal guide for debugging falsifications
>   * Fix select peers query for local state checker
>   * Add examples for programmatic configuration
>
> [CASSANDRA-18318] Implement parsing schema provider
> [CASSANDRA-18315] Trigger exception if we run out of partitions
> [CASSANDRA-17603] Allow selecting subsets of columns and wilcard queries.
> [CASSANDRA-17603] Open API for hand-crafting both mutation and read queries
> [CASSANDRA-17603] Make it possible to run multiple Harry runners concurrently 
> against the same keyspace
> [CASSANDRA-17603] Implement concurrent quiescent checker
> [CASSANDRA-17603] Pull in token util from Cassandra to avoid circular 
> dependency
> [CASSANDRA-17603] Pull in Cassandra concurrent utils until there is a common 
> shared library
>
> 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: [VOTE] Release Harry 0.0.2

[Aleksey Yeshchenko]

+1

> On 29 Nov 2023, at 11:35, Sam Tunnicliffe  wrote:
> 
> +1
> 
>> On 29 Nov 2023, at 11:14, Alex Petrov  wrote:
>> 
>> Even though we would like to bring harry in-tree, this is not an immediate 
>> priority. Meanwhile, we need to unblock RPM builds for trunk, which means no 
>> custom jars. We will have at least one more Harry release with outstanding 
>> features to avoid any blocking. 
>> 
>> Proposing the test build of cassandra-harry 0.0.2 for release, for TCM 
>> purposes.
>> 
>> Repository:
>> https://gitbox.apache.org/repos/asf?p=cassandra-harry.git;a=shortlog;h=refs/tags/0.0.2
>> 
>> Candidate SHA:
>> https://github.com/apache/cassandra-harry/commit/37761ce599242a34b027baff520e1185b7a7c3af
>> tagged with 0.0.2
>> 
>> Artifacts:
>> https://repository.apache.org/content/repositories/orgapachecassandra-1320
>> 
>> Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB
>> 
>> Prominent changes:
>> 
>> [CASSANDRA-18768] Improvements / changes required for Transactional Metadata 
>> testing:
>>   * Add an ability to run sequential r/w for more deterministic 
>> results
>>   * Implement Network Topology Strategy
>>   * Add all pds iterator to ops selector
>>   * Make sure to log when detecting that a run starts against a 
>> dirty table
>>   * Fix a concurrency issue with reorder buffer
>>   * Add some safety wheels / debugging instruments
>>   * Add a pd selector symmetry test
>>   * Make it simpler to write and log
>>   * Rename sequential rw to write before read
>>   * Avoid starving writers by readers and vice versa
>>   * Add a minimal guide for debugging falsifications
>>   * Fix select peers query for local state checker
>>   * Add examples for programmatic configuration
>> 
>> [CASSANDRA-18318] Implement parsing schema provider
>> [CASSANDRA-18315] Trigger exception if we run out of partitions
>> [CASSANDRA-17603] Allow selecting subsets of columns and wilcard queries.
>> [CASSANDRA-17603] Open API for hand-crafting both mutation and read queries
>> [CASSANDRA-17603] Make it possible to run multiple Harry runners 
>> concurrently against the same keyspace
>> [CASSANDRA-17603] Implement concurrent quiescent checker
>> [CASSANDRA-17603] Pull in token util from Cassandra to avoid circular 
>> dependency
>> [CASSANDRA-17603] Pull in Cassandra concurrent utils until there is a common 
>> shared library
>> 
>> 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: [VOTE] Release Apache Cassandra 5.0-beta1

[Aleksey Yeshchenko]

-1 on cutting a beta1 in this state. An alpha2 would be acceptable now, but I’m 
not sure there is significant value to be had from it. Merge the fixes for 
outstanding issues listed above, then cut beta1.

With TCM and Accord pushed into 5.1, SAI is the headliner user-visible feature. 
It is what we want users to test. If we are to drive more people to test SAI, 
we should resolve the issues that we ourselves know of first. Respect our 
users’ time and effort - don’t make them bump into known bugs.

P.S. I don’t believe that ‘alpha' vs. ‘beta' really makes a significant 
difference to people’s willingness to try out the build. For most folks both 
feel too raw to play with, and most of the rest would be equally adventurous 
enough for an alpha *or* a beta. This is just my gut feeling vs. your gut 
feeling, in absence of hard data.

> On 28 Nov 2023, at 21:17, Mick Semb Wever  wrote:
> 
> 
> 
>> So then cutting an alpha2 is possible.
> 
> 
> Possible, but still leaves alpha1 as our mitigation plan and alpha2 as our 
> best plan.  Doesn't seem worth it IMHO.

Re: Welcome Francisco Guerrero Hernandez as Cassandra Committer

[Benjamin Lerer]

Congratulations!!! Well deserved!

Le mer. 29 nov. 2023 à 07:31, Berenguer Blasi  a
écrit :

> Welcome!
> On 29/11/23 2:24, guo Maxwell wrote:
>
> Congrats!
>
> Jacek Lewandowski  于2023年11月29日周三 06:16写道：
>
>> Congrats!!!
>>
>> wt., 28 lis 2023, 23:08 użytkownik Abe Ratnofsky  napisał:
>>
>>> Congrats Francisco!
>>>
>>> > On Nov 28, 2023, at 1:56 PM, C. Scott Andreas 
>>> wrote:
>>> >
>>> > Congratulations, Francisco!
>>> >
>>> > - Scott
>>> >
>>> >> On Nov 28, 2023, at 10:53 AM, Dinesh Joshi  wrote:
>>> >>
>>> >> The PMC members are pleased to announce that Francisco Guerrero
>>> Hernandez has accepted
>>> >> the invitation to become committer today.
>>> >>
>>> >> Congratulations and welcome!
>>> >>
>>> >> The Apache Cassandra PMC members
>>>
>>>

Re: [VOTE] Release Harry 0.0.2

[Sam Tunnicliffe]

+1

> On 29 Nov 2023, at 11:14, Alex Petrov  wrote:
> 
> Even though we would like to bring harry in-tree, this is not an immediate 
> priority. Meanwhile, we need to unblock RPM builds for trunk, which means no 
> custom jars. We will have at least one more Harry release with outstanding 
> features to avoid any blocking. 
> 
> Proposing the test build of cassandra-harry 0.0.2 for release, for TCM 
> purposes.
> 
> Repository:
> https://gitbox.apache.org/repos/asf?p=cassandra-harry.git;a=shortlog;h=refs/tags/0.0.2
> 
> Candidate SHA:
> https://github.com/apache/cassandra-harry/commit/37761ce599242a34b027baff520e1185b7a7c3af
> tagged with 0.0.2
> 
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1320
> 
> Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB
> 
> Prominent changes:
> 
> [CASSANDRA-18768] Improvements / changes required for Transactional Metadata 
> testing:
>   * Add an ability to run sequential r/w for more deterministic 
> results
>   * Implement Network Topology Strategy
>   * Add all pds iterator to ops selector
>   * Make sure to log when detecting that a run starts against a dirty 
> table
>   * Fix a concurrency issue with reorder buffer
>   * Add some safety wheels / debugging instruments
>   * Add a pd selector symmetry test
>   * Make it simpler to write and log
>   * Rename sequential rw to write before read
>   * Avoid starving writers by readers and vice versa
>   * Add a minimal guide for debugging falsifications
>   * Fix select peers query for local state checker
>   * Add examples for programmatic configuration
> 
> [CASSANDRA-18318] Implement parsing schema provider
> [CASSANDRA-18315] Trigger exception if we run out of partitions
> [CASSANDRA-17603] Allow selecting subsets of columns and wilcard queries.
> [CASSANDRA-17603] Open API for hand-crafting both mutation and read queries
> [CASSANDRA-17603] Make it possible to run multiple Harry runners concurrently 
> against the same keyspace
> [CASSANDRA-17603] Implement concurrent quiescent checker
> [CASSANDRA-17603] Pull in token util from Cassandra to avoid circular 
> dependency
> [CASSANDRA-17603] Pull in Cassandra concurrent utils until there is a common 
> shared library
> 
> 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: [VOTE] Release Harry 0.0.2

[Marcus Eriksson]

+1

On Wed, Nov 29, 2023 at 12:14:29PM +0100, Alex Petrov wrote:
> Even though we would like to bring harry in-tree, this is not an immediate 
> priority. Meanwhile, we need to unblock RPM builds for trunk, which means no 
> custom jars. We will have at least one more Harry release with outstanding 
> features to avoid any blocking. 
> 
> Proposing the test build of cassandra-harry 0.0.2 for release, for TCM 
> purposes.
> 
> Repository:
> https://gitbox.apache.org/repos/asf?p=cassandra-harry.git;a=shortlog;h=refs/tags/0.0.2
> 
> Candidate SHA:
> https://github.com/apache/cassandra-harry/commit/37761ce599242a34b027baff520e1185b7a7c3af
> tagged with 0.0.2
> 
> Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1320
> 
> Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB
> 
> Prominent changes:
> 
> [CASSANDRA-18768] Improvements / changes required for Transactional Metadata 
> testing:
>   * Add an ability to run sequential r/w for more deterministic 
> results
>   * Implement Network Topology Strategy
>   * Add all pds iterator to ops selector
>   * Make sure to log when detecting that a run starts against a dirty 
> table
>   * Fix a concurrency issue with reorder buffer
>   * Add some safety wheels / debugging instruments
>   * Add a pd selector symmetry test
>   * Make it simpler to write and log
>   * Rename sequential rw to write before read
>   * Avoid starving writers by readers and vice versa
>   * Add a minimal guide for debugging falsifications
>   * Fix select peers query for local state checker
>   * Add examples for programmatic configuration
> 
> [CASSANDRA-18318] Implement parsing schema provider
> [CASSANDRA-18315] Trigger exception if we run out of partitions
> [CASSANDRA-17603] Allow selecting subsets of columns and wilcard queries.
> [CASSANDRA-17603] Open API for hand-crafting both mutation and read queries
> [CASSANDRA-17603] Make it possible to run multiple Harry runners concurrently 
> against the same keyspace
> [CASSANDRA-17603] Implement concurrent quiescent checker
> [CASSANDRA-17603] Pull in token util from Cassandra to avoid circular 
> dependency
> [CASSANDRA-17603] Pull in Cassandra concurrent utils until there is a common 
> shared library
> 
> 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-19113: Publishing dtest-shaded JARs on release

[Alex Petrov]

+1, we definitely need to start releasing jars, and preferrably doing it with 
some reasonable cadence / on demand. 

There is a slight problem with the fact we can not cut releases without votes, 
which, combined with the fact that we need sha-stable snapshots, makes it 
tricky. Best way to do this so far I could come up with is to just add short 
SHA as a snapshot prefix. This way no-one will override it by accident at least.

Meanwhile, since it'll take a bit of time to set everything up, there is a 
quick and easy way to do this, which is essentially what we do in Harry, if 
anyone needs this urgently:

if [ -z "${CASSANDRA_REPO}" ]; then 
CASSANDRA_REPO="g...@github.com:apache/cassandra.git"
fi

git clone -b trunk ${CLONE_REPO} cassandra

cd cassandra
./build-shaded-dtest-jar.sh

Script will also output the version it installs to local maven. 




On Tue, Nov 28, 2023, at 8:02 PM, Abe Ratnofsky wrote:
> Hey folks - wanted to raise a separate thread to discuss publishing of 
> dtest-shaded JARs on release.
> 
> Currently, adjacent projects that want to use the jvm-dtest framework need to 
> build the shaded JARs themselves. This is a decent amount of work, and is 
> duplicated across each project. This is mainly relevant for projects like 
> Sidecar and Driver. Currently, those projects need to clone and build 
> apache/cassandra themselves, run ant dtest-jar, and move the JAR into the 
> appropriate place. Different build systems treat local JARs differently, and 
> the whole process can be a bit complicated. Would be great to be able to 
> treat these as normal dependencies.
> 
> https://issues.apache.org/jira/browse/CASSANDRA-19113
> 
> Any objections?
> 
> --
> Abe

[VOTE] Release Harry 0.0.2

[Alex Petrov]

Even though we would like to bring harry in-tree, this is not an immediate 
priority. Meanwhile, we need to unblock RPM builds for trunk, which means no 
custom jars. We will have at least one more Harry release with outstanding 
features to avoid any blocking. 

Proposing the test build of cassandra-harry 0.0.2 for release, for TCM purposes.

Repository:
https://gitbox.apache.org/repos/asf?p=cassandra-harry.git;a=shortlog;h=refs/tags/0.0.2

Candidate SHA:
https://github.com/apache/cassandra-harry/commit/37761ce599242a34b027baff520e1185b7a7c3af
tagged with 0.0.2

Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1320

Key signature: A4C465FEA0C552561A392A61E91335D77E3E87CB

Prominent changes:

[CASSANDRA-18768] Improvements / changes required for Transactional Metadata 
testing:
  * Add an ability to run sequential r/w for more deterministic results
  * Implement Network Topology Strategy
  * Add all pds iterator to ops selector
  * Make sure to log when detecting that a run starts against a dirty 
table
  * Fix a concurrency issue with reorder buffer
  * Add some safety wheels / debugging instruments
  * Add a pd selector symmetry test
  * Make it simpler to write and log
  * Rename sequential rw to write before read
  * Avoid starving writers by readers and vice versa
  * Add a minimal guide for debugging falsifications
  * Fix select peers query for local state checker
  * Add examples for programmatic configuration

[CASSANDRA-18318] Implement parsing schema provider
[CASSANDRA-18315] Trigger exception if we run out of partitions
[CASSANDRA-17603] Allow selecting subsets of columns and wilcard queries.
[CASSANDRA-17603] Open API for hand-crafting both mutation and read queries
[CASSANDRA-17603] Make it possible to run multiple Harry runners concurrently 
against the same keyspace
[CASSANDRA-17603] Implement concurrent quiescent checker
[CASSANDRA-17603] Pull in token util from Cassandra to avoid circular dependency
[CASSANDRA-17603] Pull in Cassandra concurrent utils until there is a common 
shared library

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.

CASSANDRA-19054 – Community Catalyst Program

[Mick Semb Wever]

Raising for broader awareness, the project plans to announce a Catalyst
program in the next few days.  For further details please
see CASSANDRA-19054.

If you have any questions or concerns please raise them.

Re: [DISCUSS] CASSANDRA-19113: Publishing dtest-shaded JARs on release

[Mick Semb Wever]

>
> If you checked SHAs I suspect we would skip 90% of the dtests-jar builds
> in CI?
>

Yes.  The repeated building in each stage and split/container is nuts.
This can be solved in various ways, e.g. stashes, published snapshots, …
I think the stashing approach is simplest here, at the build stage at the
beginning of any ci pipeline.

Pre-commit (devbranch) ci-cassandra.a.o on 5.0 and trunk unavailable

[Mick Semb Wever]

For broader awareness.

The debranch job on ci-cassandra.a.o: that used for pre-commit testing; is
currently not available for patches against 5.0 and trunk.

Restoring it is part of CASSANDRA-18594.  This was a priority up until
recently, eta now is early January.

Those that do not have circleci premium plan, or any other CI system, to
use for testing patches, please reach out to me (or anyone with access) to
get it run through circleci.

Re: [DISCUSS] CASSANDRA-19113: Publishing dtest-shaded JARs on release

[Berenguer Blasi]

If you checked SHAs I suspect we would skip 90% of the dtests-jar builds 
in CI?


On 29/11/23 9:26, Mick Semb Wever wrote:


On Tue, 28 Nov 2023 at 20:06, Abe Ratnofsky  wrote:

Hey folks - wanted to raise a separate thread to discuss
publishing of dtest-shaded JARs on release.

Currently, adjacent projects that want to use the jvm-dtest
framework need to build the shaded JARs themselves. This is a
decent amount of work, and is duplicated across each project. This
is mainly relevant for projects like Sidecar and Driver.
Currently, those projects need to clone and build apache/cassandra
themselves, run ant dtest-jar, and move the JAR into the
appropriate place. Different build systems treat local JARs
differently, and the whole process can be a bit complicated. Would
be great to be able to treat these as normal dependencies.

https://issues.apache.org/jira/browse/CASSANDRA-19113

Any objections?



+1

But I am not sure this will save us from having to build the shared 
dtest jar for other branches in CI.


Compatibility breakages can come from a combination of changes that 
happen in different branches. I'd rather not be only catching these 
failures after a release has been made.  This is why the python dtests 
can do upgrade tests on both latest releases and branch heads.


I am in favour of seeing the jvm-dtest take both approaches, and for 
that it requires from published dtest-shaded jars.  (Also in favour of 
switching python dtests in our CI pipelines to 
use VersionSelectionStrategies.BOTH by default).

Re: [DISCUSS] CASSANDRA-19113: Publishing dtest-shaded JARs on release

[Mick Semb Wever]

On Tue, 28 Nov 2023 at 20:06, Abe Ratnofsky  wrote:

> Hey folks - wanted to raise a separate thread to discuss publishing of
> dtest-shaded JARs on release.
>
> Currently, adjacent projects that want to use the jvm-dtest framework need
> to build the shaded JARs themselves. This is a decent amount of work, and
> is duplicated across each project. This is mainly relevant for projects
> like Sidecar and Driver. Currently, those projects need to clone and build
> apache/cassandra themselves, run ant dtest-jar, and move the JAR into the
> appropriate place. Different build systems treat local JARs differently,
> and the whole process can be a bit complicated. Would be great to be able
> to treat these as normal dependencies.
>
> https://issues.apache.org/jira/browse/CASSANDRA-19113
>
> Any objections?
>


+1

But I am not sure this will save us from having to build the shared dtest
jar for other branches in CI.

Compatibility breakages can come from a combination of changes that happen
in different branches. I'd rather not be only catching these failures after
a release has been made.  This is why the python dtests can do upgrade
tests on both latest releases and branch heads.

I am in favour of seeing the jvm-dtest take both approaches, and for that
it requires from published dtest-shaded jars.  (Also in favour of switching
python dtests in our CI pipelines to use VersionSelectionStrategies.BOTH by
default).