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 also contribute to other parts of the code base, as well, so I see this as another way to bring more folks into the project.
WRT extensibility, it just requires someone to do the work of making reasonable abstraction points - and documenting them ;). The interesting question comes down to how to host/ship any pluggable dependencies. Much like what we had with jna before they relicensed, we'll probably ship some things in-tree and some things users will have to fetch and deploy themselves; it's a case-by-case basis. Thanks, -Jason On Thu, May 11, 2017 at 2:59 PM, 大平怜 <rei.oda...@gmail.com> wrote: > Hi all, > > In this JIRA ticket https://issues.apache.org/jira/browse/CASSANDRA-13486, > we proposed integrating our code to support a fast flash+FPGA card (called > CAPI Flash) only available in the ppc architecture. Although we will keep > discussing the topics specific to the patch (e.g. documentation, license, > code quality) in the JIRA, we would like to start in this dev list more > general discussion about how to (and how not to) merge > architecture-specific (or vendor-specific) changes. > > I think in the end the problem boils down to how to test the > architecture-specific code. The original contributors of the > architecture-specific code can keep "supporting" the code in a sense that > when a problem arises they can fix it and send a patch, but the committers > cannot test it anyway. Are there any other factors we must consider? > > Also, in this particular case, it is relatively easy to turn the code > change into a plugin because it extended the already-pluggable RowCache. I > feel Cassandra has promoted the plugins not so much as other pluggable > software have done like Eclipse, Apache HTTP server, fluentd, etc. For > example, they have a list of plugins in their Web pages. I think if the > community wants to encourage developers to maintain vendor-specific code as > plugins outside of the main source tree, a deeper commitment to the plugin > ecosystem would be appreciated. > > What do you think? > > > Thanks, > Rei Odaira >
