> 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 :) >>>
