Re: Integrating vendor-specific code and developing plugins

Thanks a lot, Jeremiah, Stefan, That is exactly what I was looking for. Rei Odaira 2017-06-03 3:36 GMT-05:00 Stefan Podkowinski : > I'd suggest to use the git docs for the new pages, so we can accept pull > requests for adding other plugins. [1] > > We can also link there from

Re: Integrating vendor-specific code and developing plugins

I'd suggest to use the git docs for the new pages, so we can accept pull requests for adding other plugins. [1] We can also link there from the main pages. Maybe the community page would be a good place for that. [1] https://cassandra.apache.org/doc/latest/development/documentation.html On

Re: Integrating vendor-specific code and developing plugins

The site is in svn for the main pages. https://svn.apache.org/repos/asf/cassandra/site/src/ And in git for the docs. https://github.com/apache/cassandra/tree/trunk/doc/source For suggested changes make a JIRA with proposed changes. -Jeremiah > On Jun 2, 2017, at 5:36 PM, 大平怜

Re: Integrating vendor-specific code and developing plugins

Hi all, As for our CAPI Flash enablement code, we are now working on the plugin approach. Once it is ready, we would like to propose changes in some Web pages of http://cassandra.apache.org for better plugin support. I don't find any official process to propose such changes, but could anyone

Re: Integrating vendor-specific code and developing plugins

Hi all, Everybody seems to agree with improving the plugin ecosystem (as well as not small amount of effort needed to do that), but about vendor-specific code integration, let me summarize the issues raised so far. 1) How to test it? What if my code breaks the vendor-specific build? 2) How to

Re: Integrating vendor-specific code and developing plugins

On Thu, May 18, 2017 at 10:28 AM, Jeff Jirsa wrote: > > > On Mon, May 15, 2017 at 5:25 PM, Jeremiah D Jordan < > jeremiah.jor...@gmail.com> wrote: > >> >> >> To me testable means that we can run the tests at the very least for >> every release, but ideally they would be run

Re: Integrating vendor-specific code and developing plugins

That’s epic Jeff. Very cool. Sent from my iPhone On May 18, 2017, at 10:28 AM, Jeff Jirsa > wrote: On Mon, May 15, 2017 at 5:25 PM, Jeremiah D Jordan < jeremiah.jor...@gmail.com> wrote: To me testable means that we

Re: Integrating vendor-specific code and developing plugins

On Mon, May 15, 2017 at 5:25 PM, Jeremiah D Jordan < jeremiah.jor...@gmail.com> wrote: > > > To me testable means that we can run the tests at the very least for every > release, but ideally they would be run more often than that. Especially > with the push to not release unless the test board

Re: Integrating vendor-specific code and developing plugins

> On May 15, 2017, at 6:57 PM, 大平怜 wrote: > > Thanks for the discussion, all, > >>> * 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

Re: Integrating vendor-specific code and developing plugins

Thanks for the discussion, all, >> * 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?

Re: Integrating vendor-specific code and developing plugins

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 : > There's a handful of issues I can think

Re: Integrating vendor-specific code and developing plugins

Hi all, I have suggested some modifications in CASSANDRA-13270 to be able to provide elasticsearch as a plugin, and these changes are available in a fork at https://github.com/strapdata/cassandra Of course, i don’t expect to include this in the cassandra

Re: Integrating vendor-specific code and developing plugins

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

Re: Integrating vendor-specific code and developing plugins

On Fri, May 12, 2017 at 9:31 PM, J. D. Jordan 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

Re: Integrating vendor-specific code and developing plugins

> It may be better to figure out how to foster a plugin ecosystem, which is a > bit better than "there's an API go deal with it". This is what Spark is > doing and it seems like a pretty reasonable approach to me: > https://spark-packages.org/ > In thinking about this a bit, we have: Mesos, Beam

Re: Integrating vendor-specific code and developing plugins

In accordance with the idea that the codebase should be better tested, it seems to me like things shouldn't be added that aren't testable. If there's a million unit tests that are insanely comprehensive but for some reason can never be run, they serve exactly the same value as no tests. It may

Re: Integrating vendor-specific code and developing plugins

In tree would foster more committers which is a good thing. 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

Re: Integrating vendor-specific code and developing plugins

> This being said, I don't think we should remove support for Windows or > those snitches. Instead, what I think would be more beneficial, and > certainly more reflecting the Apache Way, is to see if someone in the > community would be willing to maintain those components. Looking at another >

Re: Integrating vendor-specific code and developing plugins

I think the status quo is insufficient - even if it doesn't go in tree, we should do more than just say "the API exists, ship your own jar" What's the real risk of having it in tree? We break it because nobody can test it? How's that any worse than breaking it outside the tree? Finger pointing?

Re: Integrating vendor-specific code and developing plugins

I agree the plugins route is the safest and best. However, we already have platform-specific code in-tree that is semi-unmaintained: the Windows support. To Sylvain's point, I have little to no idea if I'm going to break the Windows builds as I don't have access to a Windows machine, nor are we as

Re: Integrating vendor-specific code and developing plugins

I’m with Sylvain on this for essentially same reasons. If we need to improve our extensibility here, we should do that, and then have niche platform specific code be an external plug-in (and add a link to the plug-in to our docs, to promote it). --  AY On 12 May 2017 at 12:36:33, Sylvain

Re: Integrating vendor-specific code and developing plugins

On Fri, May 12, 2017 at 12:29 AM, Jason Brown wrote: > Hey all, > > I'm on-board with what Rei is saying. I think we should be open to, and > encourage, other platforms/architectures for integration. Of course, it > will come down to specific maintainers/committers to do

Re: Integrating vendor-specific code and developing plugins

Hey all, I'm on-board with what Rei is saying. I think we should be open to, and encourage, other platforms/architectures for integration. Of course, it will come down to specific maintainers/committers to do the testing and verification on non-typical platforms. Hopefully those maintainers will