Next week I plan to rename master branches on the cassandra-builds,
cassandra-website and cassandra-dtest repositories to trunk.
This was discussed in
https://lists.apache.org/thread.html/r54db4cd870d2d665060d5fb50d925843be4b4d54dc64f3d21f04c367%40%3Cdev.cassandra.apache.org%3E
The general prefer
What are next steps here?
Maybe we collectively put a table together w/the 2 operators and a list of
features to compare and contrast? Enumerate the frameworks / dependencies
they have to help form a point of view about the strengths and weaknesses
of each option?
On Tue, Sep 29, 2020 at 10:22 P
+1 generally. We should do this for the sidecar repo as well.
Dinesh
> On Oct 2, 2020, at 2:17 AM, Mick Semb Wever wrote:
>
> Next week I plan to rename master branches on the cassandra-builds,
> cassandra-website and cassandra-dtest repositories to trunk.
>
> This was discussed in
> https:/
An update on Orange's point of view following the recent emails:
If we were a newly interested party in running C* in K8s, we would use
Cass-operator as it comes from Datastax.
The logic would then be that the community embraces it and thanks Datastax for
offering it!
So, on Orange side, we pr
+1 to in-jvm-dtest-api as well.
> On Oct 2, 2020, at 6:48 AM, Dinesh Joshi wrote:
>
> +1 generally. We should do this for the sidecar repo as well.
>
> Dinesh
>
>> On Oct 2, 2020, at 2:17 AM, Mick Semb Wever wrote:
>>
>> Next week I plan to rename master branches on the cassandra-builds,
>
Hello Franck,
This sounds like a great plan. We would love to expand the group of
contributors and work towards getting the combined efforts pulled into the
Apache Cassandra project proper. The list of items listed here are all wins
in our book (and we've even said how much we enjoyed the CassKop
As discussed on the contributor call, we collectively agreed to try
something new to determine scope for 4.0. Rather than going ticket by
ticket or "asking for forgiveness" and having people move things out
individually, we've flagged all tickets in the 4.0 scope that are still
open with the fixver
how to best merge Casskop's features in Cass-operator.
What if we create issues on the gh repo here
https://github.com/datastax/cass-operator/issues, create a milestone out of
that, and have engineers rally on it to get things merged? We have a few
engineers focused on k8s ecosystem for Cassandra