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 <jmcken...@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 <berenguerbl...@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 <jmcken...@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 :) 
>>>>>  
>> 

Reply via email to