Absolutely + Separate repos for separate modules also separate responsibility. IMHO it makes a heterogenuous structure more manageable. Both in a technical and a human or insitutional way.
2017-05-15 13:54 GMT+02:00 Jonathan Haddad <j...@jonhaddad.com>: > 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 > > >
