[prev in list] [next in list] [prev in thread] [next in thread]
List: cassandra-dev
Subject: Re: [DISCUSS] ccm as a subproject
From: "Josh McKenzie" <jmckenzie () apache ! org>
Date: 2024-05-16 14:54:11
Message-ID: 5db52dd9-e5ba-4bcd-89e9-a8c370fdb241 () app ! fastmail ! com
[Download RAW message or body]
> 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 <berenguerblasi@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 <jmckenzie@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 :)
> > >
[Attachment #3 (text/html)]
<!DOCTYPE html><html><head><title></title><style \
type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><blockquote \
type="cite"><div>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.<br></div></blockquote><div>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.<br></div><div><br></div><div>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?<br></div><div><br></div><div>I hadn't thought about other subprojects relying on \
it. That's a very good point.</div><div><br></div><div>On Thu, May 16, 2024, at 4:48 \
AM, Jacek Lewandowski wrote:<br></div><blockquote type="cite" id="qt" style=""><div \
dir="ltr"><div class="qt-gmail_default" style="font-family:verdana, sans-serif;">+1 \
(my personal opinion)<br></div><div class="qt-gmail_default" \
style="font-family:verdana, sans-serif;"><br></div><div class="qt-gmail_default" \
style="font-family:verdana, sans-serif;">How to deal with the DSE-supporting code is \
a separate discussion IMO<br></div><div><div dir="ltr" \
class="qt-gmail_signature"><div dir="ltr"><span class="font" \
style="font-family:verdana, sans-serif;"><br>- - -- --- ----- -------- \
-------------<br>Jacek \
Lewandowski</span></div></div></div><div><br></div></div><div><br></div><div \
class="qt-gmail_quote"><div dir="ltr" class="qt-gmail_attr">czw., 16 maj 2024 o \
10:21 Berenguer Blasi <<a \
href="mailto:berenguerblasi@gmail.com">berenguerblasi@gmail.com</a>> \
napisał(a):<br></div><blockquote class="qt-gmail_quote" \
style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, \
204, 204);padding-left:1ex;"><div><u></u><br></div><div><p>+1 ccm is super \
useful<br></p><div>On 16/5/24 10:09, Mick Semb Wever wrote:<br></div><blockquote \
type="cite"><div dir="ltr"><div dir="ltr"><div class="qt-gmail_default" \
style="font-family:arial, sans-serif;"><br></div></div><div><br></div><div \
class="qt-gmail_quote"><div dir="ltr" class="qt-gmail_attr">On Wed, \
15 May 2024 at
16:24, Josh McKenzie <<a href="mailto:jmckenzie@apache.org" \
target="_blank">jmckenzie@apache.org</a>> wrote:<br></div><blockquote \
class="qt-gmail_quote" \
style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, \
204, 204);padding-left:1ex;"><div><div><div>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.<br></div><div><br></div><div>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.<br></div><div><br></div><div>Anyone have any thoughts for or \
against?<br></div><div><br></div><div><a href="https://github.com/riptano/ccm" \
target="_blank">https://github.com/riptano/ccm</a><br></div></div></div></blockquote><div><br></div><div><br></div><div><br></div><div \
style="font-family:arial, sans-serif;" class="qt-gmail_default">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.<br></div><div style="font-family:arial, \
sans-serif;" class="qt-gmail_default"><br></div><div style="font-family:arial, \
sans-serif;" class="qt-gmail_default">Obtaining the CLAs should be much easier, the \
contributors to ccm are less diverse, being more the people we know \
already.<br></div><div><br></div><div><div style="font-family:arial, sans-serif;" \
class="qt-gmail_default">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.<br></div><div style="font-family:arial, sans-serif;" \
class="qt-gmail_default"><br></div><div style="font-family:arial, sans-serif;" \
class="qt-gmail_default">Great to see general consensus (so far) in receiving it \
:) <br></div></div><div> <br></div></div></div></blockquote></div></blockquote></div></blockquote><div><br></div></body></html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic