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 <jji...@gmail.com> wrote: > On Fri, May 12, 2017 at 9:31 PM, J. D. Jordan <jeremiah.jor...@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 >
