You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cassandra.apache.org by Josh McKenzie <jm...@apache.org> on 2024/05/15 14:23:15 UTC
[DISCUSS] ccm as a subproject
Right now ccm isn't formally a subproject of Cassandra or under governance of the ASF. Given it's an integral components of our CI as well as for local testing for many devs, and we now have more experience w/our muscle on IP clearance and ingesting / absorbing subprojects where we can't track down every single contributor to get an ICLA, seems like it might be worth revisiting the topic of donation of ccm to Apache.
For what it's worth, Sylvain originally and then DataStax after transfer have both been incredible and receptive stewards of the projects and repos, so this isn't about any response to any behavior on their part. Structurally, however, it'd be better for the health of the project(s) long-term to have ccm promoted in. As far as I know there was strong receptivity to that donation in the past but the IP clearance was the primary hurdle.
Anyone have any thoughts for or against?
https://github.com/riptano/ccm
Re: [DISCUSS] ccm as a subproject
Posted by David Capwell <dc...@apple.com>.
Yes please!
> On May 15, 2024, at 2:23 PM, Bret McGuire <br...@gmail.com> wrote:
>
> Very much agreed Paulo; I was musing on the idea of adding Docker support to ccm recently as well. We'd want to preserve the current ability to work with releases (and Github branches) but I very much like the idea of adding Docker support as a new feature.
>
> On Wed, May 15, 2024 at 3:56 PM Paulo Motta <paulo@apache.org <ma...@apache.org>> wrote:
>> As much as I'd like to remove the dependency on ccm I think we'll stick with it for a bit, so +1 on moving under the project umbrella.
>>
>> In the long term it would be nice to modernize integration test suites to use containers instead of processes for more flexibility and fewer dependencies for local development. Perhaps an incremental way to do that would be to add a docker backend to ccm.
>>
>> On Wed, May 15, 2024 at 4:25 PM Bret McGuire <bret.mcguire@gmail.com <ma...@gmail.com>> wrote:
>>> Speaking only for myself I _love_ this idea. The various drivers use ccm extensively in their integration test suites so having this tool in-house and actively looked after would be very beneficial for our work.
>>>
>>> - Bret -
>>>
>>> On Wed, May 15, 2024 at 9:23 AM Josh McKenzie <jmckenzie@apache.org <ma...@apache.org>> wrote:
>>>> Right now ccm isn't formally a subproject of Cassandra or under governance of the ASF. Given it's an integral components of our CI as well as for local testing for many devs, and we now have more experience w/our muscle on IP clearance and ingesting / absorbing subprojects where we can't track down every single contributor to get an ICLA, seems like it might be worth revisiting the topic of donation of ccm to Apache.
>>>>
>>>> For what it's worth, Sylvain originally and then DataStax after transfer have both been incredible and receptive stewards of the projects and repos, so this isn't about any response to any behavior on their part. Structurally, however, it'd be better for the health of the project(s) long-term to have ccm promoted in. As far as I know there was strong receptivity to that donation in the past but the IP clearance was the primary hurdle.
>>>>
>>>> Anyone have any thoughts for or against?
>>>>
>>>> https://github.com/riptano/ccm
>>>>
Re: [DISCUSS] ccm as a subproject
Posted by Bret McGuire <br...@gmail.com>.
Very much agreed Paulo; I was musing on the idea of adding Docker
support to ccm recently as well. We'd want to preserve the current ability
to work with releases (and Github branches) but I very much like the idea
of adding Docker support as a new feature.
On Wed, May 15, 2024 at 3:56 PM Paulo Motta <pa...@apache.org> wrote:
> As much as I'd like to remove the dependency on ccm I think we'll stick
> with it for a bit, so +1 on moving under the project umbrella.
>
> In the long term it would be nice to modernize integration test suites to
> use containers instead of processes for more flexibility and fewer
> dependencies for local development. Perhaps an incremental way to do that
> would be to add a docker backend to ccm.
>
> On Wed, May 15, 2024 at 4:25 PM Bret McGuire <br...@gmail.com>
> wrote:
>
>> Speaking only for myself I _love_ this idea. The various drivers use
>> ccm extensively in their integration test suites so having this tool
>> in-house and actively looked after would be very beneficial for our work.
>>
>> - Bret -
>>
>> On Wed, May 15, 2024 at 9:23 AM Josh McKenzie <jm...@apache.org>
>> wrote:
>>
>>> Right now ccm isn't formally a subproject of Cassandra or under
>>> governance of the ASF. Given it's an integral components of our CI as well
>>> as for local testing for many devs, and we now have more experience w/our
>>> muscle on IP clearance and ingesting / absorbing subprojects where we can't
>>> track down every single contributor to get an ICLA, seems like it might be
>>> worth revisiting the topic of donation of ccm to Apache.
>>>
>>> For what it's worth, Sylvain originally and then DataStax after transfer
>>> have both been incredible and receptive stewards of the projects and repos,
>>> so this isn't about any response to any behavior on their part.
>>> Structurally, however, it'd be better for the health of the project(s)
>>> long-term to have ccm promoted in. As far as I know there was strong
>>> receptivity to that donation in the past but the IP clearance was the
>>> primary hurdle.
>>>
>>> Anyone have any thoughts for or against?
>>>
>>> https://github.com/riptano/ccm
>>>
>>>
Re: [DISCUSS] ccm as a subproject
Posted by Paulo Motta <pa...@apache.org>.
As much as I'd like to remove the dependency on ccm I think we'll stick
with it for a bit, so +1 on moving under the project umbrella.
In the long term it would be nice to modernize integration test suites to
use containers instead of processes for more flexibility and fewer
dependencies for local development. Perhaps an incremental way to do that
would be to add a docker backend to ccm.
On Wed, May 15, 2024 at 4:25 PM Bret McGuire <br...@gmail.com> wrote:
> Speaking only for myself I _love_ this idea. The various drivers use
> ccm extensively in their integration test suites so having this tool
> in-house and actively looked after would be very beneficial for our work.
>
> - Bret -
>
> On Wed, May 15, 2024 at 9:23 AM Josh McKenzie <jm...@apache.org>
> wrote:
>
>> Right now ccm isn't formally a subproject of Cassandra or under
>> governance of the ASF. Given it's an integral components of our CI as well
>> as for local testing for many devs, and we now have more experience w/our
>> muscle on IP clearance and ingesting / absorbing subprojects where we can't
>> track down every single contributor to get an ICLA, seems like it might be
>> worth revisiting the topic of donation of ccm to Apache.
>>
>> For what it's worth, Sylvain originally and then DataStax after transfer
>> have both been incredible and receptive stewards of the projects and repos,
>> so this isn't about any response to any behavior on their part.
>> Structurally, however, it'd be better for the health of the project(s)
>> long-term to have ccm promoted in. As far as I know there was strong
>> receptivity to that donation in the past but the IP clearance was the
>> primary hurdle.
>>
>> Anyone have any thoughts for or against?
>>
>> https://github.com/riptano/ccm
>>
>>
Re: [DISCUSS] ccm as a subproject
Posted by Abe Ratnofsky <ab...@aber.io>.
Strong supporter for bringing ccm into the project as well. ccm is necessary test infrastructure for multiple subprojects, and Cassandra committers should be able to make the changes to ccm that are necessary for their patches.
There's also the security angle: we should work to consolidate our dependencies where appropriate, and reduce the risk of supply chain antics.
> On May 15, 2024, at 4:25 PM, Bret McGuire <br...@gmail.com> wrote:
>
> Speaking only for myself I _love_ this idea. The various drivers use ccm extensively in their integration test suites so having this tool in-house and actively looked after would be very beneficial for our work.
>
> - Bret -
>
> On Wed, May 15, 2024 at 9:23 AM Josh McKenzie <jmckenzie@apache.org <ma...@apache.org>> wrote:
>> Right now ccm isn't formally a subproject of Cassandra or under governance of the ASF. Given it's an integral components of our CI as well as for local testing for many devs, and we now have more experience w/our muscle on IP clearance and ingesting / absorbing subprojects where we can't track down every single contributor to get an ICLA, seems like it might be worth revisiting the topic of donation of ccm to Apache.
>>
>> For what it's worth, Sylvain originally and then DataStax after transfer have both been incredible and receptive stewards of the projects and repos, so this isn't about any response to any behavior on their part. Structurally, however, it'd be better for the health of the project(s) long-term to have ccm promoted in. As far as I know there was strong receptivity to that donation in the past but the IP clearance was the primary hurdle.
>>
>> Anyone have any thoughts for or against?
>>
>> https://github.com/riptano/ccm
>>
Re: [DISCUSS] ccm as a subproject
Posted by Bret McGuire <br...@gmail.com>.
Speaking only for myself I _love_ this idea. The various drivers use
ccm extensively in their integration test suites so having this tool
in-house and actively looked after would be very beneficial for our work.
- Bret -
On Wed, May 15, 2024 at 9:23 AM Josh McKenzie <jm...@apache.org> wrote:
> Right now ccm isn't formally a subproject of Cassandra or under governance
> of the ASF. Given it's an integral components of our CI as well as for
> local testing for many devs, and we now have more experience w/our muscle
> on IP clearance and ingesting / absorbing subprojects where we can't track
> down every single contributor to get an ICLA, seems like it might be worth
> revisiting the topic of donation of ccm to Apache.
>
> For what it's worth, Sylvain originally and then DataStax after transfer
> have both been incredible and receptive stewards of the projects and repos,
> so this isn't about any response to any behavior on their part.
> Structurally, however, it'd be better for the health of the project(s)
> long-term to have ccm promoted in. As far as I know there was strong
> receptivity to that donation in the past but the IP clearance was the
> primary hurdle.
>
> Anyone have any thoughts for or against?
>
> https://github.com/riptano/ccm
>
>
Re: [DISCUSS] ccm as a subproject
Posted by Ariel Weisberg <ar...@weisberg.ws>.
Hi,
Strong +1 as well. It's a pretty critical dependency in the path of testing and committing changes. Supporting integration points for alternative distributions of Cassandra is something I think we should generally be supportive as it's generally an opportunity to make things more modular and testable anyways.
Ariel
On Wed, May 15, 2024, at 10:23 AM, Josh McKenzie wrote:
> Right now ccm isn't formally a subproject of Cassandra or under governance of the ASF. Given it's an integral components of our CI as well as for local testing for many devs, and we now have more experience w/our muscle on IP clearance and ingesting / absorbing subprojects where we can't track down every single contributor to get an ICLA, seems like it might be worth revisiting the topic of donation of ccm to Apache.
>
> For what it's worth, Sylvain originally and then DataStax after transfer have both been incredible and receptive stewards of the projects and repos, so this isn't about any response to any behavior on their part. Structurally, however, it'd be better for the health of the project(s) long-term to have ccm promoted in. As far as I know there was strong receptivity to that donation in the past but the IP clearance was the primary hurdle.
>
> Anyone have any thoughts for or against?
>
> https://github.com/riptano/ccm
>
Re: [DISCUSS] ccm as a subproject
Posted by Josh McKenzie <jm...@apache.org>.
Sounds like we have a general consensus from the project on being willing to accept the donation, should the current rights owners be interested in said donation.
> We've been working on this along with the python-driver (just haven't raised it yet).
Which they indicate they are. :)
I'll follow up on this topic offline w/Mick. Thanks everyone for the good conversation and feedback on it.
~Josh
On Mon, May 20, 2024, at 2:36 PM, Jordan West wrote:
> I would also love to see CCM as an official side project. It is important to the project and I personally use it regularly.
>
> Jordan
>
> On Thu, May 16, 2024 at 7:55 AM Josh McKenzie <jm...@apache.org> wrote:
>> __
>>> We do still have the issues of DSE-supporting code in it, as we do with the drivers. I doubt any of us strongly object to it: there's no trickery happening here on the user; but we should be aware of it and have a rough direction sketched out for when someone else comes along wanting to add support for their proprietary product.
>> IMO as long as it's documented well at the outset and we have plans to slowly refactor to move it to clean boundaries (epic in JIRA anyone <3) so it can be extracted into a separately maintained module by folks that need it, I think we'd be in great shape. That'd also pave a path for others wanting to add support for their proprietary products as well. Win-win.
>>
>> There's always this chicken or egg problem w/things like ccm. Do people not contribute to it because it's out of the umbrella, or is it out of the umbrella because people don't need to contribute to it?
>>
>> I hadn't thought about other subprojects relying on it. That's a very good point.
>>
>> On Thu, May 16, 2024, at 4:48 AM, Jacek Lewandowski wrote:
>>> +1 (my personal opinion)
>>>
>>> How to deal with the DSE-supporting code is a separate discussion IMO
>>>
>>> - - -- --- ----- -------- -------------
>>> Jacek Lewandowski
>>>
>>>
>>> czw., 16 maj 2024 o 10:21 Berenguer Blasi <be...@gmail.com> napisał(a):
>>>> __
>>>> +1 ccm is super useful
>>>>
>>>> On 16/5/24 10:09, Mick Semb Wever wrote:
>>>>>
>>>>>
>>>>> On Wed, 15 May 2024 at 16:24, Josh McKenzie <jm...@apache.org> wrote:
>>>>>> Right now ccm isn't formally a subproject of Cassandra or under governance of the ASF. Given it's an integral components of our CI as well as for local testing for many devs, and we now have more experience w/our muscle on IP clearance and ingesting / absorbing subprojects where we can't track down every single contributor to get an ICLA, seems like it might be worth revisiting the topic of donation of ccm to Apache.
>>>>>>
>>>>>> For what it's worth, Sylvain originally and then DataStax after transfer have both been incredible and receptive stewards of the projects and repos, so this isn't about any response to any behavior on their part. Structurally, however, it'd be better for the health of the project(s) long-term to have ccm promoted in. As far as I know there was strong receptivity to that donation in the past but the IP clearance was the primary hurdle.
>>>>>>
>>>>>> Anyone have any thoughts for or against?
>>>>>>
>>>>>> https://github.com/riptano/ccm
>>>>>
>>>>>
>>>>>
>>>>> We've been working on this along with the python-driver (just haven't raised it yet). It is recognised, like the python-driver, as a key dependency that would best be in the project.
>>>>>
>>>>> Obtaining the CLAs should be much easier, the contributors to ccm are less diverse, being more the people we know already.
>>>>>
>>>>> We do still have the issues of DSE-supporting code in it, as we do with the drivers. I doubt any of us strongly object to it: there's no trickery happening here on the user; but we should be aware of it and have a rough direction sketched out for when someone else comes along wanting to add support for their proprietary product. We also don't want to be pushing downstream users to be having to create their own forks either.
>>>>>
>>>>> Great to see general consensus (so far) in receiving it :)
>>>>>
>>
Re: [DISCUSS] ccm as a subproject
Posted by Jordan West <jo...@gmail.com>.
I would also love to see CCM as an official side project. It is important
to the project and I personally use it regularly.
Jordan
On Thu, May 16, 2024 at 7:55 AM Josh McKenzie <jm...@apache.org> wrote:
> We do still have the issues of DSE-supporting code in it, as we do with
> the drivers. I doubt any of us strongly object to it: there's no trickery
> happening here on the user; but we should be aware of it and have a rough
> direction sketched out for when someone else comes along wanting to add
> support for their proprietary product.
>
> IMO as long as it's documented well at the outset and we have plans to
> slowly refactor to move it to clean boundaries (epic in JIRA anyone <3) so
> it can be extracted into a separately maintained module by folks that need
> it, I think we'd be in great shape. That'd also pave a path for others
> wanting to add support for their proprietary products as well. Win-win.
>
> There's always this chicken or egg problem w/things like ccm. Do people
> not contribute to it because it's out of the umbrella, or is it out of the
> umbrella because people don't need to contribute to it?
>
> I hadn't thought about other subprojects relying on it. That's a very good
> point.
>
> On Thu, May 16, 2024, at 4:48 AM, Jacek Lewandowski wrote:
>
> +1 (my personal opinion)
>
> How to deal with the DSE-supporting code is a separate discussion IMO
>
> - - -- --- ----- -------- -------------
> Jacek Lewandowski
>
>
> czw., 16 maj 2024 o 10:21 Berenguer Blasi <be...@gmail.com>
> napisał(a):
>
>
> +1 ccm is super useful
> On 16/5/24 10:09, Mick Semb Wever wrote:
>
>
>
> On Wed, 15 May 2024 at 16:24, Josh McKenzie <jm...@apache.org> wrote:
>
> Right now ccm isn't formally a subproject of Cassandra or under governance
> of the ASF. Given it's an integral components of our CI as well as for
> local testing for many devs, and we now have more experience w/our muscle
> on IP clearance and ingesting / absorbing subprojects where we can't track
> down every single contributor to get an ICLA, seems like it might be worth
> revisiting the topic of donation of ccm to Apache.
>
> For what it's worth, Sylvain originally and then DataStax after transfer
> have both been incredible and receptive stewards of the projects and repos,
> so this isn't about any response to any behavior on their part.
> Structurally, however, it'd be better for the health of the project(s)
> long-term to have ccm promoted in. As far as I know there was strong
> receptivity to that donation in the past but the IP clearance was the
> primary hurdle.
>
> Anyone have any thoughts for or against?
>
> https://github.com/riptano/ccm
>
>
>
>
> We've been working on this along with the python-driver (just haven't
> raised it yet). It is recognised, like the python-driver, as a key
> dependency that would best be in the project.
>
> Obtaining the CLAs should be much easier, the contributors to ccm are less
> diverse, being more the people we know already.
>
> We do still have the issues of DSE-supporting code in it, as we do with
> the drivers. I doubt any of us strongly object to it: there's no trickery
> happening here on the user; but we should be aware of it and have a rough
> direction sketched out for when someone else comes along wanting to add
> support for their proprietary product. We also don't want to be pushing
> downstream users to be having to create their own forks either.
>
> Great to see general consensus (so far) in receiving it :)
>
>
>
>
Re: [DISCUSS] ccm as a subproject
Posted by Josh McKenzie <jm...@apache.org>.
> We do still have the issues of DSE-supporting code in it, as we do with the drivers. I doubt any of us strongly object to it: there's no trickery happening here on the user; but we should be aware of it and have a rough direction sketched out for when someone else comes along wanting to add support for their proprietary product.
IMO as long as it's documented well at the outset and we have plans to slowly refactor to move it to clean boundaries (epic in JIRA anyone <3) so it can be extracted into a separately maintained module by folks that need it, I think we'd be in great shape. That'd also pave a path for others wanting to add support for their proprietary products as well. Win-win.
There's always this chicken or egg problem w/things like ccm. Do people not contribute to it because it's out of the umbrella, or is it out of the umbrella because people don't need to contribute to it?
I hadn't thought about other subprojects relying on it. That's a very good point.
On Thu, May 16, 2024, at 4:48 AM, Jacek Lewandowski wrote:
> +1 (my personal opinion)
>
> How to deal with the DSE-supporting code is a separate discussion IMO
>
> - - -- --- ----- -------- -------------
> Jacek Lewandowski
>
>
> czw., 16 maj 2024 o 10:21 Berenguer Blasi <be...@gmail.com> napisał(a):
>> __
>> +1 ccm is super useful
>>
>> On 16/5/24 10:09, Mick Semb Wever wrote:
>>>
>>>
>>> On Wed, 15 May 2024 at 16:24, Josh McKenzie <jm...@apache.org> wrote:
>>>> Right now ccm isn't formally a subproject of Cassandra or under governance of the ASF. Given it's an integral components of our CI as well as for local testing for many devs, and we now have more experience w/our muscle on IP clearance and ingesting / absorbing subprojects where we can't track down every single contributor to get an ICLA, seems like it might be worth revisiting the topic of donation of ccm to Apache.
>>>>
>>>> For what it's worth, Sylvain originally and then DataStax after transfer have both been incredible and receptive stewards of the projects and repos, so this isn't about any response to any behavior on their part. Structurally, however, it'd be better for the health of the project(s) long-term to have ccm promoted in. As far as I know there was strong receptivity to that donation in the past but the IP clearance was the primary hurdle.
>>>>
>>>> Anyone have any thoughts for or against?
>>>>
>>>> https://github.com/riptano/ccm
>>>
>>>
>>>
>>> We've been working on this along with the python-driver (just haven't raised it yet). It is recognised, like the python-driver, as a key dependency that would best be in the project.
>>>
>>> Obtaining the CLAs should be much easier, the contributors to ccm are less diverse, being more the people we know already.
>>>
>>> We do still have the issues of DSE-supporting code in it, as we do with the drivers. I doubt any of us strongly object to it: there's no trickery happening here on the user; but we should be aware of it and have a rough direction sketched out for when someone else comes along wanting to add support for their proprietary product. We also don't want to be pushing downstream users to be having to create their own forks either.
>>>
>>> Great to see general consensus (so far) in receiving it :)
>>>
Re: [DISCUSS] ccm as a subproject
Posted by Jacek Lewandowski <le...@gmail.com>.
+1 (my personal opinion)
How to deal with the DSE-supporting code is a separate discussion IMO
- - -- --- ----- -------- -------------
Jacek Lewandowski
czw., 16 maj 2024 o 10:21 Berenguer Blasi <be...@gmail.com>
napisał(a):
> +1 ccm is super useful
> On 16/5/24 10:09, Mick Semb Wever wrote:
>
>
>
> On Wed, 15 May 2024 at 16:24, Josh McKenzie <jm...@apache.org> wrote:
>
>> Right now ccm isn't formally a subproject of Cassandra or under
>> governance of the ASF. Given it's an integral components of our CI as well
>> as for local testing for many devs, and we now have more experience w/our
>> muscle on IP clearance and ingesting / absorbing subprojects where we can't
>> track down every single contributor to get an ICLA, seems like it might be
>> worth revisiting the topic of donation of ccm to Apache.
>>
>> For what it's worth, Sylvain originally and then DataStax after transfer
>> have both been incredible and receptive stewards of the projects and repos,
>> so this isn't about any response to any behavior on their part.
>> Structurally, however, it'd be better for the health of the project(s)
>> long-term to have ccm promoted in. As far as I know there was strong
>> receptivity to that donation in the past but the IP clearance was the
>> primary hurdle.
>>
>> Anyone have any thoughts for or against?
>>
>> https://github.com/riptano/ccm
>>
>
>
>
> We've been working on this along with the python-driver (just haven't
> raised it yet). It is recognised, like the python-driver, as a key
> dependency that would best be in the project.
>
> Obtaining the CLAs should be much easier, the contributors to ccm are less
> diverse, being more the people we know already.
>
> We do still have the issues of DSE-supporting code in it, as we do with
> the drivers. I doubt any of us strongly object to it: there's no trickery
> happening here on the user; but we should be aware of it and have a rough
> direction sketched out for when someone else comes along wanting to add
> support for their proprietary product. We also don't want to be pushing
> downstream users to be having to create their own forks either.
>
> Great to see general consensus (so far) in receiving it :)
>
>
>
>
Re: [DISCUSS] ccm as a subproject
Posted by Berenguer Blasi <be...@gmail.com>.
+1 ccm is super useful
On 16/5/24 10:09, Mick Semb Wever wrote:
>
>
> On Wed, 15 May 2024 at 16:24, Josh McKenzie <jm...@apache.org> wrote:
>
> Right now ccm isn't formally a subproject of Cassandra or under
> governance of the ASF. Given it's an integral components of our CI
> as well as for local testing for many devs, and we now have more
> experience w/our muscle on IP clearance and ingesting / absorbing
> subprojects where we can't track down every single contributor to
> get an ICLA, seems like it might be worth revisiting the topic of
> donation of ccm to Apache.
>
> For what it's worth, Sylvain originally and then DataStax after
> transfer have both been incredible and receptive stewards of the
> projects and repos, so this isn't about any response to any
> behavior on their part. Structurally, however, it'd be better for
> the health of the project(s) long-term to have ccm promoted in. As
> far as I know there was strong receptivity to that donation in the
> past but the IP clearance was the primary hurdle.
>
> Anyone have any thoughts for or against?
>
> https://github.com/riptano/ccm
>
>
>
>
> We've been working on this along with the python-driver (just haven't
> raised it yet). It is recognised, like the python-driver, as a key
> dependency that would best be in the project.
>
> Obtaining the CLAs should be much easier, the contributors to ccm are
> less diverse, being more the people we know already.
>
> We do still have the issues of DSE-supporting code in it, as we do
> with the drivers. I doubt any of us strongly object to it: there's no
> trickery happening here on the user; but we should be aware of it and
> have a rough direction sketched out for when someone else comes along
> wanting to add support for their proprietary product. We also don't
> want to be pushing downstream users to be having to create their own
> forks either.
>
> Great to see general consensus (so far) in receiving it :)
>
Re: [DISCUSS] ccm as a subproject
Posted by Mick Semb Wever <mc...@apache.org>.
On Wed, 15 May 2024 at 16:24, Josh McKenzie <jm...@apache.org> wrote:
> Right now ccm isn't formally a subproject of Cassandra or under governance
> of the ASF. Given it's an integral components of our CI as well as for
> local testing for many devs, and we now have more experience w/our muscle
> on IP clearance and ingesting / absorbing subprojects where we can't track
> down every single contributor to get an ICLA, seems like it might be worth
> revisiting the topic of donation of ccm to Apache.
>
> For what it's worth, Sylvain originally and then DataStax after transfer
> have both been incredible and receptive stewards of the projects and repos,
> so this isn't about any response to any behavior on their part.
> Structurally, however, it'd be better for the health of the project(s)
> long-term to have ccm promoted in. As far as I know there was strong
> receptivity to that donation in the past but the IP clearance was the
> primary hurdle.
>
> Anyone have any thoughts for or against?
>
> https://github.com/riptano/ccm
>
We've been working on this along with the python-driver (just haven't
raised it yet). It is recognised, like the python-driver, as a key
dependency that would best be in the project.
Obtaining the CLAs should be much easier, the contributors to ccm are less
diverse, being more the people we know already.
We do still have the issues of DSE-supporting code in it, as we do with the
drivers. I doubt any of us strongly object to it: there's no trickery
happening here on the user; but we should be aware of it and have a rough
direction sketched out for when someone else comes along wanting to add
support for their proprietary product. We also don't want to be pushing
downstream users to be having to create their own forks either.
Great to see general consensus (so far) in receiving it :)