cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Haddad <...@jonhaddad.com>
Subject Re: Integrating vendor-specific code and developing plugins
Date Mon, 15 May 2017 11:54:25 GMT
There's a handful of issues I can think of with shipping everything
in-tree.  I'll try to brain dump them here.

* What's included when shipped in tree?

Does every idea get merged in? Do we need 30 different Seed providers?  Who
judges what's valuable enough to add?  Who maintains it when it needs
updating?  If the maintainer can't be found, is it removed?  Shipped
broken?  Does the contributed plugins go through the same review process?
Do the contributors need to be committers?  Would CASSANDRA-12627 be merged
in even if nobody saw the value?

* Language support

Cassandra is based on Java 8.  Do we now merge in Scala, Kotlin, Jython?

* Plugins are now tied directly to cassandra release cycle

This one bugs me quite a bit.  With a new plugin, there's going to be a lot
of rapid iterations.  Spark releases once every 3 months - a lot of the
packages seem to be released at a much higher frequency.

* In Python, the standard lib is where modules go to die

I forgot where I heard this, but it's pretty accurate.  Including
everything, "batteries includes", just ends up shipping some pretty
terrible batteries.  The best stuff for python is on pypi.

Rust deliberately made the decision to limit the std to avoid this
problem.  There's a "nursery" [1] area for ideas to evolve independently,
and when some code reaches a high enough level of maturity, it can get
merged in.  There's also a packages system for third party, non std
destined code.

Anyways - I'm very +1 on a package system where codebases can independently
evolve without needing to be part of the project itself.  It's a proven
model for shipping high quality, useful code, and sometimes is even one of
the best aspects of a project.  That said, it's quite a bit of work just to
get going and someone would have to manage that.

Jon

[1] https://github.com/rust-lang-nursery


On Sun, May 14, 2017 at 9:03 PM Jeff Jirsa <jjirsa@gmail.com> wrote:

> On Fri, May 12, 2017 at 9:31 PM, J. D. Jordan <jeremiah.jordan@gmail.com>
> wrote:
>
> > In tree would foster more committers which is a good thing.
>
>
> Definitely.
>
> But I also agree that not being able to actually run unit tests is a bad
> > thing. What if we asked people who want to contribute these types of
> > optimizations to provide the ASF with a Jenkins slave we could test them
> > on, if they want them in tree?
> >
>
> I think SOME FORM of jenkins/unit/dtests need to exist, whether it's ASF
> puppet controlled or test output explicitly provided by the maintainer.
>
>
> > Otherwise one good thing about out of tree is that the maintainer can
> > specify "this plugin has been tested and works with Apache Cassandra
> > version X.Y.Z". If it is in tree it is assumed it will work. If it is out
> > of tree then the plugin can more easily notify a user what version it was
> > last tested with.  And users won't be surprised if they upgrade and
> things
> > break.
> >
>
> My main desire is that I'd like to see us do better at helping third party
> contributors be successful in contributing, and to me that means something
> more official. I like the spark packages model. I like the apache httpd
> model (with LOTS of official extensions in-tree, but a lot externally
> packaged as well). I'm not a fan of telling people to build and distribute
> their own JARs - it doesn't help the contributors, it doesn't help the
> users, and it doesn't help the project.
>
> - Jeff
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message