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? -- Jeff Jirsa > On May 12, 2017, at 12:25 PM, Jason Brown <jasedbr...@gmail.com> wrote: > > 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 a community (as best as I can tell) actively running unit tests or > dtests on Windows. > > Further, we support snitches for clouds I suspect we don't typically > run/test on, as well: CloudstackSnitch, GoogleCloudSnitch. > > 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 > Apache project, Mesos has an interesting breakdown of maintainers for > specific components [1]. We might consider adopting a similar idea for > platforms/OSes/architectures/whatevers. > > As for where to put the custom code, there's a few different options: > > bare minimum: we should have docs pointing to all known third party > implementations of pluggable interfaces > slightly more involved: contrib/ section of third-party contributed plugins > even more involved: in tree like gcp / aws snitches > > I'm not really thrilled on the contribs repo, and in-tree certainly has > drawbacks, as well. As I initially stated, it can be on a case-by-case > basis. > > Honestly, I don't want to push away contributors if they can add something > to the project - as long as it is maintainable. > > Thanks, > > -Jason > > > [1] https://mesos.apache.org/documentation/latest/committers/ > > On Fri, May 12, 2017 at 4:35 AM, Sylvain Lebresne <sylv...@datastax.com> > wrote: > >> 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 >>>> >>> >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
