[Discuss] Enabling JMX in in-jvm dtests (by default)

[Miklosovic, Stefan]

Hi list,

I want to gather a feedback for this comment (1).

Long story short, until JMX feature was introduced, we kind of hacked / mocked 
the calls to MBeans from IInstance, like this (2). If you notice, there is a 
lot of methods throwing UnsupportedOperationException because we had no proper 
JMX connection in place. That in turn means that tests which call nodetool 
commands which are using these MBeans / operations are not possible.

The fix I made in CASSANDRA-18572 will use JMX feature and it will hook 
nodetool to a proper JMX connection where we are not mocking anything etc ... 
It will use same stuff as in production.

However, this is happening only if one uses JMX feature. So all existing tests 
calling nodetool without this feature will still use it like it was. The patch 
I made takes care of both scenarios.

My question is if we should not make JMX feature turned on by default. That way 
we might further simplify the code base and get rid of the hacks. 

Another possibility is to not turn it on by default but we would add JMX 
feature to each test which is using nodetool. That would also mean that any 
future test which will use nodetool will fail if it does not have JMX feature 
enabled.

What would you like to see - dual solution (proper JMX connection if such 
feature is used as well as the legacy way) or only one solution with a proper 
JMX? (enabled by default or not).

Regards

(1) 
https://issues.apache.org/jira/browse/CASSANDRA-18572?focusedCommentId=17758920&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17758920
(2) 
https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/mock/nodetool/InternalNodeProbe.java

Re: [Discuss] Enabling JMX in in-jvm dtests (by default)

[Brandon Williams]

I would prefer to have one standard way to do it, and given the
options I would prefer it be proper JMX instead of mocking.

Kind Regards,
Brandon

On Fri, Aug 25, 2023 at 4:20 AM Miklosovic, Stefan
 wrote:
>
> Hi list,
>
> I want to gather a feedback for this comment (1).
>
> Long story short, until JMX feature was introduced, we kind of hacked / 
> mocked the calls to MBeans from IInstance, like this (2). If you notice, 
> there is a lot of methods throwing UnsupportedOperationException because we 
> had no proper JMX connection in place. That in turn means that tests which 
> call nodetool commands which are using these MBeans / operations are not 
> possible.
>
> The fix I made in CASSANDRA-18572 will use JMX feature and it will hook 
> nodetool to a proper JMX connection where we are not mocking anything etc ... 
> It will use same stuff as in production.
>
> However, this is happening only if one uses JMX feature. So all existing 
> tests calling nodetool without this feature will still use it like it was. 
> The patch I made takes care of both scenarios.
>
> My question is if we should not make JMX feature turned on by default. That 
> way we might further simplify the code base and get rid of the hacks.
>
> Another possibility is to not turn it on by default but we would add JMX 
> feature to each test which is using nodetool. That would also mean that any 
> future test which will use nodetool will fail if it does not have JMX feature 
> enabled.
>
> What would you like to see - dual solution (proper JMX connection if such 
> feature is used as well as the legacy way) or only one solution with a proper 
> JMX? (enabled by default or not).
>
> Regards
>
> (1) 
> https://issues.apache.org/jira/browse/CASSANDRA-18572?focusedCommentId=17758920&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17758920
> (2) 
> https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/mock/nodetool/InternalNodeProbe.java

Re: [Discuss] Enabling JMX in in-jvm dtests (by default)

[Doug Rohrer]

I’d agree that anywhere we’re calling `nodetoolResult` or `nodetool` in a test, 
it would be better to enable JMX and use it rather than the older mocks we set 
up to enable calling the mbeans directly. I don’t think enabling JMX by default 
is the right way to go mostly due to the added resources/time required to run 
the tests (it’s only a few seconds of additional startup/shutdown time, but 
when running lots of tests every second counts).  Also, all other features are 
only enabled when requested, so making JMX on by default would require us to 
change the general pattern and have a `without` method to turn off a feature?

Better, I think, just to require it to be explicitly turned on and then have 
the methods that call into nodetool on Instance just throw a clear exception if 
jmx is disabled.

Doug

> On Aug 25, 2023, at 6:35 AM, Brandon Williams  wrote:
> 
> I would prefer to have one standard way to do it, and given the
> options I would prefer it be proper JMX instead of mocking.
> 
> Kind Regards,
> Brandon
> 
> On Fri, Aug 25, 2023 at 4:20 AM Miklosovic, Stefan
>  wrote:
>> 
>> Hi list,
>> 
>> I want to gather a feedback for this comment (1).
>> 
>> Long story short, until JMX feature was introduced, we kind of hacked / 
>> mocked the calls to MBeans from IInstance, like this (2). If you notice, 
>> there is a lot of methods throwing UnsupportedOperationException because we 
>> had no proper JMX connection in place. That in turn means that tests which 
>> call nodetool commands which are using these MBeans / operations are not 
>> possible.
>> 
>> The fix I made in CASSANDRA-18572 will use JMX feature and it will hook 
>> nodetool to a proper JMX connection where we are not mocking anything etc 
>> ... It will use same stuff as in production.
>> 
>> However, this is happening only if one uses JMX feature. So all existing 
>> tests calling nodetool without this feature will still use it like it was. 
>> The patch I made takes care of both scenarios.
>> 
>> My question is if we should not make JMX feature turned on by default. That 
>> way we might further simplify the code base and get rid of the hacks.
>> 
>> Another possibility is to not turn it on by default but we would add JMX 
>> feature to each test which is using nodetool. That would also mean that any 
>> future test which will use nodetool will fail if it does not have JMX 
>> feature enabled.
>> 
>> What would you like to see - dual solution (proper JMX connection if such 
>> feature is used as well as the legacy way) or only one solution with a 
>> proper JMX? (enabled by default or not).
>> 
>> Regards
>> 
>> (1) 
>> https://issues.apache.org/jira/browse/CASSANDRA-18572?focusedCommentId=17758920&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17758920
>> (2) 
>> https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/mock/nodetool/InternalNodeProbe.java

[VOTE] Release Apache Cassandra 5.0-alpha1

[Mick Semb Wever]

Proposing the test build of Cassandra 5.0-alpha1 for release.

DISCLAIMER, this alpha release does not contain the expected 5.0
features: Vector Search (CEP-30), Transactional Cluster Metadata
(CEP-21) and Accord Transactions (CEP-15).  These features will land
in a later alpha release.

Please also note that this is an alpha release and what that means, further
info at
https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle

sha1: 62cb03cc7311384db6619a102d1da6a024653fa6
Git: https://github.com/apache/cassandra/tree/5.0-alpha1-tentative
Maven Artifacts:
https://repository.apache.org/content/repositories/orgapachecassandra-1314/org/apache/cassandra/cassandra-all/5.0-alpha1/

The Source and Build Artifacts, and the Debian and RPM packages and
repositories, are available here:
https://dist.apache.org/repos/dist/dev/cassandra/5.0-alpha1/

The vote will be open for 72 hours (longer if needed). 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 and no -1's.

[1]: CHANGES.txt:
https://github.com/apache/cassandra/blob/5.0-alpha1-tentative/CHANGES.txt
[2]: NEWS.txt:
https://github.com/apache/cassandra/blob/5.0-alpha1-tentative/NEWS.txt

Re: [VOTE] Release Apache Cassandra 5.0-alpha1

[Jeff Jirsa]

Given the disclaimer, can you just confirm why we'd cut an alpha now -
we're trying to lock protocols and give other people an integration target,
presumably?


On Fri, Aug 25, 2023 at 8:14 AM Mick Semb Wever  wrote:

>
> Proposing the test build of Cassandra 5.0-alpha1 for release.
>
> DISCLAIMER, this alpha release does not contain the expected 5.0
> features: Vector Search (CEP-30), Transactional Cluster Metadata
> (CEP-21) and Accord Transactions (CEP-15).  These features will land
> in a later alpha release.
>
> Please also note that this is an alpha release and what that means,
> further info at
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
>
> sha1: 62cb03cc7311384db6619a102d1da6a024653fa6
> Git: https://github.com/apache/cassandra/tree/5.0-alpha1-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1314/org/apache/cassandra/cassandra-all/5.0-alpha1/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/5.0-alpha1/
>
> The vote will be open for 72 hours (longer if needed). 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 and no -1's.
>
> [1]: CHANGES.txt:
> https://github.com/apache/cassandra/blob/5.0-alpha1-tentative/CHANGES.txt
> [2]: NEWS.txt:
> https://github.com/apache/cassandra/blob/5.0-alpha1-tentative/NEWS.txt
>

Re: [VOTE] Release Apache Cassandra 5.0-alpha1

[Ekaterina Dimitrova]

+1

On Fri, 25 Aug 2023 at 11:14, Mick Semb Wever  wrote:

>
> Proposing the test build of Cassandra 5.0-alpha1 for release.
>
> DISCLAIMER, this alpha release does not contain the expected 5.0
> features: Vector Search (CEP-30), Transactional Cluster Metadata
> (CEP-21) and Accord Transactions (CEP-15).  These features will land
> in a later alpha release.
>
> Please also note that this is an alpha release and what that means,
> further info at
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
>
> sha1: 62cb03cc7311384db6619a102d1da6a024653fa6
> Git: https://github.com/apache/cassandra/tree/5.0-alpha1-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1314/org/apache/cassandra/cassandra-all/5.0-alpha1/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/5.0-alpha1/
>
> The vote will be open for 72 hours (longer if needed). 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 and no -1's.
>
> [1]: CHANGES.txt:
> https://github.com/apache/cassandra/blob/5.0-alpha1-tentative/CHANGES.txt
> [2]: NEWS.txt:
> https://github.com/apache/cassandra/blob/5.0-alpha1-tentative/NEWS.txt
>

Re: [DISCUSSION] Shall we remove ant javadoc task?

[Ekaterina Dimitrova]

To close this one. The patch to fix javadoc and enable in CI under the ant
check the failure under broken javadoc is ready. After considering the
current project status, we decided to delay committing it until 5.0 is
feature complete and all bug CEPs are in.

Best regards,
Ekaterina

On Mon, 21 Aug 2023 at 15:30, Miklosovic, Stefan <
stefan.mikloso...@netapp.com> wrote:

> You can play with this in
>
> File -> Settings -> Editor -> Inspections -> Javadoc
>
> HTML problems in Javadoc -> Severity: Error
>
> This will mark invalid html rendering of Javadocs as errorneous.
>
> There are other checkboxes as well. I am not saying it solves it all but
> there is some room for tweaking this if one wishes.
>
> 
> From: Ekaterina Dimitrova 
> Sent: Monday, August 21, 2023 20:05
> To: dev@cassandra.apache.org
> Subject: Re: [DISCUSSION] Shall we remove ant javadoc task?
>
> NetApp Security WARNING: This is an external email. Do not click links or
> open attachments unless you recognize the sender and know the content is
> safe.
>
>
>
> My only slight concern is that almost all the errors fixed in
> CASSANDRA-18717 are such that they don’t trigger error or warning in the
> IDE. This means people will realize there is something to be done
> differently around javadoc only after they run the check task. I figured
> that before we commit to anything, it is good this point to be shared for
> visibility.
> Maxim highlighted for me that this is already the case with some of the
> other checks we already have added with checkstyle. He looks into the
> problem in CASSANDRA-18277, mentioning here in case there are committers
> with cycles to help push it through
>
> On Thu, 17 Aug 2023 at 12:46, Mick Semb Wever  m...@apache.org>> wrote:
> +1 to `ant check` (and to failing on it).
>
> On Thu, 17 Aug 2023 at 18:43, Ekaterina Dimitrova  > wrote:
> Agreed with Maxim. If we fail CI on the javadoc task, in my opinion it
> should be added to ant check probably.
>
> On Thu, 17 Aug 2023 at 12:40, Maxim Muzafarov  mmu...@apache.org>> wrote:
> We have "artifacts" ant target that depends on "checks" and "gen-doc",
> from my point of view, it would be nice to have the "artifacts"
> depending on "javadocs" as well. That way we can be sure that
> everything related is in good order.
>
> On Thu, 17 Aug 2023 at 18:05, Brandon Williams  dri...@gmail.com>> wrote:
> >
> > If everything is good now, I think CI should fail if it regresses so
> > we can keep it this way.
> >
> > Kind Regards,
> > Brandon
> >
> > On Thu, Aug 17, 2023 at 10:49 AM Ekaterina Dimitrova
> > mailto:e.dimitr...@gmail.com>> wrote:
> > >
> > > In CASSANDRA-18717 Maxim posted the javadoc fix. Stefan already made a
> first pass of review so it seems we are not removing this ant task as it
> was already fixed and there are people who find value of keeping it.
> > > My question is do we want to fail CI if this regress or not?
> > >
> > > On Thu, 3 Aug 2023 at 22:44, Josh McKenzie  > wrote:
> > >>
> > >> the problem is that the javadoc task is not given the attention
> > >> it deserves. The failonerror is currently 'false' and the task itself
> > >> is not a part of any build and/or release processes
> > >>
> > >>
> > >> I just wrote a tool that explores the distribution of keys across
> multiple sstables, I needed some of the tools classes but not much more.
> Javadocs would have made that easy
> > >>
> > >> You know what? I agree with all that. If I had to jump into the
> source for the JDK or other libraries every time I needed to work with them
> that'd be annoying.
> > >>
> > >> BTW, I have managed to fix all the javadoc errors.
> > >>
> > >> Of course you have. :) Industrious as usual Maxim; thanks for
> tackling that!
> > >>
> > >> So yeah. Depending on how long javadocs take to generate, I think
> having them as part of our pre-commit rotation makes sense. Could even add
> them to our site with something like an "API" section (gasp) here:
> https://cassandra.apache.org/doc/latest/<
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcassandra.apache.org%2Fdoc%2Flatest%2F&data=05%7C01%7CStefan.Miklosovic%40netapp.com%7Cd3af424ebf634336d60108dba2715985%7C4b0911a0929b4715944bc03745165b3a%7C0%7C0%7C638282379959793803%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vwCuMFhF6J6pqcSarzALSTe3ACEaVwkCpcOtSZ5wX9k%3D&reserved=0
> >.
> > >>
> > >> Would certainly help motivate us to clarify the whole "what is an
> external API we're committing to or not" discussions.
> > >>
> > >> On Thu, Aug 3, 2023, at 6:09 PM, Ekaterina Dimitrova wrote:
> > >>
> > >> Thank you Maxim. There is CASSANDRA-18717, I guess that patch should
> go there. Keeping the task or not, the fix of the docs should go in anyway
> IMHO. I will not be available the next few days, but I can help with
> reviews when I am back.
> > >>
> > >> On

Re: [VOTE] Release Apache Cassandra 5.0-alpha1

[C. Scott Andreas]

A snapshot artifact seems more appropriate for early testing to me, rather than a voted / released build issued by the project given how much has yet to land.- ScottOn Aug 25, 2023, at 8:46 AM, Ekaterina Dimitrova  wrote:+1On Fri, 25 Aug 2023 at 11:14, Mick Semb Wever  wrote:Proposing the test build of Cassandra 5.0-alpha1 for release.DISCLAIMER, this alpha release does not contain the expected 5.0features: Vector Search (CEP-30), Transactional Cluster Metadata(CEP-21) and Accord Transactions (CEP-15).  These features will landin a later alpha release.Please also note that this is an alpha release and what that means, further info at https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle sha1: 62cb03cc7311384db6619a102d1da6a024653fa6Git: https://github.com/apache/cassandra/tree/5.0-alpha1-tentativeMaven Artifacts: https://repository.apache.org/content/repositories/orgapachecassandra-1314/org/apache/cassandra/cassandra-all/5.0-alpha1/The Source and Build Artifacts, and the Debian and RPM packages and repositories, are available here: https://dist.apache.org/repos/dist/dev/cassandra/5.0-alpha1/The vote will be open for 72 hours (longer if needed). 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 and no -1's.[1]: CHANGES.txt: https://github.com/apache/cassandra/blob/5.0-alpha1-tentative/CHANGES.txt[2]: NEWS.txt: https://github.com/apache/cassandra/blob/5.0-alpha1-tentative/NEWS.txt

Re: [DISCUSSION] Dependency management in our first alpha release

[Ekaterina Dimitrova]

Thank you all. We are going to continue with those tickets and related
problems then.

On Maxim's question:
"Do we need a separate issue for 'org.caffinitas.ohc:ohc-core-j8' or we
should handle everything under [2]?"

It depends on whether someone has the time to sit and deal with the
complete list as soon as possible or we should do divide and conquer. It
will also require some archeology and potential discussions with users in
some cases, etc.

Best regards,
Ekaterina



On Wed, 23 Aug 2023 at 17:29, Abe Ratnofsky  wrote:

> > I also want to hear if Abe still has concerns about not following
> deprecation process here.
>
> I support removing the library on an expedited schedule, rather than
> waiting for a full major of deprecation. We still have a large surface for
> metrics integrations, and users who depended on metrics-reporter-config
> will have a path forward if they need similar functionality.
>
> On Aug 23, 2023, at 07:28, Ekaterina Dimitrova 
> wrote:
>
> I also want to hear if Abe still has concerns about not following
> deprecation process here.
>
>

Re: [VOTE] Release Apache Cassandra 5.0-alpha1

[German Eichberger via dev]

I concur. Those are major features...

From: C. Scott Andreas 
Sent: Friday, August 25, 2023 9:06 AM
To: dev@cassandra.apache.org 
Subject: [EXTERNAL] Re: [VOTE] Release Apache Cassandra 5.0-alpha1

You don't often get email from sc...@paradoxica.net. Learn why this is 
important
A snapshot artifact seems more appropriate for early testing to me, rather than 
a voted / released build issued by the project given how much has yet to land.

- Scott

On Aug 25, 2023, at 8:46 AM, Ekaterina Dimitrova  wrote:


+1

On Fri, 25 Aug 2023 at 11:14, Mick Semb Wever 
mailto:m...@apache.org>> wrote:

Proposing the test build of Cassandra 5.0-alpha1 for release.

DISCLAIMER, this alpha release does not contain the expected 5.0
features: Vector Search (CEP-30), Transactional Cluster Metadata
(CEP-21) and Accord Transactions (CEP-15).  These features will land
in a later alpha release.

Please also note that this is an alpha release and what that means, further 
info at https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle

sha1: 62cb03cc7311384db6619a102d1da6a024653fa6
Git: https://github.com/apache/cassandra/tree/5.0-alpha1-tentative
Maven Artifacts: 
https://repository.apache.org/content/repositories/orgapachecassandra-1314/org/apache/cassandra/cassandra-all/5.0-alpha1/

The Source and Build Artifacts, and the Debian and RPM packages and 
repositories, are available here: 
https://dist.apache.org/repos/dist/dev/cassandra/5.0-alpha1/

The vote will be open for 72 hours (longer if needed). 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 and no -1's.

[1]: CHANGES.txt: 
https://github.com/apache/cassandra/blob/5.0-alpha1-tentative/CHANGES.txt
[2]: NEWS.txt: 
https://github.com/apache/cassandra/blob/5.0-alpha1-tentative/NEWS.txt

Re: [Discuss] Enabling JMX in in-jvm dtests (by default)

[Miklosovic, Stefan]

Great. So, we are going to remove legacy solution / mocking of JMX, nodetool 
will interact only via a proper JMX connection and a developer is required to 
enable JMX feature to be able to execute nodetool commands. If JMX feature is 
not present an exception is thrown saying it has to be enabled to execute 
nodetool commands.


From: Doug Rohrer 
Sent: Friday, August 25, 2023 16:02
To: dev@cassandra.apache.org
Subject: Re: [Discuss] Enabling JMX in in-jvm dtests (by default)

You don't often get email from droh...@apple.com. Learn why this is 
important
NetApp Security WARNING: This is an external email. Do not click links or open 
attachments unless you recognize the sender and know the content is safe.



I’d agree that anywhere we’re calling `nodetoolResult` or `nodetool` in a test, 
it would be better to enable JMX and use it rather than the older mocks we set 
up to enable calling the mbeans directly. I don’t think enabling JMX by default 
is the right way to go mostly due to the added resources/time required to run 
the tests (it’s only a few seconds of additional startup/shutdown time, but 
when running lots of tests every second counts).  Also, all other features are 
only enabled when requested, so making JMX on by default would require us to 
change the general pattern and have a `without` method to turn off a feature?

Better, I think, just to require it to be explicitly turned on and then have 
the methods that call into nodetool on Instance just throw a clear exception if 
jmx is disabled.

Doug

On Aug 25, 2023, at 6:35 AM, Brandon Williams  wrote:

I would prefer to have one standard way to do it, and given the
options I would prefer it be proper JMX instead of mocking.

Kind Regards,
Brandon

On Fri, Aug 25, 2023 at 4:20 AM Miklosovic, Stefan
 wrote:

Hi list,

I want to gather a feedback for this comment (1).

Long story short, until JMX feature was introduced, we kind of hacked / mocked 
the calls to MBeans from IInstance, like this (2). If you notice, there is a 
lot of methods throwing UnsupportedOperationException because we had no proper 
JMX connection in place. That in turn means that tests which call nodetool 
commands which are using these MBeans / operations are not possible.

The fix I made in CASSANDRA-18572 will use JMX feature and it will hook 
nodetool to a proper JMX connection where we are not mocking anything etc ... 
It will use same stuff as in production.

However, this is happening only if one uses JMX feature. So all existing tests 
calling nodetool without this feature will still use it like it was. The patch 
I made takes care of both scenarios.

My question is if we should not make JMX feature turned on by default. That way 
we might further simplify the code base and get rid of the hacks.

Another possibility is to not turn it on by default but we would add JMX 
feature to each test which is using nodetool. That would also mean that any 
future test which will use nodetool will fail if it does not have JMX feature 
enabled.

What would you like to see - dual solution (proper JMX connection if such 
feature is used as well as the legacy way) or only one solution with a proper 
JMX? (enabled by default or not).

Regards

(1) 
https://issues.apache.org/jira/browse/CASSANDRA-18572?focusedCommentId=17758920&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17758920
(2) 
https://github.com/apache/cassandra/blob/trunk/test/distributed/org/apache/cassandra/distributed/mock/nodetool/InternalNodeProbe.java

Jira: Project logo with incorrect/no trademark

[Melissa Logan]

Hello:

The Cassandra logos on the ASF Project Logos page are outdated, as they
include lowercase letters and no trademark. This Jira request includes
logos to be replaced on the site, which requires a committer to publish:
https://issues.apache.org/jira/browse/CASSANDRA-18621

The logo on the main website also has the TM vs. R trademark. PR coming for
that soon.

This will ensure compliance with ASF branding policies, as well as enabling
third parties use the correct logo.

Thanks in advance to a committer who can help!

Melissa

New episode of The Apache Cassandra (R) Corner podcast!

[Aaron Ploetz]

Link to the next episode (video):
https://drive.google.com/file/d/1nu_h8JczmAI59GhnDunTI9Oew-TxmzNU/view?usp=sharing

s2e8 - Otavio Santana
(You may have to download it to play)

It will remain in staging for 72 hours, going live (assuming no objections)
by Monday, August 28th.

If anyone should have any questions or comments, or if you want to be a
guest, please reach out to me.

I am looking for additional guests.  So if you know someone who would be a
great guest, please let me know!

Thanks, everyone!

Aaron

Re: [VOTE] Release Apache Cassandra 5.0-alpha1

[Mick Semb Wever]

There was lazy consensus on this thread:
https://lists.apache.org/thread/mzj3dq8b7mzf60k6mkby88b9n9ywmsgw
 and also the announcement about the staged release was out for a longer
period of time to raise objections.

Not that it's too late to object, just that it's been raised for attention
twice now with no objections  :-)

For me, I'm keen to get it out simply because there's so many features
coming in 5.0 it helps bring a bit more awareness to each.  There's also a
bit of a wait for TCM (from what I've heard off-thread) and we want all the
testing we can get and it takes time to get people to come around to doing
it.


On Fri, 25 Aug 2023 at 10:36, German Eichberger via dev <
dev@cassandra.apache.org> wrote:

> I concur. Those are major features...
> --
> *From:* C. Scott Andreas 
> *Sent:* Friday, August 25, 2023 9:06 AM
> *To:* dev@cassandra.apache.org 
> *Subject:* [EXTERNAL] Re: [VOTE] Release Apache Cassandra 5.0-alpha1
>
> You don't often get email from sc...@paradoxica.net. Learn why this is
> important
> 
> A snapshot artifact seems more appropriate for early testing to me, rather
> than a voted / released build issued by the project given how much has yet
> to land.
>
> - Scott
>
> On Aug 25, 2023, at 8:46 AM, Ekaterina Dimitrova 
> wrote:
>
> 
> +1
>
> On Fri, 25 Aug 2023 at 11:14, Mick Semb Wever  wrote:
>
>
> Proposing the test build of Cassandra 5.0-alpha1 for release.
>
> DISCLAIMER, this alpha release does not contain the expected 5.0
> features: Vector Search (CEP-30), Transactional Cluster Metadata
> (CEP-21) and Accord Transactions (CEP-15).  These features will land
> in a later alpha release.
>
> Please also note that this is an alpha release and what that means,
> further info at
> https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle
>
> sha1: 62cb03cc7311384db6619a102d1da6a024653fa6
> Git: https://github.com/apache/cassandra/tree/5.0-alpha1-tentative
> Maven Artifacts:
> https://repository.apache.org/content/repositories/orgapachecassandra-1314/org/apache/cassandra/cassandra-all/5.0-alpha1/
>
> The Source and Build Artifacts, and the Debian and RPM packages and
> repositories, are available here:
> https://dist.apache.org/repos/dist/dev/cassandra/5.0-alpha1/
>
> The vote will be open for 72 hours (longer if needed). 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 and no -1's.
>
> [1]: CHANGES.txt:
> https://github.com/apache/cassandra/blob/5.0-alpha1-tentative/CHANGES.txt
> [2]: NEWS.txt:
> https://github.com/apache/cassandra/blob/5.0-alpha1-tentative/NEWS.txt
>
>

Re: [VOTE] Release Apache Cassandra 5.0-alpha1

[J. D. Jordan]

+1 nb.I think it’s good to get an alpha out there for people to starting trying out the features which are done.On Aug 25, 2023, at 4:03 PM, Mick Semb Wever  wrote:There was lazy consensus on this thread: https://lists.apache.org/thread/mzj3dq8b7mzf60k6mkby88b9n9ywmsgw  and also the announcement about the staged release was out for a longer period of time to raise objections.Not that it's too late to object, just that it's been raised for attention twice now with no objections  :-) For me, I'm keen to get it out simply because there's so many features coming in 5.0 it helps bring a bit more awareness to each.  There's also a bit of a wait for TCM (from what I've heard off-thread) and we want all the testing we can get and it takes time to get people to come around to doing it.On Fri, 25 Aug 2023 at 10:36, German Eichberger via dev  wrote:






I concur. Those are major features...


From: C. Scott Andreas 
Sent: Friday, August 25, 2023 9:06 AM
To: dev@cassandra.apache.org 
Subject: [EXTERNAL] Re: [VOTE] Release Apache Cassandra 5.0-alpha1
 








You don't often get email from sc...@paradoxica.net. 
Learn why this is important








A snapshot artifact seems more appropriate for early testing to me, rather than a voted / released build issued by the project given how much has yet to land.



- Scott

On Aug 25, 2023, at 8:46 AM, Ekaterina Dimitrova  wrote:





+1


On Fri, 25 Aug 2023 at 11:14, Mick Semb Wever  wrote:




Proposing the test build of Cassandra 5.0-alpha1 for release.


DISCLAIMER, this alpha release does not contain the expected 5.0
features: Vector Search (CEP-30), Transactional Cluster Metadata
(CEP-21) and Accord Transactions (CEP-15).  These features will land
in a later alpha release.


Please also note that this is an alpha release and what that means, further info at https://cwiki.apache.org/confluence/display/CASSANDRA/Release+Lifecycle 

sha1: 62cb03cc7311384db6619a102d1da6a024653fa6
Git:

https://github.com/apache/cassandra/tree/5.0-alpha1-tentative
Maven Artifacts:

https://repository.apache.org/content/repositories/orgapachecassandra-1314/org/apache/cassandra/cassandra-all/5.0-alpha1/

The Source and Build Artifacts, and the Debian and RPM packages and repositories, are available here:

https://dist.apache.org/repos/dist/dev/cassandra/5.0-alpha1/

The vote will be open for 72 hours (longer if needed). 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 and no -1's.

[1]: CHANGES.txt:

https://github.com/apache/cassandra/blob/5.0-alpha1-tentative/CHANGES.txt
[2]: NEWS.txt:

https://github.com/apache/cassandra/blob/5.0-alpha1-tentative/NEWS.txt