Re: [VOTE] Release dtest-api 0.0.16

[Alex Petrov]

+1

On Thu, Aug 17, 2023, at 4:46 AM, Brandon Williams wrote:
> +1
> 
> Kind Regards,
> Brandon
> 
> On Wed, Aug 16, 2023 at 4:34 PM Dinesh Joshi  wrote:
> >
> > Proposing the test build of in-jvm dtest API 0.0.16 for release.
> >
> > Repository:
> > https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git
> >
> > Candidate SHA:
> > https://github.com/apache/cassandra-in-jvm-dtest-api/commit/1ba6ef93d0721741b5f6d6d72cba3da03fe78438
> > tagged with 0.0.16
> >
> > Artifacts:
> > https://repository.apache.org/content/repositories/orgapachecassandra-1307/org/apache/cassandra/dtest-api/0.0.16/
> >
> > Key signature: 53371F9B1B425A336988B6A03B6042413D323470
> >
> > Changes since last release:
> >
> > * CASSANDRA-18727 - JMXUtil.getJmxConnector should retry connection attempts
> >
> > 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.
> >
> 

Mailing list threading improvements

[Christofer Dutz]

TL;DR: We’re updating how auto-generated email from Github will be
threaded on your mailing lists. If you want to keep the old defaults,
details are below.

We’re pleased to let you know that we’re tweaking the way that auto-
generated email from Github will appear on your mailing lists. This
will lead to more human-readable subject lines, and the ability of most
modern mail clients to correctly thread discussions originating on
Github.

Background: Many project mailing lists receive email auto-generated by
Github. The way that the subject lines are crafted leads to messages
from the same topic not being threaded together by most mail clients.
We’re fixing that.

The way that these messages are threaded is defined by a file -
.asf.yml - in your git repositories. We’re changing the way that it
will work by default if you don’t choose settings. If you’re happy for
us to make this change, don’t do anything - the change will happen on
October the 1st 2023.

Details of the current default, as well as the proposed changes, are on
the following page, along with instructions on how to keep your current
settings, if you prefer:

https://community.apache.org/contributors/mailing-lists.html#configuring-the-subject-lines-of-the-emails-being-sent

Please copy d...@community.apache.org
on any feedback.

Chris, on behalf of the Comdev PMC

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

[Ekaterina Dimitrova]

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

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

[Brandon Williams]

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

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

[Maxim Muzafarov]

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

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

[Ekaterina Dimitrova]

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  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  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
> >  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/.
> > >>
> > >> 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 <
> e.dimitr...@gmail.com> 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

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

[Mick Semb Wever]

+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  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  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
>> >  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/.
>> > >>
>> > >> 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 <
>> e.dimitr...@gmail.com> 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 pack

[DISCUSSION] CASSANDRA-18772 - removal of commons-codec on trunk

[Ekaterina Dimitrova]

Hi everyone,

I propose we remove commons-codec on trunk.
The only usage I found was from CASSANDRA-12790
* - *Support
InfluxDb metrics reporter configuration, which relied on commons-codec and
metrics-reporter-config, which will be removed as part of CASSANDRA-18743.
The only question is whether we can remove those two dependencies on trunk,
considering it is 5.1, or do we need to wait until 6.0.

Best regards,
Ekaterina

Re: [DISCUSSION] CASSANDRA-18772 - removal of commons-codec on trunk

[Abe Ratnofsky]

If we're going to do bulk dependency pruning, we should minimize the number of 
deprecation plans that users need to prepare for. There will likely be a few 
more dependencies we clean up around 5.0, so sticking with 5.0 deprecation and 
6.0 removal for all of them would likely make our users' lives easier.

If there's new information about a security issue in a dependency and no clear 
alternative, I'd be open to an expedited removal plan as an exception, but that 
would be on a case-by-case basis.

> On Aug 17, 2023, at 10:10 AM, Ekaterina Dimitrova  
> wrote:
> 
> Hi everyone,
> 
> I propose we remove commons-codec on trunk.
> The only usage I found was from CASSANDRA-12790 
>  - Support InfluxDb 
> metrics reporter configuration, which relied on commons-codec and 
> metrics-reporter-config, which will be removed as part of CASSANDRA-18743. 
> The only question is whether we can remove those two dependencies on trunk, 
> considering it is 5.1, or do we need to wait until 6.0. 
> 
> Best regards,
> Ekaterina

Re: [DISCUSSION] CASSANDRA-18772 - removal of commons-codec on trunk

[Miklosovic, Stefan]

I would remove it all in 5.0 but that's just me. I do not think that the 
deprecation is a must and it is just unnecessary exercise and we are just red 
taping here.

Major releases are good for dropping the "baggage" like this. Do we really want 
to wait until 6.0 is out to cut off the dead weight?


From: Ekaterina Dimitrova 
Sent: Thursday, August 17, 2023 19:10
To: dev
Subject: [DISCUSSION] CASSANDRA-18772 - removal of commons-codec on trunk

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.



Hi everyone,

I propose we remove commons-codec on trunk.
The only usage I found was from 
CASSANDRA-12790 - 
Support InfluxDb metrics reporter configuration, which relied on commons-codec 
and metrics-reporter-config, which will be removed as part of CASSANDRA-18743.
The only question is whether we can remove those two dependencies on trunk, 
considering it is 5.1, or do we need to wait until 6.0.

Best regards,
Ekaterina

Re: [DISCUSSION] CASSANDRA-18772 - removal of commons-codec on trunk

[Mick Semb Wever]

>
> I propose we remove commons-codec on trunk.
> The only usage I found was from CASSANDRA-12790 - Support InfluxDb
metrics reporter configuration, which relied on commons-codec and
metrics-reporter-config, which will be removed as part of CASSANDRA-18743.
> The only question is whether we can remove those two dependencies on
trunk, considering it is 5.1, or do we need to wait until 6.0.



Dependencies are not an API (where they're not exposed/leaked), +1 on
removing it in 5.0 (when 18743 lands).  If users/operators need it back on
the classpath it is for reasons outside of our API concerns.