[DISCUSS] mapping of all deprecations after 18912 and removal of deprecations added in Cassandra 1.x and 2.x

[Miklosovic, Stefan via dev]

Hi list,

this is the follow-up thread after we discussed the addition of Deprecated 
annotations with "since" in the code. It was merged to 5.0 and trunk under 
18912.

I have added all the mappings under (1). There are tables for each major 
version of Cassandra with links to all places where we deprecated that with 
information whether it is JMX/public facing or nodetool, Config etc.

As we are targeting this for 5.x/trunk, I think we are safe to elaborate on the 
removal of all deprecations which we added in majors 1, 2 and 3 only.

I would like to make this an iterative process. For starters, we might remove 
(if we decide to do so), stuff which was deprecated in 1.x and 2.x to which I 
put various commentary in the ticket.

If you see something which we should not remove, please tell me so, for such 
elements, I will put "forRemoval = false" to respective deprecation annotations.

Regards

(1) https://issues.apache.org/jira/browse/CASSANDRA-18938

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Benjamin Lerer]

The proposal includes 3 things:
1. Do not include TCM and Accord in 5.0 to avoid delaying 5.0
2. The next release will be 5.1 and will include only Accord and TCM
3. Merge TCM and Accord right now in 5.1 (making an initial release)

I am fine with question 1 and do not have a strong opinion on which way to
go.
2. Means that every new feature will have to wait for post 5.1 even if it
is ready before 5.1 is stabilized and shipped. If we do a 5.1 release why
not take it as an opportunity to release more things. I am not saying that
we will. Just that we should let that door open.
3. There is a need to merge TCM and Accord as maintaining those separate
branches is costly in terms of time and energy. I fully understand that. On
the other hand merging TCM and Accord will make the TCM review harder and I
do believe that this second round of review is valuable as it already
uncovered a valid issue. Nevertheless, I am fine with merging TCM as soon
as it passes CI and continuing the review after the merge. If we cannot
meet at least that quality level (Green CI) we should not merge just for
creating an 5.1.alpha release for the summit.

Now, I am totally fine with a preview release without numbering and with
big warnings that will only serve as a preview for the summit.

Le mer. 25 oct. 2023 à 06:33, Berenguer Blasi  a
écrit :

> I also think there's many good new features in 5.0 already they'd make a
> good release even on their own. My 2 cts.
>
> On 24/10/23 23:20, Brandon Williams wrote:
> > The catch here is that we don't publish docker images currently.  The
> > C* docker images available are not made by us.
> >
> > Kind Regards,
> > Brandon
> >
> > On Tue, Oct 24, 2023 at 3:31 PM Patrick McFadin 
> wrote:
> >> Let me make that really easy. Hell yes
> >>
> >> Not everybody runs CCM, I've tried but I've met resistance.
> >>
> >> Compiling your own version usually involves me saying the words "Yes,
> ant realclean exists. I'm not trolling you"
> >>
> >> docker pull  works on every OS and curates a single node
> experience.
> >>
> >>
> >>
> >> On Tue, Oct 24, 2023 at 12:37 PM Josh McKenzie 
> wrote:
> >>> In order for the project to advertise the release outside the dev@
> list it needs to be a formal release.
> >>>
> >>> That's my reading as well:
> >>> https://www.apache.org/legal/release-policy.html#release-definition
> >>>
> >>> I wonder if there'd be value in us having a cronned job that'd do
> nightly docker container builds on trunk + feature branches, archived for N
> days, and we make that generally known to the dev@ list here so folks
> that want to poke at the current state of trunk or other branches could do
> so with very low friction. We'd probably see more engagement on feature
> branches if it was turn-key easy for other C* devs to spin the up and check
> them out.
> >>>
> >>> For what you're talking about here Patrick (a docker image for folks
> outside the dev@ audience and more user-facing), we'd want to vote on it
> and go through the formal process.
> >>>
> >>> On Tue, Oct 24, 2023, at 3:10 PM, Jeremiah Jordan wrote:
> >>>
> >>> In order for the project to advertise the release outside the dev@
> list it needs to be a formal release.  That just means that there was a
> release vote and at least 3 PMC members +1’ed it, and there are more +1
> than there are -1, and we follow all the normal release rules.  The ASF
> release process doesn’t care what branch you cut the artifacts from or what
> version you call it.
> >>>
> >>> So the project can cut artifacts for and release a 5.1-alpha1,
> 5.1-dev-preview1, what ever we want to version this thing, from trunk or
> any other branch name we want.
> >>>
> >>> -Jeremiah
> >>>
> >>> On Oct 24, 2023 at 2:03:41 PM, Patrick McFadin 
> wrote:
> >>>
> >>> I would like to have something for developers to use ASAP to try the
> Accord syntax. Very few people have seen it, and I think there's a learning
> curve we can start earlier.
> >>>
> >>> It's my understanding that ASF policy is that it needs to be a project
> release to create a docker image.
> >>>
> >>> On Tue, Oct 24, 2023 at 11:54 AM Jeremiah Jordan <
> jeremiah.jor...@gmail.com> wrote:
> >>>
> >>> If we decide to go the route of not merging TCM to the 5.0 branch.  Do
> we actually need to immediately cut a 5.1 branch?  Can we work on
> stabilizing things while it is in trunk and cut the 5.1 branch when we
> actually think we are near releasing?  I don’t see any reason we can not
> cut “preview” artifacts from trunk?
> >>>
> >>> -Jeremiah
> >>>
> >>> On Oct 24, 2023 at 11:54:25 AM, Jon Haddad 
> wrote:
> >>>
> >>> I guess at the end of the day, shipping a release with a bunch of
> awesome features is better than holding it back.  If there's 2 big releases
> in 6 months the community isn't any worse off.
> >>>
> >>> We either ship something, or nothing, and something is probably better.
> >>>
> >>> Jon
> >>>
> >>>
> >>> On 2023/10/24 16:27:04 Patrick McFadin wrote:
> >>>
> >>> +1 to what you are saying

Re: CASSANDRA-16565

[Claude Warren, Jr via dev]

I ended up posting the code at
https://github.com/Aiven-Labs/compare_oshi_sigar if anyone wants to take a
look and see if they get differing results on various systems.

On Tue, Oct 24, 2023 at 4:59 PM Brandon Williams  wrote:

> On Tue, Oct 24, 2023 at 7:48 AM Claude Warren, Jr via dev
>  wrote:
> >
> > Is there someplace I can stash the tgz that others can download it from?
> The file info is : 6269066 okt 24 12:46 compare_oshi_sigar.tgz
>
> Is posting a github branch not sufficient?
>

Development Dependencies documentation.

[Claude Warren, Jr via dev]

I just had to change dependencies in Cassandra for the first  time and I
think the documentation [1] is out of date.

First I think most of the file edits are in the ".build" directory.  Adding
jars to the "lib" directory works until calling "ant realclean", so perhaps
the instructions should include regenerating the "lib" folder after making
the edits.

If I am wrong please let me know, otherwise I will open a ticket and update
the documentation.

[1] https://cassandra.apache.org/_/development/dependencies.html

Re: Development Dependencies documentation.

[Ekaterina Dimitrova]

Hi Claude,
You are not wrong. Unfortunately, it is outdated. Abe Ratnofsky has a work
in progress patch. You might want to get in touch with him to finish it.
Best regards,
Ekaterina

On Wed, 25 Oct 2023 at 8:04, Claude Warren, Jr via dev <
dev@cassandra.apache.org> wrote:

> I just had to change dependencies in Cassandra for the first  time and I
> think the documentation [1] is out of date.
>
> First I think most of the file edits are in the ".build" directory.
> Adding jars to the "lib" directory works until calling "ant realclean", so
> perhaps the instructions should include regenerating the "lib" folder after
> making the edits.
>
> If I am wrong please let me know, otherwise I will open a ticket and
> update the documentation.
>
> [1] https://cassandra.apache.org/_/development/dependencies.html
>

Re: CASSANDRA-18775 (Cassandra supported OSs)

[Josh McKenzie]

+1 to drop if we're not using.

On Fri, Oct 20, 2023, at 6:58 PM, Ekaterina Dimitrova wrote:
> +1 on removal the whole lib if we are sure we don’t need it. Nothing better 
> than some healthy house cleaning 
> 
>  -1 on partial removals
> 
> On Fri, 20 Oct 2023 at 17:34, David Capwell  wrote:
>> +1 to drop the whole lib… 
>> 
>> 
>>> On Oct 20, 2023, at 7:55 AM, Jeremiah Jordan  
>>> wrote:
>>> 
>>> Agreed.  -1 on selectively removing any of the libs.  But +1 for removing 
>>> the whole thing if it is no longer used.
>>> 
>>> -Jeremiah
>>> 
>>> On Oct 20, 2023 at 9:28:55 AM, Mick Semb Wever  wrote:
> Does anyone see any reason _not_ to do this?
 
 
 Thanks for bring this to dev@
 
 I see reason not to do it, folk do submit patches for other archs despite 
 us not formally maintaining and testing the code for those archs.  Some 
 examples are PPC64 Big Endian (CASSANDRA-7476), s390x (CASSANDRA-17723), 
 PPC64 Little Endian (CASSANDRA-7381), sparcv9 (CASSANDRA-6628).  Wrote 
 this on the ticket too.
 
 +1 for removing sigar altogether (as Brandon points out). 

Re: [DISCUSS] Allow UPDATE on settings virtual table to change running configuration

[Josh McKenzie]

Is the primary pain point you're trying to solve getting a 2nd committer 
reviewer Maxim? And / or making the review process simpler / cleaner for 
someone?

On Wed, Oct 18, 2023, at 5:06 PM, Maxim Muzafarov wrote:
> Hello everyone,
> 
> It has been a long time since the last update on this thread, so I
> wanted to share some status updates: The issue is still awaiting
> review, but all my hopes are pinned on Benjamin :-)
> 
> My question here is, is there anything I can do to facilitate the
> review for anyone who wants to delve into the patch?
> 
> I have a few thoughts to follow:
> - CEPify the changes - this will allow us to see the result of the
> discussion on a single page without having to re-read the whole
> thread;
> - Write a blog post with possible design solutions - this will both
> reveal the results of the discussion and potentially will draw some
> attention to the community;
> - Presenting and discussing slides at one of the Cassandra Town Halls;
> 
> I tend to the 1-st and/or 2-nd points. What are the best practices we
> have here for such cases though? Any thoughts?
> 
> On Tue, 11 Jul 2023 at 15:51, Maxim Muzafarov  wrote:
> >
> > Thank you for your comments and for sharing the ticket targeting
> > strategy, I'm really happy to see this page where I have found all the
> > answers to the questions I had. So, I tend towards your view and will
> > just land this ticket on the 5.0 release only for now as it makes
> > sense for me as well.
> >
> > I didn't add the feature flag for this feature because for 99% of the
> > source code changes it only works with Cassandra internals leaving the
> > public API unchanged. A few remarks on this are:
> > - the display format of the vtable property has changed to match the
> > yaml configuration style, this doesn't mean that we are displaying
> > property values in a completely different way in fact the formats
> > match with only 4 exceptions mentioned in the message above (this
> > should be fine for the major release I hope);
> > - a new column, which we've agreed to add (I'll fix the PR shortly);
> >
> >
> > I would also like to mention the follow-up todos required by this
> > issue to set the right expectations. Currently, we've brought a few
> > properties under the framework to make them updateable with the
> > SettingsTable, so that you can keep focusing on the framework itself
> > rather than on tagging the configuration properties themselves with
> > the @Mutable annotation. Although the solution is self-sufficient for
> > the already tagged properties, we still need to bring the rest of them
> > under the framework afterwards. I'll create an issue and do it right,
> > we'll be done with the inital patch.
> >
> >
> > On Fri, 7 Jul 2023 at 20:37, Josh McKenzie  wrote:
> > >
> > > This really is great work Maxim; definitely appreciate all the hard work 
> > > that's gone into it and I think the users will too.
> > >
> > > In terms of where it should land, we discussed this type of question at 
> > > length on the ML awhile ago and ended up codifying it in the wiki: 
> > > https://cwiki.apache.org/confluence/display/CASSANDRA/Patching%2C+versioning%2C+and+LTS+releases
> > >
> > > When working on a ticket, use the following guideline to determine which 
> > > branch to apply it to (Note: See How To Commit for details on the commit 
> > > and merge process)
> > >
> > > Bugfix: apply to oldest applicable LTS and merge up through latest GA to 
> > > trunk
> > >
> > > In the event you need to make changes on the merge commit, merge with -s 
> > > ours and revise the commit via --amend
> > >
> > > Improvement: apply to trunk only (next release)
> > >
> > > Note: refactoring and removing dead code qualifies as an Improvement; our 
> > > priority is stability on GA lines
> > >
> > > New Feature: apply to trunk only (next release)
> > >
> > > Our priority is to keep the 2 LTS releases and latest GA stable while 
> > > releasing new "latest GA" on a cadence that provides new improvements and 
> > > functionality to users soon enough to be valuable and relevant.
> > >
> > >
> > > So in this case, target whatever unreleased next feature release (i.e. 
> > > SEMVER MAJOR || MINOR) we have on deck.
> > >
> > > On Thu, Jul 6, 2023, at 1:21 PM, Ekaterina Dimitrova wrote:
> > >
> > > Hi,
> > >
> > > First of all, thank you for all the work!
> > > I personally think that it should be ok to add a new column.
> > >
> > > I will be very happy to see this landing in 5.0.
> > > I am personally against porting this patch to 4.1. To be clear, I am sure 
> > > you did a great job and my response would be the same to every single 
> > > person - the configuration is quite wide-spread and the devil is in the 
> > > details. I do not see a good reason for exception here except 
> > > convenience. There is no feature flag for these changes too, right?
> > >
> > > Best regards,
> > > Ekaterina
> > >
> > > На четвъртък, 6 юли 2023 г. Miklosovic, Stefan 
> > >  написа:
> > >
>

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Josh McKenzie]

> If we cannot meet at least that quality level (Green CI) we should not merge
We should probably make it a formally agreed upon point to not merge things 
unless we're sure they won't destabilize, and thus block release of, a branch. 
So green CI for a feature (excepting feature-specific tests if it's still a 
work in progress), experimental flag if we don't consider it prod ready, should 
be absolute bare minimum for anything to merge really IMO.

On Wed, Oct 25, 2023, at 4:17 AM, Benjamin Lerer wrote:
> The proposal includes 3 things:
> 1. Do not include TCM and Accord in 5.0 to avoid delaying 5.0
> 2. The next release will be 5.1 and will include only Accord and TCM
> 3. Merge TCM and Accord right now in 5.1 (making an initial release)
> 
> I am fine with question 1 and do not have a strong opinion on which way to go.
> 2. Means that every new feature will have to wait for post 5.1 even if it is 
> ready before 5.1 is stabilized and shipped. If we do a 5.1 release why not 
> take it as an opportunity to release more things. I am not saying that we 
> will. Just that we should let that door open.
> 3. There is a need to merge TCM and Accord as maintaining those separate 
> branches is costly in terms of time and energy. I fully understand that. On 
> the other hand merging TCM and Accord will make the TCM review harder and I 
> do believe that this second round of review is valuable as it already 
> uncovered a valid issue. Nevertheless, I am fine with merging TCM as soon as 
> it passes CI and continuing the review after the merge. If we cannot meet at 
> least that quality level (Green CI) we should not merge just for creating an 
> 5.1.alpha release for the summit.
> 
> Now, I am totally fine with a preview release without numbering and with big 
> warnings that will only serve as a preview for the summit.
> 
> Le mer. 25 oct. 2023 à 06:33, Berenguer Blasi  a 
> écrit :
>> I also think there's many good new features in 5.0 already they'd make a 
>> good release even on their own. My 2 cts.
>> 
>> On 24/10/23 23:20, Brandon Williams wrote:
>> > The catch here is that we don't publish docker images currently.  The
>> > C* docker images available are not made by us.
>> >
>> > Kind Regards,
>> > Brandon
>> >
>> > On Tue, Oct 24, 2023 at 3:31 PM Patrick McFadin  wrote:
>> >> Let me make that really easy. Hell yes
>> >>
>> >> Not everybody runs CCM, I've tried but I've met resistance.
>> >>
>> >> Compiling your own version usually involves me saying the words "Yes, ant 
>> >> realclean exists. I'm not trolling you"
>> >>
>> >> docker pull  works on every OS and curates a single node 
>> >> experience.
>> >>
>> >>
>> >>
>> >> On Tue, Oct 24, 2023 at 12:37 PM Josh McKenzie  
>> >> wrote:
>> >>> In order for the project to advertise the release outside the dev@ list 
>> >>> it needs to be a formal release.
>> >>>
>> >>> That's my reading as well:
>> >>> https://www.apache.org/legal/release-policy.html#release-definition
>> >>>
>> >>> I wonder if there'd be value in us having a cronned job that'd do 
>> >>> nightly docker container builds on trunk + feature branches, archived 
>> >>> for N days, and we make that generally known to the dev@ list here so 
>> >>> folks that want to poke at the current state of trunk or other branches 
>> >>> could do so with very low friction. We'd probably see more engagement on 
>> >>> feature branches if it was turn-key easy for other C* devs to spin the 
>> >>> up and check them out.
>> >>>
>> >>> For what you're talking about here Patrick (a docker image for folks 
>> >>> outside the dev@ audience and more user-facing), we'd want to vote on it 
>> >>> and go through the formal process.
>> >>>
>> >>> On Tue, Oct 24, 2023, at 3:10 PM, Jeremiah Jordan wrote:
>> >>>
>> >>> In order for the project to advertise the release outside the dev@ list 
>> >>> it needs to be a formal release.  That just means that there was a 
>> >>> release vote and at least 3 PMC members +1’ed it, and there are more +1 
>> >>> than there are -1, and we follow all the normal release rules.  The ASF 
>> >>> release process doesn’t care what branch you cut the artifacts from or 
>> >>> what version you call it.
>> >>>
>> >>> So the project can cut artifacts for and release a 5.1-alpha1, 
>> >>> 5.1-dev-preview1, what ever we want to version this thing, from trunk or 
>> >>> any other branch name we want.
>> >>>
>> >>> -Jeremiah
>> >>>
>> >>> On Oct 24, 2023 at 2:03:41 PM, Patrick McFadin  
>> >>> wrote:
>> >>>
>> >>> I would like to have something for developers to use ASAP to try the 
>> >>> Accord syntax. Very few people have seen it, and I think there's a 
>> >>> learning curve we can start earlier.
>> >>>
>> >>> It's my understanding that ASF policy is that it needs to be a project 
>> >>> release to create a docker image.
>> >>>
>> >>> On Tue, Oct 24, 2023 at 11:54 AM Jeremiah Jordan 
>> >>>  wrote:
>> >>>
>> >>> If we decide to go the route of not merging TCM to the 5.0 branch.  Do 
>> >>> we actual

Re: CASSANDRA-18941 produce size bounded SSTables from CQLSSTableWriter

[Doug Rohrer]

+1 (nb) - wiłl be nice for the analytics writer to be able to size SSTables 
appropriately and efficiently.

Doug

> On Oct 24, 2023, at 10:36 PM, guo Maxwell  wrote:
> 
> 😄
> 
> Chris Lohfink mailto:clohfin...@gmail.com>> 
> 于2023年10月25日周三 05:02写道：
>> +1
>> 
>> On Tue, Oct 24, 2023 at 11:24 AM Brandon Williams > > wrote:
>>> +1
>>> 
>>> Kind Regards,
>>> Brandon
>>> 
>>> On Mon, Oct 23, 2023 at 6:22 PM Yifan Cai >> > wrote:
>>> >
>>> > Hi,
>>> >
>>> > I want to propose merging the patch in CASSANDRA-18941 to 4.0 and up to 
>>> > trunk and hope we are all OK with it.
>>> >
>>> > In CASSANDRA-18941, I am adding the capability to produce size-bounded 
>>> > SSTables in CQLSSTableWriter for sorted data. It can greatly benefit 
>>> > Cassandra Analytics (https://github.com/apache/cassandra-analytics) for 
>>> > bulk writing SSTables, since it avoids buffering and sorting on flush, 
>>> > given the data source is sorted already in the bulk write process. 
>>> > Cassandra Analytics supports Cassandra 4.0 and depends on the 
>>> > cassandra-all 4.0.x library. Therefore, we are mostly interested in using 
>>> > the new capability in 4.0.
>>> >
>>> > CQLSSTableWriter is only used in offline tools and never in the code path 
>>> > of Cassandra server.
>>> >
>>> > Any objections to merging the patch to 4.0 and up to trunk?
>>> >
>>> > - Yifan

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Jeremiah Jordan]

>
> If we do a 5.1 release why not take it as an opportunity to release more
> things. I am not saying that we will. Just that we should let that door
> open.
>

Agreed.  This is the reason I brought up the possibility of not branching
off 5.1 immediately.


On Oct 25, 2023 at 3:17:13 AM, Benjamin Lerer  wrote:

> The proposal includes 3 things:
> 1. Do not include TCM and Accord in 5.0 to avoid delaying 5.0
> 2. The next release will be 5.1 and will include only Accord and TCM
> 3. Merge TCM and Accord right now in 5.1 (making an initial release)
>
> I am fine with question 1 and do not have a strong opinion on which way to
> go.
> 2. Means that every new feature will have to wait for post 5.1 even if it
> is ready before 5.1 is stabilized and shipped. If we do a 5.1 release why
> not take it as an opportunity to release more things. I am not saying that
> we will. Just that we should let that door open.
> 3. There is a need to merge TCM and Accord as maintaining those separate
> branches is costly in terms of time and energy. I fully understand that. On
> the other hand merging TCM and Accord will make the TCM review harder and I
> do believe that this second round of review is valuable as it already
> uncovered a valid issue. Nevertheless, I am fine with merging TCM as soon
> as it passes CI and continuing the review after the merge. If we cannot
> meet at least that quality level (Green CI) we should not merge just for
> creating an 5.1.alpha release for the summit.
>
> Now, I am totally fine with a preview release without numbering and with
> big warnings that will only serve as a preview for the summit.
>
> Le mer. 25 oct. 2023 à 06:33, Berenguer Blasi 
> a écrit :
>
>> I also think there's many good new features in 5.0 already they'd make a
>> good release even on their own. My 2 cts.
>>
>> On 24/10/23 23:20, Brandon Williams wrote:
>> > The catch here is that we don't publish docker images currently.  The
>> > C* docker images available are not made by us.
>> >
>> > Kind Regards,
>> > Brandon
>> >
>> > On Tue, Oct 24, 2023 at 3:31 PM Patrick McFadin 
>> wrote:
>> >> Let me make that really easy. Hell yes
>> >>
>> >> Not everybody runs CCM, I've tried but I've met resistance.
>> >>
>> >> Compiling your own version usually involves me saying the words "Yes,
>> ant realclean exists. I'm not trolling you"
>> >>
>> >> docker pull  works on every OS and curates a single node
>> experience.
>> >>
>> >>
>> >>
>> >> On Tue, Oct 24, 2023 at 12:37 PM Josh McKenzie 
>> wrote:
>> >>> In order for the project to advertise the release outside the dev@
>> list it needs to be a formal release.
>> >>>
>> >>> That's my reading as well:
>> >>> https://www.apache.org/legal/release-policy.html#release-definition
>> >>>
>> >>> I wonder if there'd be value in us having a cronned job that'd do
>> nightly docker container builds on trunk + feature branches, archived for N
>> days, and we make that generally known to the dev@ list here so folks
>> that want to poke at the current state of trunk or other branches could do
>> so with very low friction. We'd probably see more engagement on feature
>> branches if it was turn-key easy for other C* devs to spin the up and check
>> them out.
>> >>>
>> >>> For what you're talking about here Patrick (a docker image for folks
>> outside the dev@ audience and more user-facing), we'd want to vote on it
>> and go through the formal process.
>> >>>
>> >>> On Tue, Oct 24, 2023, at 3:10 PM, Jeremiah Jordan wrote:
>> >>>
>> >>> In order for the project to advertise the release outside the dev@
>> list it needs to be a formal release.  That just means that there was a
>> release vote and at least 3 PMC members +1’ed it, and there are more +1
>> than there are -1, and we follow all the normal release rules.  The ASF
>> release process doesn’t care what branch you cut the artifacts from or what
>> version you call it.
>> >>>
>> >>> So the project can cut artifacts for and release a 5.1-alpha1,
>> 5.1-dev-preview1, what ever we want to version this thing, from trunk or
>> any other branch name we want.
>> >>>
>> >>> -Jeremiah
>> >>>
>> >>> On Oct 24, 2023 at 2:03:41 PM, Patrick McFadin 
>> wrote:
>> >>>
>> >>> I would like to have something for developers to use ASAP to try the
>> Accord syntax. Very few people have seen it, and I think there's a learning
>> curve we can start earlier.
>> >>>
>> >>> It's my understanding that ASF policy is that it needs to be a
>> project release to create a docker image.
>> >>>
>> >>> On Tue, Oct 24, 2023 at 11:54 AM Jeremiah Jordan <
>> jeremiah.jor...@gmail.com> wrote:
>> >>>
>> >>> If we decide to go the route of not merging TCM to the 5.0 branch.
>> Do we actually need to immediately cut a 5.1 branch?  Can we work on
>> stabilizing things while it is in trunk and cut the 5.1 branch when we
>> actually think we are near releasing?  I don’t see any reason we can not
>> cut “preview” artifacts from trunk?
>> >>>
>> >>> -Jeremiah
>> >>>
>> >>> On Oct 24, 2023 a

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Ekaterina Dimitrova]

Hi everyone,
Thanks, Mick, for raising the topic.

I support having released 5.0 without waiting on Accord and TCM as
previously discussed here. (we are almost November, and the features
are not ready. The currently committed set is glamorous in its own way
:-) )https://lists.apache.org/thread/9c5cnn57c7oqw8wzo3zs0dkrm4f17lm3

I support releasing 5.1 when TCM and Accord are ready and not
necessarily waiting another year for 5.1, next release.


Now, in more detail, what my understanding is and what I did just
supported exactly:

"2. The next release will be 5.1 and will include only Accord and TCM"
I read the current thread, and I didn't see a mention that we are not
accepting anything else to trunk in the meantime until those are ready
and reviewed. I do not see an issue with accepting other works in the
meantime as long as everyone adheres to our approach of merging
finished, fully reviewed, and tested working patches.

"The TCM work (CEP-21) is in its review stage but being well past our
cut-off date¹ for merging, and now jeopardising 5.0 GA efforts, I would
like to propose the following."
I feel this statement is maybe a bit confusing as there were no new
patches (except a doc and harry version change) since this
conversation 
happened:https://the-asf.slack.com/archives/CK23JSY2K/p1695654432116079

This means to me that we are doing high-level checks and building
understanding at the moment (that's actually great; I am very happy we
are doing it), but the full-fledged review hasn't started because the
code is not yet fully committed.

"Reviewing of TCM and Accord will continue to happen post-merge. This is
not our normal practice, but this work will have already received its
two +1s from committers, and such ongoing review effort is akin to GA
stabilisation work on release branches."
My reading here is that a review, as per our project guidelines, by
two committers, will happen before the merge. As usual, if there is
some exception or something - it should be brought to the dev ML for
discussion. https://cassandra.apache.org/_/development/how_to_review.html
(feature flags are not mentioned in the doc, but we have it somewhere
on the ML for sure)
 BUT as it is a big piece of work, as it happens with many
features - there might be more than 2 reviewers involved. Normally, we
wait until everyone is done, not only as long as we have two
committers +1s and ignore the others (as long as they do not have
immediate concerns). My understanding of Mick's suggestion is if
people are not ready with their reviews and they do not have immediate
concerns to raise - things can be merged based on the two committers
who are confident the features meet our standards. I have a  strong
preference to wait on everyone, but I am not going to block anything
as long as we have the two reviewers confident and green CI, as usual.
Then, the rest of the reviewers can continue testing and reviewing,
and the authors will stay available to address any new
concerns/questions/feedback. (Overall, we know that the CLA says
contributions are accepted on "AS-IS" basis
(https://www.apache.org/licenses/icla.pdf), but the authors will make
a waiver in this case and ensure things are addressed in a reasonable
timeframe before a release (not two years later :D ); correct me if I
am wrong but that is how I read Mick's suggestion.)

Last but not least, I think we probably need a separate discussion
thread on the preview release with all the details, as this is
something we all agree is nice to have, but we haven't done it before,
and the details are unclear. I think the current discussion thread
proves that calling an early preview alpha1 gives a wrong perspective
of the state of affairs to our users. But overall, I am not against
having an early preview; we need to shape only the form of it. I think
this is a very good call.

Best regards,

Ekaterina



On Wed, 25 Oct 2023 at 12:07, Jeremiah Jordan 
wrote:

> If we do a 5.1 release why not take it as an opportunity to release more
>> things. I am not saying that we will. Just that we should let that door
>> open.
>>
>
> Agreed.  This is the reason I brought up the possibility of not branching
> off 5.1 immediately.
>
>
> On Oct 25, 2023 at 3:17:13 AM, Benjamin Lerer  wrote:
>
>> The proposal includes 3 things:
>> 1. Do not include TCM and Accord in 5.0 to avoid delaying 5.0
>> 2. The next release will be 5.1 and will include only Accord and TCM
>> 3. Merge TCM and Accord right now in 5.1 (making an initial release)
>>
>> I am fine with question 1 and do not have a strong opinion on which way
>> to go.
>> 2. Means that every new feature will have to wait for post 5.1 even if it
>> is ready before 5.1 is stabilized and shipped. If we do a 5.1 release why
>> not take it as an opportunity to release more things. I am not saying that
>> we will. Just that we should let that door open.
>> 3. There is a need to merge TCM and Accord as maintaining those separate
>> branches is costly in terms of time

Re: [DISCUSS] Backport CASSANDRA-18816 to 5.0? Add support for repair coordinator to retry messages that timeout

[David Capwell]

IR patch is up for review https://issues.apache.org/jira/browse/CASSANDRA-18962

> On Oct 24, 2023, at 3:15 PM, David Capwell  wrote:
> 
> I sat down to add IR messages to the mix… given how positive the feedback was 
> for other repair messages I assume people are still ok with this new IR work 
> going to 5.0 as well, if not please let me know here (will send a patch 
> tomorrow).
> 
> Once I send out the patch 100% of repair messages have retry logic
> 
>> On Sep 26, 2023, at 12:08 PM, David Capwell  wrote:
>> 
>> Thanks all for the feedback!  The patch has 2 +1s on trunk and back ported 
>> to 5.0, making sure it’s stable now; I plan to merge early this week.
>> 
>>> On Sep 21, 2023, at 2:07 PM, Ekaterina Dimitrova  
>>> wrote:
>>> 
>>> +1 from me too. Moreover, this work has started as part of the test efforts 
>>> and identifying weak points during the 4.0 testing, if I recall correctly. 
>>> 5.0 sounds like a good place to land. Thank you David and everyone else 
>>> involved for your efforts!
>>> 
>>> On Thu, 21 Sep 2023 at 1:01, Berenguer Blasi >> > wrote:
 +1 I agree with Brandon. It's more like a bug imo.
 On 20/9/23 21:42, Caleb Rackliffe wrote:
> +1 on a 5.0 backport
> 
> On Wed, Sep 20, 2023 at 2:26 PM Brandon Williams  > wrote:
>> I think it could be argued that not retrying messages is a bug, I am
>> +1 on including this in 5.0.
>> 
>> Kind Regards,
>> Brandon
>> 
>> On Tue, Sep 19, 2023 at 1:16 PM David Capwell > > wrote:
>> >
>> > To try to get repair more stable, I added optional retry logic (patch 
>> > is still in review) to a handful of critical repair verbs.  This patch 
>> > is disabled by default but allows you to opt-in to retries so 
>> > ephemeral issues don’t cause a repair to fail after running for a long 
>> > time (assuming they resolve within the retry window). There are 2 
>> > protocol level changes to enable this: VALIDATION_RSP and SYNC_RSP now 
>> > send an ACK (if the sender doesn’t attach a callback, these ACKs get 
>> > ignored in all versions; see org.apache.cassandra.net 
>> > .ResponseVerbHandler#doVerb and 
>> > Verb.REPAIR_RSP).  Given that we have already forked, I believe we 
>> > would need to give a waiver to allow this patch due to this change.
>> >
>> > The patch was written on trunk, but figured back porting 5.0 would be 
>> > rather trivial and this was brought up during the review, so floating 
>> > this to a wider audience.
>> >
>> > If you look at the patch you will see that it is very large, but this 
>> > is only to make testing of repair coordination easier and 
>> > deterministic, the biggest code changes are:
>> >
>> > 1) Moving from ActiveRepairService.instance to 
>> > ActiveRepairService.instance() (this is the main reason so many files 
>> > were touched; this was needed so unit tests don’t load the whole world)
>> > 2) Repair no longer reaches into global space and instead is provided 
>> > the subsystems needed to perform repair; this change is local to 
>> > repair code
>> >
>> > Both of these changes were only for testing as they allow us to 
>> > simulate 1k repairs in around 15 seconds with 100% deterministic 
>> > execution.
>> 
> 

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Mick Semb Wever]

I'm open to the suggestions of not branching cassandra-5.1 and/or naming a
preview release something other than 5.1-alpha1.

But… the codebases and release process (and upgrade tests) do not currently
support releases with qualifiers that are not alpha, beta, or rc.  We can
add a preview qualifier to this list, but I would not want to block getting
a preview release out only because this wasn't yet in place.

Hence the proposal used 5.1-alpha1 simply because that's what we know we
can do today.  An alpha release also means (typically) the branch.

Is anyone up for looking into adding a "preview" qualifier to our release
process?
This may also solve our previous discussions and desire to have quarterly
releases that folk can use through the trunk dev cycle.

Personally, with my understanding of timelines in front of us to fully
review and stabilise tcm, it makes sense to branch it as soon as it's
merged.  It's easiest to stabilise it on a branch, and there's definitely
the desire and demand to do so, so it won't be getting forgotten or
down-prioritised.



On Wed, 25 Oct 2023 at 18:07, Jeremiah Jordan 
wrote:

> If we do a 5.1 release why not take it as an opportunity to release more
>> things. I am not saying that we will. Just that we should let that door
>> open.
>>
>
> Agreed.  This is the reason I brought up the possibility of not branching
> off 5.1 immediately.
>
>
> On Oct 25, 2023 at 3:17:13 AM, Benjamin Lerer  wrote:
>
>> The proposal includes 3 things:
>> 1. Do not include TCM and Accord in 5.0 to avoid delaying 5.0
>> 2. The next release will be 5.1 and will include only Accord and TCM
>> 3. Merge TCM and Accord right now in 5.1 (making an initial release)
>>
>> I am fine with question 1 and do not have a strong opinion on which way
>> to go.
>> 2. Means that every new feature will have to wait for post 5.1 even if it
>> is ready before 5.1 is stabilized and shipped. If we do a 5.1 release why
>> not take it as an opportunity to release more things. I am not saying that
>> we will. Just that we should let that door open.
>> 3. There is a need to merge TCM and Accord as maintaining those separate
>> branches is costly in terms of time and energy. I fully understand that. On
>> the other hand merging TCM and Accord will make the TCM review harder and I
>> do believe that this second round of review is valuable as it already
>> uncovered a valid issue. Nevertheless, I am fine with merging TCM as soon
>> as it passes CI and continuing the review after the merge. If we cannot
>> meet at least that quality level (Green CI) we should not merge just for
>> creating an 5.1.alpha release for the summit.
>>
>> Now, I am totally fine with a preview release without numbering and with
>> big warnings that will only serve as a preview for the summit.
>>
>> Le mer. 25 oct. 2023 à 06:33, Berenguer Blasi 
>> a écrit :
>>
>>> I also think there's many good new features in 5.0 already they'd make a
>>> good release even on their own. My 2 cts.
>>>
>>> On 24/10/23 23:20, Brandon Williams wrote:
>>> > The catch here is that we don't publish docker images currently.  The
>>> > C* docker images available are not made by us.
>>> >
>>> > Kind Regards,
>>> > Brandon
>>> >
>>> > On Tue, Oct 24, 2023 at 3:31 PM Patrick McFadin 
>>> wrote:
>>> >> Let me make that really easy. Hell yes
>>> >>
>>> >> Not everybody runs CCM, I've tried but I've met resistance.
>>> >>
>>> >> Compiling your own version usually involves me saying the words "Yes,
>>> ant realclean exists. I'm not trolling you"
>>> >>
>>> >> docker pull  works on every OS and curates a single node
>>> experience.
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Oct 24, 2023 at 12:37 PM Josh McKenzie 
>>> wrote:
>>> >>> In order for the project to advertise the release outside the dev@
>>> list it needs to be a formal release.
>>> >>>
>>> >>> That's my reading as well:
>>> >>> https://www.apache.org/legal/release-policy.html#release-definition
>>> >>>
>>> >>> I wonder if there'd be value in us having a cronned job that'd do
>>> nightly docker container builds on trunk + feature branches, archived for N
>>> days, and we make that generally known to the dev@ list here so folks
>>> that want to poke at the current state of trunk or other branches could do
>>> so with very low friction. We'd probably see more engagement on feature
>>> branches if it was turn-key easy for other C* devs to spin the up and check
>>> them out.
>>> >>>
>>> >>> For what you're talking about here Patrick (a docker image for folks
>>> outside the dev@ audience and more user-facing), we'd want to vote on
>>> it and go through the formal process.
>>> >>>
>>> >>> On Tue, Oct 24, 2023, at 3:10 PM, Jeremiah Jordan wrote:
>>> >>>
>>> >>> In order for the project to advertise the release outside the dev@
>>> list it needs to be a formal release.  That just means that there was a
>>> release vote and at least 3 PMC members +1’ed it, and there are more +1
>>> than there are -1, and we follow all the normal release ru

Re: CASSANDRA-18941 produce size bounded SSTables from CQLSSTableWriter

[Yifan Cai]

Thanks everyone! I have updated CASSANDRA-18941 with PRs to each branch,
i.e. cassandra-4.0, cassandra-4.1, cassandra-5.0 and cassandra-trunk.

- Yifan

On Wed, Oct 25, 2023 at 7:00 AM Doug Rohrer  wrote:

> +1 (nb) - wiłl be nice for the analytics writer to be able to size
> SSTables appropriately and efficiently.
>
> Doug
>
> On Oct 24, 2023, at 10:36 PM, guo Maxwell  wrote:
>
> 😄
>
> Chris Lohfink  于2023年10月25日周三 05:02写道：
>
>> +1
>>
>> On Tue, Oct 24, 2023 at 11:24 AM Brandon Williams 
>> wrote:
>>
>>> +1
>>>
>>> Kind Regards,
>>> Brandon
>>>
>>> On Mon, Oct 23, 2023 at 6:22 PM Yifan Cai  wrote:
>>> >
>>> > Hi,
>>> >
>>> > I want to propose merging the patch in CASSANDRA-18941 to 4.0 and up
>>> to trunk and hope we are all OK with it.
>>> >
>>> > In CASSANDRA-18941, I am adding the capability to produce size-bounded
>>> SSTables in CQLSSTableWriter for sorted data. It can greatly benefit
>>> Cassandra Analytics (https://github.com/apache/cassandra-analytics) for
>>> bulk writing SSTables, since it avoids buffering and sorting on flush,
>>> given the data source is sorted already in the bulk write process.
>>> Cassandra Analytics supports Cassandra 4.0 and depends on the cassandra-all
>>> 4.0.x library. Therefore, we are mostly interested in using the new
>>> capability in 4.0.
>>> >
>>> > CQLSSTableWriter is only used in offline tools and never in the code
>>> path of Cassandra server.
>>> >
>>> > Any objections to merging the patch to 4.0 and up to trunk?
>>> >
>>> > - Yifan
>>>
>>
>

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Benedict]

I am surprised this needs to be said, but - especially for long-running CEPs - you must involve yourself early, and certainly within some reasonable time of being notified the work is ready for broader input and review. In this case, more than six months ago.

This isn’t the first time this has happened, and it is disappointing to see it again. Clearly we need to make this explicit in the guidance docs.

Regarding the release of 5.1, I understood the proposal to be that we cut an actual alpha, thereby sealing the 5.1 release from new features. Only features merged before we cut the alpha would be permitted, and the alpha should be cut as soon as practicable. What exactly would we be waiting for? 

If we don’t have a clear and near-term trigger for branching 5.1 for its own release, shortly after Accord and TCM merge, then I am in favour of instead delaying 5.0.On 25 Oct 2023, at 19:40, Mick Semb Wever  wrote:I'm open to the suggestions of not branching cassandra-5.1 and/or naming a preview release something other than 5.1-alpha1.But… the codebases and release process (and upgrade tests) do not currently support releases with qualifiers that are not alpha, beta, or rc.  We can add a preview qualifier to this list, but I would not want to block getting a preview release out only because this wasn't yet in place.  Hence the proposal used 5.1-alpha1 simply because that's what we know we can do today.  An alpha release also means (typically) the branch.Is anyone up for looking into adding a "preview" qualifier to our release process? This may also solve our previous discussions and desire to have quarterly releases that folk can use through the trunk dev cycle.Personally, with my understanding of timelines in front of us to fully review and stabilise tcm, it makes sense to branch it as soon as it's merged.  It's easiest to stabilise it on a branch, and there's definitely the desire and demand to do so, so it won't be getting forgotten or down-prioritised.   On Wed, 25 Oct 2023 at 18:07, Jeremiah Jordan  wrote:
If we do a 5.1 release why not take it as an opportunity to release more things. I am not saying that we will. Just that we should let that door open.
Agreed.  This is the reason I brought up the possibility of not branching off 5.1 immediately.


On Oct 25, 2023 at 3:17:13 AM, Benjamin Lerer  wrote:

The proposal includes 3 things:1. Do not include TCM and Accord in 5.0 to avoid delaying 5.02. The next release will be 5.1 and will include only Accord and TCM3. Merge TCM and Accord right now in 5.1 (making an initial release)I am fine with question 1 and do not have a strong opinion on which way to go.2. Means that every new feature will have to wait for post 5.1 even if it is ready before 5.1 is stabilized and shipped. If we do a 5.1 release why not take it as an opportunity to release more things. I am not saying that we will. Just that we should let that door open.3. There is a need to merge TCM and Accord as maintaining those separate branches is costly in terms of time and energy. I fully understand that. On the other hand merging TCM and Accord will make the TCM review harder and I do believe that this second round of review is valuable as it already uncovered a valid issue. Nevertheless, I am fine with merging TCM as soon as it passes CI and continuing the review after the merge. If we cannot meet at least that quality level (Green CI) we should not merge just for creating an 5.1.alpha release for the summit.Now, I am totally fine with a preview release without numbering and with big warnings that will only serve as a preview for the summit.Le mer. 25 oct. 2023 à 06:33, Berenguer Blasi  a écrit :I also think there's many good new features in 5.0 already they'd make a 
good release even on their own. My 2 cts.

On 24/10/23 23:20, Brandon Williams wrote:
> The catch here is that we don't publish docker images currently.  The
> C* docker images available are not made by us.
>
> Kind Regards,
> Brandon
>
> On Tue, Oct 24, 2023 at 3:31 PM Patrick McFadin  wrote:
>> Let me make that really easy. Hell yes
>>
>> Not everybody runs CCM, I've tried but I've met resistance.
>>
>> Compiling your own version usually involves me saying the words "Yes, ant realclean exists. I'm not trolling you"
>>
>> docker pull  works on every OS and curates a single node experience.
>>
>>
>>
>> On Tue, Oct 24, 2023 at 12:37 PM Josh McKenzie  wrote:
>>> In order for the project to advertise the release outside the dev@ list it needs to be a formal release.
>>>
>>> That's my reading as well:
>>> https://www.apache.org/legal/release-policy.html#release-definition
>>>
>>> I wonder if there'd be value in us having a cronned job that'd do nightly docker container builds on trunk + feature branches, archived for N days, and we make that generally known to the dev@ list here so folks that want to poke 

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

[Benedict]

I have spoken privately with Ekaterina, and to clear up some possible ambiguity: I realise nobody has demanded a delay to this work to conduct additional reviews; a couple of folk have however said they would prefer one.

My point is that, as a community, we need to work on ensuring folk that care about a CEP participate at an appropriate time. If they aren’t able to, the consequences of that are for them to bear. We should be working to avoid surprises as CEP start to land. To this end, I think we should work on some additional paragraphs for the governance doc covering expectations around the landing of CEPs.On 25 Oct 2023, at 21:55, Benedict  wrote:I am surprised this needs to be said, but - especially for long-running CEPs - you must involve yourself early, and certainly within some reasonable time of being notified the work is ready for broader input and review. In this case, more than six months ago.

This isn’t the first time this has happened, and it is disappointing to see it again. Clearly we need to make this explicit in the guidance docs.

Regarding the release of 5.1, I understood the proposal to be that we cut an actual alpha, thereby sealing the 5.1 release from new features. Only features merged before we cut the alpha would be permitted, and the alpha should be cut as soon as practicable. What exactly would we be waiting for? 

If we don’t have a clear and near-term trigger for branching 5.1 for its own release, shortly after Accord and TCM merge, then I am in favour of instead delaying 5.0.On 25 Oct 2023, at 19:40, Mick Semb Wever  wrote:I'm open to the suggestions of not branching cassandra-5.1 and/or naming a preview release something other than 5.1-alpha1.But… the codebases and release process (and upgrade tests) do not currently support releases with qualifiers that are not alpha, beta, or rc.  We can add a preview qualifier to this list, but I would not want to block getting a preview release out only because this wasn't yet in place.  Hence the proposal used 5.1-alpha1 simply because that's what we know we can do today.  An alpha release also means (typically) the branch.Is anyone up for looking into adding a "preview" qualifier to our release process? This may also solve our previous discussions and desire to have quarterly releases that folk can use through the trunk dev cycle.Personally, with my understanding of timelines in front of us to fully review and stabilise tcm, it makes sense to branch it as soon as it's merged.  It's easiest to stabilise it on a branch, and there's definitely the desire and demand to do so, so it won't be getting forgotten or down-prioritised.   On Wed, 25 Oct 2023 at 18:07, Jeremiah Jordan  wrote:
If we do a 5.1 release why not take it as an opportunity to release more things. I am not saying that we will. Just that we should let that door open.
Agreed.  This is the reason I brought up the possibility of not branching off 5.1 immediately.


On Oct 25, 2023 at 3:17:13 AM, Benjamin Lerer  wrote:

The proposal includes 3 things:1. Do not include TCM and Accord in 5.0 to avoid delaying 5.02. The next release will be 5.1 and will include only Accord and TCM3. Merge TCM and Accord right now in 5.1 (making an initial release)I am fine with question 1 and do not have a strong opinion on which way to go.2. Means that every new feature will have to wait for post 5.1 even if it is ready before 5.1 is stabilized and shipped. If we do a 5.1 release why not take it as an opportunity to release more things. I am not saying that we will. Just that we should let that door open.3. There is a need to merge TCM and Accord as maintaining those separate branches is costly in terms of time and energy. I fully understand that. On the other hand merging TCM and Accord will make the TCM review harder and I do believe that this second round of review is valuable as it already uncovered a valid issue. Nevertheless, I am fine with merging TCM as soon as it passes CI and continuing the review after the merge. If we cannot meet at least that quality level (Green CI) we should not merge just for creating an 5.1.alpha release for the summit.Now, I am totally fine with a preview release without numbering and with big warnings that will only serve as a preview for the summit.Le mer. 25 oct. 2023 à 06:33, Berenguer Blasi  a écrit :I also think there's many good new features in 5.0 already they'd make a 
good release even on their own. My 2 cts.

On 24/10/23 23:20, Brandon Williams wrote:
> The catch here is that we don't publish docker images currently.  The
> C* docker images available are not made by us.
>
> Kind Regards,
> Brandon
>
> On Tue, Oct 24, 2023 at 3:31 PM Patrick McFadin  wrote:
>> Let me make that really easy. Hell yes
>>
>> Not everybody runs CCM, I've tried but I've met resistance.
>>
>> Compiling your own version usually involves me saying the words "Yes, a

Re: CASSANDRA-18775 (Cassandra supported OSs)

[Claude Warren, Jr via dev]

I closed 18775 as it did not seem reasonable after discussions here.  I
have been working on 16565 and have a pull request [1] and an experimental
suite to show the differences. [2]

[1]  https://github.com/apache/cassandra/pull/2842
[2]  https://github.com/Aiven-Labs/compare_oshi_sigar

On Wed, Oct 25, 2023 at 2:59 PM Josh McKenzie  wrote:

> +1 to drop if we're not using.
>
> On Fri, Oct 20, 2023, at 6:58 PM, Ekaterina Dimitrova wrote:
>
> +1 on removal the whole lib if we are sure we don’t need it. Nothing
> better than some healthy house cleaning
>
>  -1 on partial removals
>
> On Fri, 20 Oct 2023 at 17:34, David Capwell  wrote:
>
> +1 to drop the whole lib…
>
>
> On Oct 20, 2023, at 7:55 AM, Jeremiah Jordan 
> wrote:
>
> Agreed.  -1 on selectively removing any of the libs.  But +1 for removing
> the whole thing if it is no longer used.
>
> -Jeremiah
>
> On Oct 20, 2023 at 9:28:55 AM, Mick Semb Wever  wrote:
>
> Does anyone see any reason _not_ to do this?
>
>
>
> Thanks for bring this to dev@
>
> I see reason not to do it, folk do submit patches for other archs despite
> us not formally maintaining and testing the code for those archs.  Some
> examples are PPC64 Big Endian (CASSANDRA-7476), s390x (CASSANDRA-17723),
> PPC64 Little Endian (CASSANDRA-7381), sparcv9 (CASSANDRA-6628).  Wrote this
> on the ticket too.
>
> +1 for removing sigar altogether (as Brandon points out).
>
>
>