Re: [DISCUSS] CASSANDRA-15234

2021-09-10 Thread Patrick McFadin
Ah, I feel like cassandra.yaml discussions are such an evergreen topic. This was something brought up a while back, but I remember years ago we talked about emulating the config options that some other databases have done. Providing different versions of the config for different approaches. For

Re: [DISCUSS] CASSANDRA-15234

2021-09-10 Thread Jeremiah D Jordan
> Also, if you run the above command you will see we actually have a lot of > things show (129 lines)… it would be nice to clean it up as only a small > subset is required and most shown normal users won’t care +1 for this. It would be good to clean up the config code and yaml such that only

Re: Defining which code changes target which release types

2021-09-10 Thread David Capwell
> I believe that always having a feature flag for every new feature might be > too complicated in practice for different reasons. > Some new features might be low impact like new nodetool commands or new > virtual tables and adding flags for those might simply be extra > complication for the

Re: [DISCUSS] CASSANDRA-15234

2021-09-10 Thread David Capwell
We can have both, but I would hope we do not have humans maintaining both. If we maintain the commented one, and did something like the below while we compile then the burden to maintain doesn’t exist # remove comments and empty lines $ egrep -v '^[[:space:]]*#|^[[:space:]]*$'

Re: Defining which code changes target which release types

2021-09-10 Thread Joshua McKenzie
I put together a gdoc documenting what was in this thread - should be open to comment for everyone: https://docs.google.com/document/d/1LhCNcbuhtqTkv_aKx1TQUgWEcq022fsAZs1C_oOxEJw/edit I'll let this thread sit to early next week and assuming no major concerns we'll get that into either the wiki

Re: Keeping on top of test failures

2021-09-10 Thread Joshua McKenzie
Thanks for the feedback everyone. Drafting site changes now and I'll pull the trigger on JIRA probably Monday; give people the weekend to chew on this. If I open up the window to 52 weeks, we still only have 13 of the test failure tickets being created in that window. Figure it's probably safe to

Re: [DISCUSS] Java 17 support - Nashorn removed

2021-09-10 Thread Ekaterina Dimitrova
Hey Aleksei, Thank you so much for looking into this! Really appreciate it! Indeed, maven says UPL but if you look at the License file here, it says GPL2 https://github.com/oracle/graal And now looking at the bottom of the Readme there is a table that says particular components, including the sdk

Re: [DISCUSS] Java 17 support - Nashorn removed

2021-09-10 Thread Aleksei Zotov
Hi Ekaterina, It seems /graal-sdk/ is licensed under UPL license as well (see https://github.com/oracle/graal/tree/master/sdk): > GraalVM SDK is licensed under the Universal Permissive License. Also it is marked as UPL in Maven Central (see

Re: [DISCUSS] Diagnostic events in virtual tables

2021-09-10 Thread Stefan Miklosovic
Hi Mick, I returned to this after some time and here are my questions about this. I am waiting for 16806 to be merged which introduces abstract mutable vtables (1) on top of which I want to build what you have proposed. I do not think we need a non-virtual table for this and this is actually