On Fri, May 12, 2017 at 12:29 AM, Jason Brown <jasedbr...@gmail.com> 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 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. > Without going so far as to say we shouldn't merge any platform/architecture/vendor specific code ever and for no reason, I personally think we should avoid doing so as much as practical and encourage the "plugins" route instead. It's just much cleaner imo on principle and amounts to good software development hygiene. I don't want to not be able to commit some changes because it breaks the build because there is code for X number of super specific platform/architecture I don't have access to/don't know anything about and the maintainers are on vacation or hasn't been reachable in a while. And what if such maintainer do go away? Sure we can have some "process" to remove the code in such cases, but why add that burden on us? Plus we, the Apache Cassandra project, would still be seen as the ones that drop support for said platform/architecture even though we really have no choice if it's something we don't have access to anyway. And sure, I'm painting a bleak picture here, and we would probably have none of those problems in most cases. But if we do start encourage actual merge of such code, you can be sure we'll have some of those problems at some point. Encouraging plugins have imo pretty much all the benefits with none of the risks. In particular, I'm unconvinced that someone will be much more likely to meaningfully contribute to other part of the code if his "plugins" is in-tree versus out of it. *But* I can certainly agree with the part about us not having done a good job to promote plugins and it make sense to me to try to improve on that. > > 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 > > >
