Re: DataStax Driver Donation to Apache Cassandra Project

[Stephen Mallette]

>
> 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 possible that the
experience I have in this area doesn't apply much here, but I'll offer some
words on the matter in the event that some of it is helpful.

For many years even prior to joining Apache, TinkerPop was quite against
bringing in driver-style sub-projects. Our main concern was one that I
think was voiced here in this thread in some fashion, where core developers
would have to be knowledgeable of the incoming body of work and maintain
that going forward. For core contributors who were primarily Java
developers it was difficult to think that we'd suddenly be responsible for
reviews/VOTEs on Python code, for example.  It was with a bit of
trepidation that we eventually decided it a good idea and opened the
project to them. For our purposes we brought all such projects directly
into our core repository as the thinking was that we wanted to keep all
aspects of the project unified (testing, release, etc) to ensure that for a
particular release tag you could be sure that everything worked together.
We initially started with just Python and developed that as our model for
how new drivers would arrive (there were already other disparate projects
out there in other languages).

We wanted a model that ensured a reasonably high bar for acceptance and
created a rough set of minimum criteria we wanted to have for adding a new
driver to our release lines. The core of that criteria was a common
language agnostic test suite that needed to pass for us to consider it
"ready" in any sense and the project needed to build, test and release
using Maven (which is our build tool for the project). The former ensured
that we had a reasonable level of common tested functionality among drivers
and the latter ensured an easy and consistent way to manage build/release
practices (which fed nicely into our Docker infrastructure for both full
builds and for giving non-JVM developers a nice way to develop drivers
against the latest code without having to be Java experts). Once we
established this approach with Python, we successfully brought in .NET and
Javascript.

I think there were a number of nice upsides to deciding to bring in drivers
in the first place and then in the model for acceptance that we chose:

+ We saw a greater diversity of folks contributing in general as the
ecosystem opened up beyond just the JVM.
+ We saw that the general community coalesced around the "official"
drivers, contributing as one to them, rather than going off and creating
one-off projects. I'm not really aware of any third-party drivers right now
for the languages we support, but if you look at something like Go, there
are three or more choices. I suppose Go would be our next target for
official inclusion.
+ Release day was pretty simple despite the complexity of the environment
with that mixed ecosystem because of our unified build model using Maven
and there wasn't a lot of disparate tooling exposed to the release manager
directly.
+ I can't say that we really saw problems with core project developers (who
mostly new Java) having to review python/c#/javascript. For the most part,
the contribution quality was high and we managed and became more
knowledgeable as we went.
+ As we released drivers and core together, we no longer had situations
where some third-party driver lagged behind some feature in core - if you
wanted to use the latest core functionality you just used the latest
release of core and driver and you could be assured they worked together
and we felt confident saying so.

Doing it over again, I think I would still consider going single repo for
this situation but I think I might not place the requirement that the
projects build with Maven. I think Maven has turned-off some contributors
from those language ecosystems who don't know the JVM. They would have been
much more comfortable just working more directly with the tool systems that
they were familiar with. Of course, to get rid of local maven builds
completely we would have to build a "latest" Docker images so that folks
didn't need to do that themselves like they do now (also with Maven).

Aside from TinkerPop experiences I will offer that, while I'm not
completely sure, I think that for a contribution like this one where the
bulk of the code has been developed outside of the ASF, the DS drivers
would need to go through an IP Clearance process:

https://incubator.apache.org/ip-clearance/



On Mon, Apr 27, 2020 at 12:57 PM Joshua McKenzie 
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 they're interdependent upon in
> their ecosystems? I'd lik

Re: Meeting notes and recording from today's meeting

[Stephen Mallette]

As a quick follow up to the DockerHub portion of that discussion, this
morning I checked in with one of the TinkerPop PMC members who also happens
to be on Apache infra and he confirmed that the Distribution Guidelines
draft:

https://cwiki.apache.org/confluence/display/incubator/DistributionGuidelines

remains the most recent thinking on this topic though discussion is ongoing
on the infra mailing list apparently (and perhaps elsewhere...) as to how
to refine this all into something official. That said, given that this
topic is ages old already (ages old generally speaking, and at least a year
old with DockerHub specifically), waiting for something official would
probably take a while.



On Tue, Apr 21, 2020 at 8:46 PM Patrick McFadin  wrote:

> Hi everyone,
>
> Here are the notes and video recording from today's meeting:
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/2020-04-21+Apache+Cassandra+Contributor+Meeting
>
> I updated the meeting details with an ICS to import into your own calendar
> to make it easy to schedule.
>
> https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Contributor+Meeting
>
> Thanks!
>
> Patrick
>

Re: [proposal] Introduce AssertJ in test framework

[Stephen Mallette]

>  (4. potentially migrating other existing tests to AssertJ in the long
term)

Highest value conversions would probably be assertTrue/False() assertions
as I believe those offer the least feedback on failure. I would imagine
that exception assertions would follow that especially when leaning on
@Test(expected = ...) sort of syntax or using explicit try/catch with
fail() logic in tests. AssertJ exception assertions tend to be much more
readable with test intention more clear.

On Wed, Mar 11, 2020 at 10:59 AM Kevin Gallardo 
wrote:

> Hi,
>
> Once you get to know assertJ, it's impossible to go back to basic
> > assertions of JUnit
>
>
> Definitely with you on that :)
>
> Great to see people are excited about this, thanks for the responses. Given
> the positive feedback I have created CASSANDRA-15631
>  as a first step.
>
> My proposal to try to get this going smoothly would be:
>
> 1. introduce the dependency and rewrite an existing test suite to showcase
> it as a reference
> 2. encourage new tests to be written with AssertJ once the dep is added
> 3. add a mention of the preferred assertion library in the contributing
> guidelines and link to the reference for an example
> (4. potentially migrating other existing tests to AssertJ in the long term)
>
> wdyt?
>
>
> On Tue, Mar 10, 2020 at 6:24 PM Joshua McKenzie 
> wrote:
>
> > Strong +1 here. Many of you know I'm a C# / LINQ junkie though. ;)
> >
> > On Tue, Mar 10, 2020 at 3:55 PM DuyHai Doan 
> wrote:
> >
> > > Definitely +1
> > >
> > > Coding in Java every day, I can't write test without assertJ. Once you
> > get
> > > to know assertJ, it's impossible to go back to basic assertions of
> JUnit
> > > that feels really boilerplate
> > >
> > >
> > >
> > > On Tue, Mar 10, 2020 at 8:53 PM Jordan West 
> wrote:
> > >
> > > > If it encourages more  and higher quality test writing +1 (nb). Also,
> > low
> > > > risk given it’s a test dep.
> > > >
> > > > Using QuickTheories as an example, merging it with a new or updated
> > test
> > > > could be a good way to get it merged
> > > >
> > > > Jordan
> > > >
> > > > On Tue, Mar 10, 2020 at 10:33 AM Benjamin Lerer <
> > > > benjamin.le...@datastax.com>
> > > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > On Tue, Mar 10, 2020 at 6:18 PM Jon Haddad 
> > wrote:
> > > > >
> > > > > > I've used assertj in a lot of projects, I prefer it by a wide
> > margin
> > > > over
> > > > > > using only junit.
> > > > > >
> > > > > > On Tue, Mar 10, 2020 at 9:45 AM David Capwell <
> dcapw...@gmail.com>
> > > > > wrote:
> > > > > >
> > > > > > > +1 from me
> > > > > > >
> > > > > > > In CASSANDRA-15564 I build my own assert chain to make the
> tests
> > > > > cleaner;
> > > > > > > did it since assertj wasn't there.
> > > > > > >
> > > > > > > On Tue, Mar 10, 2020, 9:28 AM Kevin Gallardo <
> > > > > > kevin.galla...@datastax.com>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > I would like to propose adding AssertJ <
> > > > > >
> > > > >
> > > >
> > >
> >
> https://urldefense.proofpoint.com/v2/url?u=https-3A__assertj.github.io_doc_&d=DwIFaQ&c=adz96Xi0w1RHqtPMowiL2g&r=Jad7nE1Oab1mebx31r7AOfSsa0by8th6tCxpykmmOBA&m=WrkWi_LeOnAl7rqft1DM27OEkXD7sc2fnZMy_-c7IS8&s=D4FAaGRQi2WlwKAOQbQMfyt_cRqsOuZdePUDgchdLhA&e=
> > > > > > >
> > > > > > > as
> > > > > > > > a test dependency and therefore have it available for writing
> > > > > > > > unit/distributed/any test assertions.
> > > > > > > >
> > > > > > > > In addition to the examples mentioned on the AssertJ docs
> page
> > > > > (allows
> > > > > > to
> > > > > > > > do elaborate and comprehensible assertions on Collections,
> > > String,
> > > > > and
> > > > > > > > *custom
> > > > > > > > assertions*), here's an example of a dtest I was looking at,
> > that
> > > > > could
> > > > > > > be
> > > > > > > > translated to AssertJ syntax, just to give an idea of how the
> > > > syntax
> > > > > > > would
> > > > > > > > apply:
> > > > > > > >
> > > > > > > > *JUnit asserts*:
> > > > > > > > try {
> > > > > > > >[...]
> > > > > > > > } catch (Exception e) {
> > > > > > > > Assert.assertTrue(e instanceof RuntimeException);
> > > > > > > > RuntimeException re = ((RuntimeException) e);
> > > > > > > > Assert.assertTrue(re.getCause() instanceof
> > > > ReadTimeoutException);
> > > > > > > > ReadTimeoutException rte = ((ReadTimeoutException)
> > > > e.getCause());
> > > > > > > > Assert.assertTrue(rte.getMessage().contains("blabla")
> > > > > > > >   &&
> > rte.getMessage().contains("andblablo"));
> > > > > > > > }
> > > > > > > >
> > > > > > > > *AssertJ style:*
> > > > > > > > try {
> > > > > > > > [...]
> > > > > > > > } catch (Exception e) {
> > > > > > > > Assertions.assertThat(e)
> > > > > > > > .isInstanceOf(RuntimeException.class)
> > > > > > > >
> > >  .hasCauseExactlyInstanceOf(ReadTimeoutException.class)
> > > > > > > > .hasMessageContaining("blabla")
> >