Re: [DISCUSSION] Adding BountyCastle as a test dependency

[Ekaterina Dimitrova]

As it seems there are no objections, we will continue with the addition of
this dependency, thank you

On Mon, 31 Jul 2023 at 11:41, Ekaterina Dimitrova 
wrote:

> Hi team,
> Probably most of you noticed that SSLFactoryTest unit tests fail now with
> JDK 17. Java 15 removed sun.security.x509 package. You can still generate
> a Self-Signed certificate using BouncyCastle by adding it to the classpath, 
> described
> in this issue  from the
> Netty community. We plan to add BountyCastle test dependency as part of
> CASSANDRA-17992, which will fix SSLFactoryTest. Please let us know if you
> have any questions or concerns.
> Best regards,
> Ekaterina
>

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

[Claude Warren, Jr via dev]

I think that we can get more developers interested if there are available
javadocs.  While many of the core classes are not going to be touched by
someone just starting, being able to understand what the external touch
points are and how they interact with other bits of the system can be
invaluable, particularly when you don't have the entire code base in front
of you.

For example, 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 if I did not have the source code
in front of me.

I am -1 on removing the javadocs.

On Thu, Aug 3, 2023 at 4:35 AM Josh McKenzie  wrote:

> If anything, the codebase could use a little more package/class/method
> markup in some places
>
> I am impressed with how diplomatic and generous you're being here Derek. :D
>
> On Wed, Aug 2, 2023, at 5:46 PM, Miklosovic, Stefan wrote:
>
> That is a good idea. I would like to have Javadocs valid when going
> through them in IDE. To enforce it, we would have to fix it first. If we
> find a way how to validate Javadocs without actually rendering them, that
> would be cool.
>
> There is a lot of legacy and rewriting of some custom-crafted formatting
> of some comments might be quite a tedious task to do if it is required to
> have them valid. I am in general for valid documentation and even enforcing
> it but what to do with what is already there ...
>
> 
> From: Jacek Lewandowski 
> Sent: Wednesday, August 2, 2023 23:38
> 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.
>
>
>
> With or without outputting JavaDoc to HTML, there are some errors which we
> should maybe fix. We want to keep the documentation, but there can be
> syntax errors which may prevent IDE generating a proper preview. So, the
> question is - should we validate the JavaDoc comments as a precommit task?
> Can it be done without actually generating HTML output?
>
> Thanks,
> Jacek
>
> śr., 2 sie 2023, 22:24 użytkownik Derek Chen-Becker  > napisał:
> Oh, whoops, I guess I'm the only one that thinks Javadoc is just the tool
> and/or it's output (not the markup itself) :P If anything, the codebase
> could use a little more package/class/method markup in some places, so I'm
> definitely only in favor of getting rid of the ant task. I should amend my
> statement to be "...I suspect most people are not opening their browsers
> and looking at Javadoc..." :)
>
> Cheers,
>
> Derek
>
>
>
> On Wed, Aug 2, 2023, 1:30 PM Josh McKenzie  jmcken...@apache.org>> wrote:
> most people are not looking at Javadoc when working on the codebase.
> I definitely use it extensively inside the IDE. But never as a compiled
> set of external docs.
>
> Which is to say, I'm +1 on removing the target and I'd ask everyone to
> keep javadoccing your classes and methods where things are non-obvious or
> there's a logical coupling with something else in the system. :)
>
> On Wed, Aug 2, 2023, at 2:08 PM, Derek Chen-Becker wrote:
> +1. If a need comes up for Javadoc we can fix it at that point, but I
> suspect most people are not looking at Javadoc when working on the codebase.
>
> Cheers,
>
> Derek
>
> On Wed, Aug 2, 2023 at 11:11 AM Brandon Williams  dri...@gmail.com>> wrote:
> I don't think even if it works anyone is going to use the output, so
> I'm good with removal.
>
> Kind Regards,
> Brandon
>
> On Wed, Aug 2, 2023 at 11:50 AM Ekaterina Dimitrova
> mailto:e.dimitr...@gmail.com>> wrote:
> >
> > Hi everyone,
> > We were looking into a user report around our ant javadoc task recently.
> > That made us realize it is not run in CI; it finishes successfully even
> if there are hundreds of errors, some potentially breaking doc pages.
> >
> > There was a ticket discussion where a few community members mentioned
> that this task was probably unnecessary. Can we remove it, or shall we fix
> it?
> >
> > Best regards,
> > Ekaterina
>
>
> --
> +---+
> | Derek Chen-Becker |
> | GPG Key available at https://keybase.io/dchenbecker<
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fkeybase.io%2Fdchenbecker&data=05%7C01%7CStefan.Miklosovic%40netapp.com%7C7ca04f0f58764996ab1e08db93a0de2a%7C4b0911a0929b4715944bc03745165b3a%7C0%7C0%7C638266091373361824%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=n%2BrDfikzzoQG%2Fg%2BRvNqEEE6vHP8ZmY1skeosesLK9v0%3D&reserved=0>
> and   |
> | https://pgp.mit.edu/pks/lookup?search=derek%40chen-becker.org<
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpgp.mit.edu%2Fpks%2Flookup%3Fsearch%3Dde

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

[Jeremiah Jordan]

 I don’t think anyone wants to remove the javadocs.  This thread is about
removing the broken ant task which generates html files from them.

+1 from me on removing the ant task.  If someone feels the task is useful
they can always implement one that does not crash and add it back.

-Jeremiah

On Aug 3, 2023 at 9:59:55 AM, "Claude Warren, Jr via dev" <
dev@cassandra.apache.org> wrote:

> I think that we can get more developers interested if there are available
> javadocs.  While many of the core classes are not going to be touched by
> someone just starting, being able to understand what the external touch
> points are and how they interact with other bits of the system can be
> invaluable, particularly when you don't have the entire code base in front
> of you.
>
> For example, 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 if I did not have the source code
> in front of me.
>
> I am -1 on removing the javadocs.
>
> On Thu, Aug 3, 2023 at 4:35 AM Josh McKenzie  wrote:
>
>> If anything, the codebase could use a little more package/class/method
>> markup in some places
>>
>> I am impressed with how diplomatic and generous you're being here Derek.
>> :D
>>
>> On Wed, Aug 2, 2023, at 5:46 PM, Miklosovic, Stefan wrote:
>>
>> That is a good idea. I would like to have Javadocs valid when going
>> through them in IDE. To enforce it, we would have to fix it first. If we
>> find a way how to validate Javadocs without actually rendering them, that
>> would be cool.
>>
>> There is a lot of legacy and rewriting of some custom-crafted formatting
>> of some comments might be quite a tedious task to do if it is required to
>> have them valid. I am in general for valid documentation and even enforcing
>> it but what to do with what is already there ...
>>
>> 
>> From: Jacek Lewandowski 
>> Sent: Wednesday, August 2, 2023 23:38
>> 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.
>>
>>
>>
>> With or without outputting JavaDoc to HTML, there are some errors which
>> we should maybe fix. We want to keep the documentation, but there can be
>> syntax errors which may prevent IDE generating a proper preview. So, the
>> question is - should we validate the JavaDoc comments as a precommit task?
>> Can it be done without actually generating HTML output?
>>
>> Thanks,
>> Jacek
>>
>> śr., 2 sie 2023, 22:24 użytkownik Derek Chen-Becker <
>> de...@chen-becker.org> napisał:
>> Oh, whoops, I guess I'm the only one that thinks Javadoc is just the tool
>> and/or it's output (not the markup itself) :P If anything, the codebase
>> could use a little more package/class/method markup in some places, so I'm
>> definitely only in favor of getting rid of the ant task. I should amend my
>> statement to be "...I suspect most people are not opening their browsers
>> and looking at Javadoc..." :)
>>
>> Cheers,
>>
>> Derek
>>
>>
>>
>> On Wed, Aug 2, 2023, 1:30 PM Josh McKenzie > jmcken...@apache.org>> wrote:
>> most people are not looking at Javadoc when working on the codebase.
>> I definitely use it extensively inside the IDE. But never as a compiled
>> set of external docs.
>>
>> Which is to say, I'm +1 on removing the target and I'd ask everyone to
>> keep javadoccing your classes and methods where things are non-obvious or
>> there's a logical coupling with something else in the system. :)
>>
>> On Wed, Aug 2, 2023, at 2:08 PM, Derek Chen-Becker wrote:
>> +1. If a need comes up for Javadoc we can fix it at that point, but I
>> suspect most people are not looking at Javadoc when working on the codebase.
>>
>> Cheers,
>>
>> Derek
>>
>> On Wed, Aug 2, 2023 at 11:11 AM Brandon Williams > > wrote:
>> I don't think even if it works anyone is going to use the output, so
>> I'm good with removal.
>>
>> Kind Regards,
>> Brandon
>>
>> On Wed, Aug 2, 2023 at 11:50 AM Ekaterina Dimitrova
>> mailto:e.dimitr...@gmail.com>> wrote:
>> >
>> > Hi everyone,
>> > We were looking into a user report around our ant javadoc task recently.
>> > That made us realize it is not run in CI; it finishes successfully even
>> if there are hundreds of errors, some potentially breaking doc pages.
>> >
>> > There was a ticket discussion where a few community members mentioned
>> that this task was probably unnecessary. Can we remove it, or shall we fix
>> it?
>> >
>> > Best regards,
>> > Ekaterina
>>
>>
>> --
>> +---+
>> | Derek Chen-Becker |
>> | GPG Key available at https://keybase.io/dchenbecker
>> 

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

[Maxim Muzafarov]

Personally, I find javadocs quite useful, especially when htmls are
indexed by search engines, which in turn increases the chances of
finding the right answer faster (I have seen a lot of useful javadocs
in the source code).

I have done a quick build of the javadocs:

  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] Building index for all classes...
  [javadoc] 100 errors
  [javadoc] 100 warnings

100 errors is no big deal and can be easily fixed. From my point of
view, 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, correct me if I'm
wrong.

So,
1. Fix warnings/errors;
2. Make the javadoc task part of the build (e.g. put it under
'artifacts'), or make it part of the release process that is regularly
checked on the CI;
3. Publish/deploy the javadoc htmls for release in the special
directory of the cassandra website to give them a chance of being
indexed;

On Thu, 3 Aug 2023 at 17:11, Jeremiah Jordan  wrote:
>
> I don’t think anyone wants to remove the javadocs.  This thread is about 
> removing the broken ant task which generates html files from them.
>
> +1 from me on removing the ant task.  If someone feels the task is useful 
> they can always implement one that does not crash and add it back.
>
> -Jeremiah
>
> On Aug 3, 2023 at 9:59:55 AM, "Claude Warren, Jr via dev" 
>  wrote:
>>
>> I think that we can get more developers interested if there are available 
>> javadocs.  While many of the core classes are not going to be touched by 
>> someone just starting, being able to understand what the external touch 
>> points are and how they interact with other bits of the system can be 
>> invaluable, particularly when you don't have the entire code base in front 
>> of you.
>>
>> For example, 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 if I did not have the source code 
>> in front of me.
>>
>> I am -1 on removing the javadocs.
>>
>> On Thu, Aug 3, 2023 at 4:35 AM Josh McKenzie  wrote:
>>>
>>> If anything, the codebase could use a little more package/class/method 
>>> markup in some places
>>>
>>> I am impressed with how diplomatic and generous you're being here Derek. :D
>>>
>>> On Wed, Aug 2, 2023, at 5:46 PM, Miklosovic, Stefan wrote:
>>>
>>> That is a good idea. I would like to have Javadocs valid when going through 
>>> them in IDE. To enforce it, we would have to fix it first. If we find a way 
>>> how to validate Javadocs without actually rendering them, that would be 
>>> cool.
>>>
>>> There is a lot of legacy and rewriting of some custom-crafted formatting of 
>>> some comments might be quite a tedious task to do if it is required to have 
>>> them valid. I am in general for valid documentation and even enforcing it 
>>> but what to do with what is already there ...
>>>
>>> 
>>> From: Jacek Lewandowski 
>>> Sent: Wednesday, August 2, 2023 23:38
>>> 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.
>>>
>>>
>>>
>>> With or without outputting JavaDoc to HTML, there are some errors which we 
>>> should maybe fix. We want to keep the documentation, but there can be 
>>> syntax errors which may prevent IDE generating a proper preview. So, the 
>>> question is - should we validate the JavaDoc comments as a precommit task? 
>>> Can it be done without actually generating HTML output?
>>>
>>> Thanks,
>>> Jacek
>>>
>>> śr., 2 sie 2023, 22:24 użytkownik Derek Chen-Becker 
>>> mailto:de...@chen-becker.org>> napisał:
>>> Oh, whoops, I guess I'm the only one that thinks Javadoc is just the tool 
>>> and/or it's output (not the markup itself) :P If anything, the codebase 
>>> could use a little more package/class/method markup in some places, so I'm 
>>> definitely only in favor of getting rid of the ant task. I should amend my 
>>> statement to be "...I suspect most people are not opening their browsers 
>>> and looking at Javadoc..." :)
>>>
>>> Cheers,
>>>
>>> Derek
>>>
>>>
>>>
>>> On Wed, Aug 2, 2023, 1:30 PM Josh McKenzie 
>>> mailto:jmcken...@apache.org>> wrote:
>>> most people are not looking at Javadoc when working on the codebase.
>>> I definitely use it extensively inside the IDE. But never as a compiled set 
>>> of external docs.
>>>
>>> Which is to say, I'm +1 on removing the target and I'd ask everyone to keep 
>>> javadoccing your classes and methods where things are non-obvious or 
>>> there's a logical coupling with something else in the system. :)
>>>
>>> On Wed, Aug 2, 2023, at 2:08 PM, Derek Chen-Becker 

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

[Ekaterina Dimitrova]

Thank you Maxim,

“

>From my point of
view, 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, correct me if I'm
wrong.

So,
1. Fix warnings/errors;
2. Make the javadoc task part of the build (e.g. put it under
'artifacts'), or make it part of the release process that is regularly
checked on the CI;
3. Publish/deploy the javadoc htmls for release in the special
directory of the cassandra website to give them a chance of being
indexed;“

This is aligned with what I saw and the two options mentioned at the
beginning - if we decide to keep it we should fix things and add the task
to CI, if we don’t because no one wants the html pages - then better to
remove it this ant task.
On your comment about 100 errors - it seems they are more. There is a cap
of 100 but when you fix them, more errors appear.
Further discussion can be found at CASSANDRA-17687

On Thu, 3 Aug 2023 at 14:21, Maxim Muzafarov  wrote:

> Personally, I find javadocs quite useful, especially when htmls are
> indexed by search engines, which in turn increases the chances of
> finding the right answer faster (I have seen a lot of useful javadocs
> in the source code).
>
> I have done a quick build of the javadocs:
>
>   [javadoc] Building index for all the packages and classes...
>   [javadoc] Building index for all classes...
>   [javadoc] Building index for all classes...
>   [javadoc] 100 errors
>   [javadoc] 100 warnings
>
> 100 errors is no big deal and can be easily fixed. From my point of
> view, 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, correct me if I'm
> wrong.
>
> So,
> 1. Fix warnings/errors;
> 2. Make the javadoc task part of the build (e.g. put it under
> 'artifacts'), or make it part of the release process that is regularly
> checked on the CI;
> 3. Publish/deploy the javadoc htmls for release in the special
> directory of the cassandra website to give them a chance of being
> indexed;
>
> On Thu, 3 Aug 2023 at 17:11, Jeremiah Jordan 
> wrote:
> >
> > I don’t think anyone wants to remove the javadocs.  This thread is about
> removing the broken ant task which generates html files from them.
> >
> > +1 from me on removing the ant task.  If someone feels the task is
> useful they can always implement one that does not crash and add it back.
> >
> > -Jeremiah
> >
> > On Aug 3, 2023 at 9:59:55 AM, "Claude Warren, Jr via dev" <
> dev@cassandra.apache.org> wrote:
> >>
> >> I think that we can get more developers interested if there are
> available javadocs.  While many of the core classes are not going to be
> touched by someone just starting, being able to understand what the
> external touch points are and how they interact with other bits of the
> system can be invaluable, particularly when you don't have the entire code
> base in front of you.
> >>
> >> For example, 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 if I did not have the source code
> in front of me.
> >>
> >> I am -1 on removing the javadocs.
> >>
> >> On Thu, Aug 3, 2023 at 4:35 AM Josh McKenzie 
> wrote:
> >>>
> >>> If anything, the codebase could use a little more package/class/method
> markup in some places
> >>>
> >>> I am impressed with how diplomatic and generous you're being here
> Derek. :D
> >>>
> >>> On Wed, Aug 2, 2023, at 5:46 PM, Miklosovic, Stefan wrote:
> >>>
> >>> That is a good idea. I would like to have Javadocs valid when going
> through them in IDE. To enforce it, we would have to fix it first. If we
> find a way how to validate Javadocs without actually rendering them, that
> would be cool.
> >>>
> >>> There is a lot of legacy and rewriting of some custom-crafted
> formatting of some comments might be quite a tedious task to do if it is
> required to have them valid. I am in general for valid documentation and
> even enforcing it but what to do with what is already there ...
> >>>
> >>> 
> >>> From: Jacek Lewandowski 
> >>> Sent: Wednesday, August 2, 2023 23:38
> >>> 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.
> >>>
> >>>
> >>>
> >>> With or without outputting JavaDoc to HTML, there are some errors
> which we should maybe fix. We want to keep the documentation, but there can
> be syntax errors which may prevent IDE generating a proper preview. So, the
> question is - should we validate the JavaDoc comments as a precommit task?
> Can it be done without actually generating HTML output?
>

Re: [DISCUSS] Creating a 5.0 landing page

[Ekaterina Dimitrova]

Hi Hugh,

Thank you for reaching out. I think this is a great idea. Also, great
timing, considering the community is discussing a potential 5.0 alpha
release soon.

It seems to me you actually suggest more than one page?
1) 5.0 and new features - could this be an update of the What’s new page? -
https://cassandra.apache.org/doc/trunk/cassandra/new/index.html
Adding also links to some of the talks sounds great to me.
2) Dedicated events page? We were using the Blogs page before but I don’t
think it is a bad idea to split Blog posts from Events page.

Thank you
Ekaterina


On Wed, 2 Aug 2023 at 21:03, Hugh Lashbrooke  wrote:

> With the upcoming release of Apache Cassandra 5.0, I’d like to create a
> landing page for the release and what that could look like.
>
> The landing page would be intended to educate users about what is coming
> up in this important release, highlighting why upgrading will be valuable
> to them, as well as guiding them into more community activities, such as
> Town Halls, where they can learn more and become further involved.
>
> The 5.0 landing page could include:
>
>- An overview of the release with a brief summary of the major features
>- A page for each CEP that is likely to be included–with key features,
>implementation information, and other technical details. These pages can
>also include recordings of relevant Contributor Meetings. Here is an
>example for CEP-28 - Spark Bulk Analytics Library
>
> 
>.
>- CTAs to community platforms and activities - Slack, Meetups, Town
>Halls, Contributor Meetings, etc.
>
> Let’s discuss! Does this sound valuable? If so, I will create a Jira
> ticket and am happy to get started. What other things do you think should
> be included in a page like this?
>

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

[Maxim Muzafarov]

Yes, I agree. The javadoc task should be part of our CI if we decide
to keep it, to keep it buildable at all times.


BTW, I have managed to fix all the javadoc errors.
I have tested the task for both jdk11 and jdk17.

Changes are here:
https://github.com/apache/cassandra/compare/trunk...Mmuzaf:cassandra:javadoc_build

On Thu, 3 Aug 2023 at 21:20, Ekaterina Dimitrova  wrote:
>
> Thank you Maxim,
>
> “
>
> From my point of
> view, 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, correct me if I'm
> wrong.
>
> So,
> 1. Fix warnings/errors;
> 2. Make the javadoc task part of the build (e.g. put it under
> 'artifacts'), or make it part of the release process that is regularly
> checked on the CI;
> 3. Publish/deploy the javadoc htmls for release in the special
> directory of the cassandra website to give them a chance of being
> indexed;“
>
> This is aligned with what I saw and the two options mentioned at the 
> beginning - if we decide to keep it we should fix things and add the task to 
> CI, if we don’t because no one wants the html pages - then better to remove 
> it this ant task.
> On your comment about 100 errors - it seems they are more. There is a cap of 
> 100 but when you fix them, more errors appear.
> Further discussion can be found at CASSANDRA-17687
>
> On Thu, 3 Aug 2023 at 14:21, Maxim Muzafarov  wrote:
>>
>> Personally, I find javadocs quite useful, especially when htmls are
>> indexed by search engines, which in turn increases the chances of
>> finding the right answer faster (I have seen a lot of useful javadocs
>> in the source code).
>>
>> I have done a quick build of the javadocs:
>>
>>   [javadoc] Building index for all the packages and classes...
>>   [javadoc] Building index for all classes...
>>   [javadoc] Building index for all classes...
>>   [javadoc] 100 errors
>>   [javadoc] 100 warnings
>>
>> 100 errors is no big deal and can be easily fixed. From my point of
>> view, 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, correct me if I'm
>> wrong.
>>
>> So,
>> 1. Fix warnings/errors;
>> 2. Make the javadoc task part of the build (e.g. put it under
>> 'artifacts'), or make it part of the release process that is regularly
>> checked on the CI;
>> 3. Publish/deploy the javadoc htmls for release in the special
>> directory of the cassandra website to give them a chance of being
>> indexed;
>>
>> On Thu, 3 Aug 2023 at 17:11, Jeremiah Jordan  
>> wrote:
>> >
>> > I don’t think anyone wants to remove the javadocs.  This thread is about 
>> > removing the broken ant task which generates html files from them.
>> >
>> > +1 from me on removing the ant task.  If someone feels the task is useful 
>> > they can always implement one that does not crash and add it back.
>> >
>> > -Jeremiah
>> >
>> > On Aug 3, 2023 at 9:59:55 AM, "Claude Warren, Jr via dev" 
>> >  wrote:
>> >>
>> >> I think that we can get more developers interested if there are available 
>> >> javadocs.  While many of the core classes are not going to be touched by 
>> >> someone just starting, being able to understand what the external touch 
>> >> points are and how they interact with other bits of the system can be 
>> >> invaluable, particularly when you don't have the entire code base in 
>> >> front of you.
>> >>
>> >> For example, 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 if I did not have the source 
>> >> code in front of me.
>> >>
>> >> I am -1 on removing the javadocs.
>> >>
>> >> On Thu, Aug 3, 2023 at 4:35 AM Josh McKenzie  wrote:
>> >>>
>> >>> If anything, the codebase could use a little more package/class/method 
>> >>> markup in some places
>> >>>
>> >>> I am impressed with how diplomatic and generous you're being here Derek. 
>> >>> :D
>> >>>
>> >>> On Wed, Aug 2, 2023, at 5:46 PM, Miklosovic, Stefan wrote:
>> >>>
>> >>> That is a good idea. I would like to have Javadocs valid when going 
>> >>> through them in IDE. To enforce it, we would have to fix it first. If we 
>> >>> find a way how to validate Javadocs without actually rendering them, 
>> >>> that would be cool.
>> >>>
>> >>> There is a lot of legacy and rewriting of some custom-crafted formatting 
>> >>> of some comments might be quite a tedious task to do if it is required 
>> >>> to have them valid. I am in general for valid documentation and even 
>> >>> enforcing it but what to do with what is already there ...
>> >>>
>> >>> 
>> >>> From: Jacek Lewandowski 
>> >>> Sent: Wednesday, August 2, 2023 23:38
>> >>> To: dev@cassandra.apache.org
>> >>> Subject: Re: [DISCUSSION] Shall we remove

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

[Ekaterina Dimitrova]

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 Thu, 3 Aug 2023 at 17:44, Maxim Muzafarov  wrote:

> Yes, I agree. The javadoc task should be part of our CI if we decide
> to keep it, to keep it buildable at all times.
>
>
> BTW, I have managed to fix all the javadoc errors.
> I have tested the task for both jdk11 and jdk17.
>
> Changes are here:
>
> https://github.com/apache/cassandra/compare/trunk...Mmuzaf:cassandra:javadoc_build
>
> On Thu, 3 Aug 2023 at 21:20, Ekaterina Dimitrova 
> wrote:
> >
> > Thank you Maxim,
> >
> > “
> >
> > From my point of
> > view, 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, correct me if I'm
> > wrong.
> >
> > So,
> > 1. Fix warnings/errors;
> > 2. Make the javadoc task part of the build (e.g. put it under
> > 'artifacts'), or make it part of the release process that is regularly
> > checked on the CI;
> > 3. Publish/deploy the javadoc htmls for release in the special
> > directory of the cassandra website to give them a chance of being
> > indexed;“
> >
> > This is aligned with what I saw and the two options mentioned at the
> beginning - if we decide to keep it we should fix things and add the task
> to CI, if we don’t because no one wants the html pages - then better to
> remove it this ant task.
> > On your comment about 100 errors - it seems they are more. There is a
> cap of 100 but when you fix them, more errors appear.
> > Further discussion can be found at CASSANDRA-17687
> >
> > On Thu, 3 Aug 2023 at 14:21, Maxim Muzafarov  wrote:
> >>
> >> Personally, I find javadocs quite useful, especially when htmls are
> >> indexed by search engines, which in turn increases the chances of
> >> finding the right answer faster (I have seen a lot of useful javadocs
> >> in the source code).
> >>
> >> I have done a quick build of the javadocs:
> >>
> >>   [javadoc] Building index for all the packages and classes...
> >>   [javadoc] Building index for all classes...
> >>   [javadoc] Building index for all classes...
> >>   [javadoc] 100 errors
> >>   [javadoc] 100 warnings
> >>
> >> 100 errors is no big deal and can be easily fixed. From my point of
> >> view, 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, correct me if I'm
> >> wrong.
> >>
> >> So,
> >> 1. Fix warnings/errors;
> >> 2. Make the javadoc task part of the build (e.g. put it under
> >> 'artifacts'), or make it part of the release process that is regularly
> >> checked on the CI;
> >> 3. Publish/deploy the javadoc htmls for release in the special
> >> directory of the cassandra website to give them a chance of being
> >> indexed;
> >>
> >> On Thu, 3 Aug 2023 at 17:11, Jeremiah Jordan 
> wrote:
> >> >
> >> > I don’t think anyone wants to remove the javadocs.  This thread is
> about removing the broken ant task which generates html files from them.
> >> >
> >> > +1 from me on removing the ant task.  If someone feels the task is
> useful they can always implement one that does not crash and add it back.
> >> >
> >> > -Jeremiah
> >> >
> >> > On Aug 3, 2023 at 9:59:55 AM, "Claude Warren, Jr via dev" <
> dev@cassandra.apache.org> wrote:
> >> >>
> >> >> I think that we can get more developers interested if there are
> available javadocs.  While many of the core classes are not going to be
> touched by someone just starting, being able to understand what the
> external touch points are and how they interact with other bits of the
> system can be invaluable, particularly when you don't have the entire code
> base in front of you.
> >> >>
> >> >> For example, 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 if I did not have the source
> code in front of me.
> >> >>
> >> >> I am -1 on removing the javadocs.
> >> >>
> >> >> On Thu, Aug 3, 2023 at 4:35 AM Josh McKenzie 
> wrote:
> >> >>>
> >> >>> If anything, the codebase could use a little more
> package/class/method markup in some places
> >> >>>
> >> >>> I am impressed with how diplomatic and generous you're being here
> Derek. :D
> >> >>>
> >> >>> On Wed, Aug 2, 2023, at 5:46 PM, Miklosovic, Stefan wrote:
> >> >>>
> >> >>> That is a good idea. I would like to have Javadocs valid when going
> through them in IDE. To enforce it, we would have to fix it first. If we
> find a way how to validate Javadocs without actually rendering them, that
> would be cool.
> >> >>>
> >> >>> There is a lot of legacy and rewriting of some custom-crafted
> formatting of some comments mig

Re: Tokenization and SAI query syntax

[Jon Haddad]

Yes, I understand that.  What I'm trying to point out is the potential 
confusion with having the same syntax behave differently for different index 
types.  

I'm not holding this view strongly, I'd just like folks to consider the impact 
to the end user, who in my experience is great with foot guns and bad with 
nuance.

On 2023/08/03 00:20:02 Jeremiah Jordan wrote:
> SASI just uses “=“ for the tokenized equality matching, which is the exact 
> thing this discussion is about changing/not liking.
> 
> > On Aug 2, 2023, at 7:18 PM, J. D. Jordan  wrote:
> > 
> > I do not think LIKE actually applies here. LIKE is used for prefix, 
> > contains, or suffix searches in SASI depending on the index type.
> > 
> > This is about exact matching of tokens.
> > 
> >> On Aug 2, 2023, at 5:53 PM, Jon Haddad  wrote:
> >> 
> >> Certain bits of functionality also already exist on the SASI side of 
> >> things, but I'm not sure how much overlap there is.  Currently, there's a 
> >> LIKE keyword that handles token matching, although it seems to have some 
> >> differences from the feature set in SAI.  
> >> 
> >> That said, there seems to be enough of an overlap that it would make sense 
> >> to consider using LIKE in the same manner, doesn't it?  I think it would 
> >> be a little odd if we have different syntax for different indexes.  
> >> 
> >> https://github.com/apache/cassandra/blob/trunk/doc/SASI.md
> >> 
> >> I think one complication here is that there seems to be a desire, that I 
> >> very much agree with, to expose as much of the underlying flexibility of 
> >> Lucene as much as possible.  If it means we use Caleb's suggestion, I'd 
> >> ask that the queries that SASI and SAI both support use the same syntax, 
> >> even if it means there's two ways of writing the same query.  To use 
> >> Caleb's example, this would mean supporting both LIKE and the `expr` 
> >> column.  
> >> 
> >> Jon
> >> 
>  On 2023/08/01 19:17:11 Caleb Rackliffe wrote:
> >>> Here are some additional bits of prior art, if anyone finds them useful:
> >>> 
> >>> 
> >>> The Stratio Lucene Index -
> >>> https://github.com/Stratio/cassandra-lucene-index#examples
> >>> 
> >>> Stratio was the reason C* added the "expr" functionality. They embedded
> >>> something similar to ElasticSearch JSON, which probably isn't my favorite
> >>> choice, but it's there.
> >>> 
> >>> 
> >>> The ElasticSearch match query syntax -
> >>> https://urldefense.com/v3/__https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-match-query.html__;!!PbtH5S7Ebw!ZHwYJ2xkivwTzYgjkp5QFAzALXCWPqkga6GBD-m2aK3j06ioSCRPsdZD0CIe50VpRrtW-1rY_m6lrSpp7zVlAf0MsxZ9$
> >>>  
> >>> 
> >>> Again, not my favorite. It's verbose, and probably too powerful for us.
> >>> 
> >>> 
> >>> ElasticSearch's documentation for the basic Lucene query syntax -
> >>> https://urldefense.com/v3/__https://www.elastic.co/guide/en/elasticsearch/reference/8.9/query-dsl-query-string-query.html*query-string-syntax__;Iw!!PbtH5S7Ebw!ZHwYJ2xkivwTzYgjkp5QFAzALXCWPqkga6GBD-m2aK3j06ioSCRPsdZD0CIe50VpRrtW-1rY_m6lrSpp7zVlAXEPP1sK$
> >>>  
> >>> 
> >>> One idea is to take the basic Lucene index, which it seems we already have
> >>> some support for, and feed it to "expr". This is nice for two reasons:
> >>> 
> >>> 1.) People can just write Lucene queries if they already know how.
> >>> 2.) No changes to the grammar.
> >>> 
> >>> Lucene has distinct concepts of filtering and querying, and this is kind 
> >>> of
> >>> the latter. I'm not sure how, for example, we would want "expr" to 
> >>> interact
> >>> w/ filters on other column indexes in vanilla CQL space...
> >>> 
> >>> 
>  On Mon, Jul 24, 2023 at 9:37 AM Josh McKenzie  
>  wrote:
>  
>  `column CONTAINS term`. Contains is used by both Java and Python for
>  substring searches, so at least some users will be surprised by 
>  term-based
>  behavior.
>  
>  I wonder whether users are in their "programming language" headspace or 
>  in
>  their "querying a database" headspace when interacting with CQL? i.e. 
>  this
>  would only present confusion if we expected users to be thinking in the
>  idioms of their respective programming languages. If they're thinking in
>  terms of SQL, MATCHES would probably end up confusing them a bit since it
>  doesn't match the general structure of the MATCH operator.
>  
>  That said, I also think CONTAINS loses something important that you 
>  allude
>  to here Jonathan:
>  
>  with corresponding query-time tokenization and analysis.  This means that
>  the query term is not always a substring of the original string!  Besides
>  obvious transformations like lowercasing, you have things like
>  PhoneticFilter available as well.
>  
>  So to me, neither MATCHES nor CONTAINS are particularly great candidates.
>  
>  So +1 to the "I don't actually hate it" sentiment on:
>  
>  column : term`. Inspired

Re: Tokenization and SAI query syntax

[Jon Haddad]

Assuming SAI is a superset of SASI, and we were to set up something so that 
SASI indexes auto convert to SAI, this gives even more weight to my point 
regarding how differing behavior for the same syntax can lead to issues.  Imo 
the best case scenario results in the user not even noticing their indexes have 
changed.

An (maybe better?) alternative is to add a flag to the index configuration for 
"compatibility mod", which might address the concerns around using an equality 
operator when it actually is a partial match.

For what it's worth, I'm in agreement that = should mean full equality and not 
token match.

On 2023/08/03 03:56:23 Caleb Rackliffe wrote:
> For what it's worth, I'd very much like to completely remove SASI from the
> codebase for 6.0. The only remaining functionality gaps at the moment are
> LIKE (prefix/suffix) queries and its limited tokenization
> capabilities, both of which already have SAI Phase 2 Jiras.
> 
> On Wed, Aug 2, 2023 at 7:20 PM Jeremiah Jordan 
> wrote:
> 
> > SASI just uses “=“ for the tokenized equality matching, which is the exact
> > thing this discussion is about changing/not liking.
> >
> > > On Aug 2, 2023, at 7:18 PM, J. D. Jordan 
> > wrote:
> > >
> > > I do not think LIKE actually applies here. LIKE is used for prefix,
> > contains, or suffix searches in SASI depending on the index type.
> > >
> > > This is about exact matching of tokens.
> > >
> > >> On Aug 2, 2023, at 5:53 PM, Jon Haddad 
> > wrote:
> > >>
> > >> Certain bits of functionality also already exist on the SASI side of
> > things, but I'm not sure how much overlap there is.  Currently, there's a
> > LIKE keyword that handles token matching, although it seems to have some
> > differences from the feature set in SAI.
> > >>
> > >> That said, there seems to be enough of an overlap that it would make
> > sense to consider using LIKE in the same manner, doesn't it?  I think it
> > would be a little odd if we have different syntax for different indexes.
> > >>
> > >> https://github.com/apache/cassandra/blob/trunk/doc/SASI.md
> > >>
> > >> I think one complication here is that there seems to be a desire, that
> > I very much agree with, to expose as much of the underlying flexibility of
> > Lucene as much as possible.  If it means we use Caleb's suggestion, I'd ask
> > that the queries that SASI and SAI both support use the same syntax, even
> > if it means there's two ways of writing the same query.  To use Caleb's
> > example, this would mean supporting both LIKE and the `expr` column.
> > >>
> > >> Jon
> > >>
> >  On 2023/08/01 19:17:11 Caleb Rackliffe wrote:
> > >>> Here are some additional bits of prior art, if anyone finds them
> > useful:
> > >>>
> > >>>
> > >>> The Stratio Lucene Index -
> > >>> https://github.com/Stratio/cassandra-lucene-index#examples
> > >>>
> > >>> Stratio was the reason C* added the "expr" functionality. They embedded
> > >>> something similar to ElasticSearch JSON, which probably isn't my
> > favorite
> > >>> choice, but it's there.
> > >>>
> > >>>
> > >>> The ElasticSearch match query syntax -
> > >>>
> > https://urldefense.com/v3/__https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-match-query.html__;!!PbtH5S7Ebw!ZHwYJ2xkivwTzYgjkp5QFAzALXCWPqkga6GBD-m2aK3j06ioSCRPsdZD0CIe50VpRrtW-1rY_m6lrSpp7zVlAf0MsxZ9$
> > >>>
> > >>> Again, not my favorite. It's verbose, and probably too powerful for us.
> > >>>
> > >>>
> > >>> ElasticSearch's documentation for the basic Lucene query syntax -
> > >>>
> > https://urldefense.com/v3/__https://www.elastic.co/guide/en/elasticsearch/reference/8.9/query-dsl-query-string-query.html*query-string-syntax__;Iw!!PbtH5S7Ebw!ZHwYJ2xkivwTzYgjkp5QFAzALXCWPqkga6GBD-m2aK3j06ioSCRPsdZD0CIe50VpRrtW-1rY_m6lrSpp7zVlAXEPP1sK$
> > >>>
> > >>> One idea is to take the basic Lucene index, which it seems we already
> > have
> > >>> some support for, and feed it to "expr". This is nice for two reasons:
> > >>>
> > >>> 1.) People can just write Lucene queries if they already know how.
> > >>> 2.) No changes to the grammar.
> > >>>
> > >>> Lucene has distinct concepts of filtering and querying, and this is
> > kind of
> > >>> the latter. I'm not sure how, for example, we would want "expr" to
> > interact
> > >>> w/ filters on other column indexes in vanilla CQL space...
> > >>>
> > >>>
> >  On Mon, Jul 24, 2023 at 9:37 AM Josh McKenzie 
> > wrote:
> > 
> >  `column CONTAINS term`. Contains is used by both Java and Python for
> >  substring searches, so at least some users will be surprised by
> > term-based
> >  behavior.
> > 
> >  I wonder whether users are in their "programming language" headspace
> > or in
> >  their "querying a database" headspace when interacting with CQL? i.e.
> > this
> >  would only present confusion if we expected users to be thinking in
> > the
> >  idioms of their respective programming languages. If they're thinking
> > in
> >  terms of SQL, MATCHES would probably

Re: [DISCUSS] Creating a 5.0 landing page

[Josh McKenzie]

We actually already have an events page: 
https://cassandra.apache.org/_/events.html; not sure if you were saying we 
should add one Ekaterina or saying we should add this content there. +1 to the 
content there and having a landing page that points there + integrating 
meetups, town halls, etc.

Community -> Events on the menu up top in case someone missed it.

On Thu, Aug 3, 2023, at 4:21 PM, Ekaterina Dimitrova wrote:
> 
> Hi Hugh,
> 
> Thank you for reaching out. I think this is a great idea. Also, great timing, 
> considering the community is discussing a potential 5.0 alpha release soon. 
> 
> It seems to me you actually suggest more than one page?
> 1) 5.0 and new features - could this be an update of the What’s new page? - 
> https://cassandra.apache.org/doc/trunk/cassandra/new/index.html
> Adding also links to some of the talks sounds great to me.
> 2) Dedicated events page? We were using the Blogs page before but I don’t 
> think it is a bad idea to split Blog posts from Events page.
> 
> Thank you
> Ekaterina
> 
> 
> On Wed, 2 Aug 2023 at 21:03, Hugh Lashbrooke  wrote:
>> With the upcoming release of Apache Cassandra 5.0, I’d like to create a 
>> landing page for the release and what that could look like.
>> 
>> The landing page would be intended to educate users about what is coming up 
>> in this important release, highlighting why upgrading will be valuable to 
>> them, as well as guiding them into more community activities, such as Town 
>> Halls, where they can learn more and become further involved.
>> 
>> The 5.0 landing page could include:
>>  • An overview of the release with a brief summary of the major features
>>  • A page for each CEP that is likely to be included–with key features, 
>> implementation information, and other technical details. These pages can 
>> also include recordings of relevant Contributor Meetings. Here is an example 
>> for CEP-28 - Spark Bulk Analytics Library 
>> .
>>  • CTAs to community platforms and activities - Slack, Meetups, Town Halls, 
>> Contributor Meetings, etc.
>> Let’s discuss! Does this sound valuable? If so, I will create a Jira ticket 
>> and am happy to get started. What other things do you think should be 
>> included in a page like this?
>> 

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

[Josh McKenzie]

> 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/.

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 Thu, 3 Aug 2023 at 17:44, Maxim Muzafarov  wrote:
>> Yes, I agree. The javadoc task should be part of our CI if we decide
>> to keep it, to keep it buildable at all times.
>> 
>> 
>> BTW, I have managed to fix all the javadoc errors.
>> I have tested the task for both jdk11 and jdk17.
>> 
>> Changes are here:
>> https://github.com/apache/cassandra/compare/trunk...Mmuzaf:cassandra:javadoc_build
>> 
>> On Thu, 3 Aug 2023 at 21:20, Ekaterina Dimitrova  
>> wrote:
>> >
>> > Thank you Maxim,
>> >
>> > “
>> >
>> > From my point of
>> > view, 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, correct me if I'm
>> > wrong.
>> >
>> > So,
>> > 1. Fix warnings/errors;
>> > 2. Make the javadoc task part of the build (e.g. put it under
>> > 'artifacts'), or make it part of the release process that is regularly
>> > checked on the CI;
>> > 3. Publish/deploy the javadoc htmls for release in the special
>> > directory of the cassandra website to give them a chance of being
>> > indexed;“
>> >
>> > This is aligned with what I saw and the two options mentioned at the 
>> > beginning - if we decide to keep it we should fix things and add the task 
>> > to CI, if we don’t because no one wants the html pages - then better to 
>> > remove it this ant task.
>> > On your comment about 100 errors - it seems they are more. There is a cap 
>> > of 100 but when you fix them, more errors appear.
>> > Further discussion can be found at CASSANDRA-17687
>> >
>> > On Thu, 3 Aug 2023 at 14:21, Maxim Muzafarov  wrote:
>> >>
>> >> Personally, I find javadocs quite useful, especially when htmls are
>> >> indexed by search engines, which in turn increases the chances of
>> >> finding the right answer faster (I have seen a lot of useful javadocs
>> >> in the source code).
>> >>
>> >> I have done a quick build of the javadocs:
>> >>
>> >>   [javadoc] Building index for all the packages and classes...
>> >>   [javadoc] Building index for all classes...
>> >>   [javadoc] Building index for all classes...
>> >>   [javadoc] 100 errors
>> >>   [javadoc] 100 warnings
>> >>
>> >> 100 errors is no big deal and can be easily fixed. From my point of
>> >> view, 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, correct me if I'm
>> >> wrong.
>> >>
>> >> So,
>> >> 1. Fix warnings/errors;
>> >> 2. Make the javadoc task part of the build (e.g. put it under
>> >> 'artifacts'), or make it part of the release process that is regularly
>> >> checked on the CI;
>> >> 3. Publish/deploy the javadoc htmls for release in the special
>> >> directory of the cassandra website to give them a chance of being
>> >> indexed;
>> >>
>> >> On Thu, 3 Aug 2023 at 17:11, Jeremiah Jordan  
>> >> wrote:
>> >> >
>> >> > I don’t think anyone wants to remove the javadocs.  This thread is 
>> >> > about removing the broken ant task which generates html files from them.
>> >> >
>> >> > +1 from me on removing the ant task.  If someone feels the task is 
>> >> > useful they can always implement one that does not crash and add it 
>> >> > back.
>> >> >
>> >> > -Jeremiah
>> >> >
>> >> > On Aug 3, 2023 at 9:59:55 AM, "Claude Warren, Jr via dev" 
>> >> >  wrote:
>> >> >>
>> >> >> I think that we can get more developers interested if there are 
>> >> >> available javadocs.  While many of the core classes are not going to 
>> >> >> be touched by someone just starting, b

Re: [DISCUSS] Creating a 5.0 landing page

[Ekaterina Dimitrova]

I honestly didn’t realize events page was added already. Thank you, Josh!

So yes, in that case I guess that is what I am asking - shall we add there
town halle, etc?

On Thu, 3 Aug 2023 at 22:37, Josh McKenzie  wrote:

> We actually already have an events page:
> https://cassandra.apache.org/_/events.html; not sure if you were saying
> we should add one Ekaterina or saying we should add this content there. +1
> to the content there and having a landing page that points there +
> integrating meetups, town halls, etc.
>
> Community -> Events on the menu up top in case someone missed it.
>
> On Thu, Aug 3, 2023, at 4:21 PM, Ekaterina Dimitrova wrote:
>
>
> Hi Hugh,
>
> Thank you for reaching out. I think this is a great idea. Also, great
> timing, considering the community is discussing a potential 5.0 alpha
> release soon.
>
> It seems to me you actually suggest more than one page?
> 1) 5.0 and new features - could this be an update of the What’s new page?
> -
> https://cassandra.apache.org/doc/trunk/cassandra/new/index.html
> Adding also links to some of the talks sounds great to me.
> 2) Dedicated events page? We were using the Blogs page before but I don’t
> think it is a bad idea to split Blog posts from Events page.
>
> Thank you
> Ekaterina
>
>
> On Wed, 2 Aug 2023 at 21:03, Hugh Lashbrooke  wrote:
>
> With the upcoming release of Apache Cassandra 5.0, I’d like to create a
> landing page for the release and what that could look like.
>
> The landing page would be intended to educate users about what is coming
> up in this important release, highlighting why upgrading will be valuable
> to them, as well as guiding them into more community activities, such as
> Town Halls, where they can learn more and become further involved.
>
> The 5.0 landing page could include:
>
>- An overview of the release with a brief summary of the major features
>- A page for each CEP that is likely to be included–with key features,
>implementation information, and other technical details. These pages can
>also include recordings of relevant Contributor Meetings. Here is an
>example for CEP-28 - Spark Bulk Analytics Library
>
> 
>.
>- CTAs to community platforms and activities - Slack, Meetups, Town
>Halls, Contributor Meetings, etc.
>
> Let’s discuss! Does this sound valuable? If so, I will create a Jira
> ticket and am happy to get started. What other things do you think should
> be included in a page like this?
>
>
>

Re: [DISCUSS] Creating a 5.0 landing page

[guo Maxwell]

Can we have some pages for 5.0 in Chinese？If we can，I can do some help to
doing some translation ！
Ekaterina Dimitrova 于2023年8月4日 周五上午10:55写道：

> I honestly didn’t realize events page was added already. Thank you, Josh!
>
> So yes, in that case I guess that is what I am asking - shall we add there
> town halle, etc?
>
> On Thu, 3 Aug 2023 at 22:37, Josh McKenzie  wrote:
>
>> We actually already have an events page:
>> https://cassandra.apache.org/_/events.html; not sure if you were saying
>> we should add one Ekaterina or saying we should add this content there. +1
>> to the content there and having a landing page that points there +
>> integrating meetups, town halls, etc.
>>
>> Community -> Events on the menu up top in case someone missed it.
>>
>> On Thu, Aug 3, 2023, at 4:21 PM, Ekaterina Dimitrova wrote:
>>
>>
>> Hi Hugh,
>>
>> Thank you for reaching out. I think this is a great idea. Also, great
>> timing, considering the community is discussing a potential 5.0 alpha
>> release soon.
>>
>> It seems to me you actually suggest more than one page?
>> 1) 5.0 and new features - could this be an update of the What’s new page?
>> -
>> https://cassandra.apache.org/doc/trunk/cassandra/new/index.html
>> Adding also links to some of the talks sounds great to me.
>> 2) Dedicated events page? We were using the Blogs page before but I don’t
>> think it is a bad idea to split Blog posts from Events page.
>>
>> Thank you
>> Ekaterina
>>
>>
>> On Wed, 2 Aug 2023 at 21:03, Hugh Lashbrooke  wrote:
>>
>> With the upcoming release of Apache Cassandra 5.0, I’d like to create a
>> landing page for the release and what that could look like.
>>
>> The landing page would be intended to educate users about what is coming
>> up in this important release, highlighting why upgrading will be valuable
>> to them, as well as guiding them into more community activities, such as
>> Town Halls, where they can learn more and become further involved.
>>
>> The 5.0 landing page could include:
>>
>>- An overview of the release with a brief summary of the major
>>features
>>- A page for each CEP that is likely to be included–with key
>>features, implementation information, and other technical details. These
>>pages can also include recordings of relevant Contributor Meetings. Here
>>is an example for CEP-28 - Spark Bulk Analytics Library
>>
>> 
>>.
>>- CTAs to community platforms and activities - Slack, Meetups, Town
>>Halls, Contributor Meetings, etc.
>>
>> Let’s discuss! Does this sound valuable? If so, I will create a Jira
>> ticket and am happy to get started. What other things do you think should
>> be included in a page like this?
>>
>>
>> --
you are the apple of my eye !