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
> 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
> 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
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:]]*$'
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
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
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
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
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