CEP seems reasonable enough. I'll talk to Alex and Olivier.
On Thu, Jun 25, 2020 at 4:51 PM Mick Semb Wever wrote:
> > > What are next steps here? Anyone knowledgeable on thread?
>
>
> Can we take it to a CEP now?
>
> Even if the decision is to take one driver as a guinea pig and learn as we
> g
> > What are next steps here? Anyone knowledgeable on thread?
Can we take it to a CEP now?
Even if the decision is to take one driver as a guinea pig and learn as we
go, there's some questions that need to be thrashed out in advance
(somewhere better than this thread), e.g. the incubator ip clea
I don't see any reason not to bring in other drivers to the project. We can
start with the Java driver. I think Nate might be aware of the specifics of the
process.
Dinesh
> On Jun 25, 2020, at 11:36 AM, Joshua McKenzie wrote:
>
> My understanding is that there's comparable traffic on python,
My understanding is that there's comparable traffic on python, java, and
node drivers in terms of usage out in the Cassandra ecosystem. Shall we get
started w/the java process and incubation on the donation (CLA's, vetting
contributions, etc) with plans to follow up with python and then node?
What
>
>
> Lastly, and to Stephen's previous email, it might be more manageable to
> accept one drivers first and figure all the details/issues/questions that
> are bound to arise before accepting more. It's worth discussing at least.
>
This approach makes complete sense to me: let's sort out how to ac
I agree keeping the source separate is a good idea to start. If we find
some benefit later in merging the two trees, it's easy enough to do so,
it's more of a pain to split things apart.
The build system used plays a big part as well - ant is definitely not
doing us any favors here.
On Tue, Apr
On Tue, Apr 28, 2020 at 5:10 PM Joshua McKenzie
wrote:
> >
> > If we're talking day to day
> > maintenance, so the bulk of the work really, then I feel rather confident
> > saying that you are wrong,
>
> You're confidently responding to something I wasn't trying to say. :) I may
> not have commu
>
> If we're talking day to day
> maintenance, so the bulk of the work really, then I feel rather confident
> saying that you are wrong,
You're confidently responding to something I wasn't trying to say. :) I may
not have communicated clearly. I was attempting to enumerate:
1. New feature dev
I want to clarify that my plea here is just that we acknowledge that once we
adopt drivers (especially if all of them), the "project" becomes quite big.
All sane big projects have a minimum of organization, so let's make sure we
have enough organization to make sure we don't make our future lives
Thanks, Stephen, this is really helpful!
On Tue, Apr 28, 2020 at 6:24 AM Stephen Mallette
wrote:
> >
> > To step out of the weeds a bit - other than the Zookeeper / Curator
> > example, does anyone know of any other apache projects that have either
> > subprojects or complementary sideprojects t
>
> To step out of the weeds a bit - other than the Zookeeper / Curator
> example, does anyone know of any other apache projects that have either
> subprojects or complementary sideprojects they're interdependent upon in
> their ecosystems?
Every Apache project is different, so it's quite possibl
Separate JIRA is enough enough, separate dev list.. maybe. I don't see
much purpose in trying to organize into a hierarchy, what problem are you
actually solving here? It sounds like you don't trust folks who work on
the driver to not commit random code to Cassandra, is that the case? If
that's
+1, this is essentially my position, and I agree with the baseline requirements
for a merged project. I'm not trying to rule anything out, just wondering what
the optimal division is.
I think from the user point of view we can hopefully achieve the same
appearance with or without the same proj
To step out of the weeds a bit - other than the Zookeeper / Curator
example, does anyone know of any other apache projects that have either
subprojects or complementary sideprojects they're interdependent upon in
their ecosystems? I'd like to reach out to some other pmc's for advice and
feedback on
re: ML noise, how hard would it be to filter out JIRA updates w/component
"Drivers"? Or from JIRA queries?
For governance, I see it cutting both ways. If we have two separate
projects and ML's for drivers and C*, how do we keep a coherent view of new
features and roadmap stuff? Do we have CEP's fo
> On Apr 27, 2020, at 2:50 AM, Sylvain Lebresne wrote:
>
> Fwiw, I agree with the concerns raised by Benedict, and think we should
> carefully think about how this is handled. Which isn't not a rejection of
> the donation in any way.
>
> Drivers are not small projects, and the majority of the
Fwiw, I agree with the concerns raised by Benedict, and think we should
carefully think about how this is handled. Which isn't not a rejection of
the donation in any way.
Drivers are not small projects, and the majority of their day to day
maintenance is unrelated to the server (and the reverse is
> > - How will we run CI for these contributions?
> >
> > ASF Jenkins/CircleCI works? Do the drivers have specific needs beyond this?
> >
> That will probably work. I asked partially because the driver CI can have
> a fairly extensive matrix of platforms, runtimes, and server versions. I'm
> not s
Thanks for the early input here.
> - Which major branch of the Java driver should be chosen for development?
> > -- Server currently uses Java driver 3.x but the latest is 4.x
>
> No opinions here. What are the major differences here? Could you please
> elaborate.
>
4.x is our actively developed b
Benedict,
Your concerns are valid and its great to think through issues that might occur
in the future. I personally have never thought that the driver should be
treated as a separate entity because as a user, Cassandra cannot be used
_without_ a driver. Drivers are the public interface and ar
Do you have some examples of issues?
So, to explain my thinking: I believe there is value in most contributors being
able to know and understand a majority of what the project undertakes. Many
people track a wide variety of activity on the project, and whether they
express an opinion they pr
It would probably be a good idea to get some outside guidance on what other
projects have seen because like what Nate said, this isn't the first time.
https://felix.apache.org/documentation/subprojects.html
https://cocoon.apache.org/subprojects/
Commons has components: http://commons.apache.org/co
On Thu, Apr 23, 2020 at 5:37 AM Benedict Elliott Smith
wrote:
> I welcome the donation, and hope we are able to accept all of the
> drivers. This is really great news IMO.
>
> I do however wonder if the project may be accumulating too many
> sub-projects? I wonder if it's time to think about s
I welcome the donation, and hope we are able to accept all of the drivers.
This is really great news IMO.
I do however wonder if the project may be accumulating too many sub-projects?
I wonder if it's time to think about splitting, and perhaps incubating a
project for the drivers?
On 22/0
Hi Adam,
Great to hear from you! I personally welcome the driver donation. My views are
inline below.
Thanks,
Dinesh
> On Apr 22, 2020, at 10:00 AM, Adam Holmberg
> wrote:
> - Which drivers should be taken into project stewardship?
> -- The project currently bundles Java and Python; there a
The developers who maintain the DataStax drivers would like to start a
conversation about donating these drivers to the Apache Cassandra project.
Since we're actively working on the C* 4.0 support and integration in the
drivers right now, we don't plan on executing on this until after C* 4.0
releas
26 matches
Mail list logo
