cassandra-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aleksey Yeschenko <alek...@apache.org>
Subject Re: Integrating vendor-specific code and developing plugins
Date Fri, 12 May 2017 12:31:07 GMT
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 Lebresne (sylvain@datastax.com) wrote:

On Fri, May 12, 2017 at 12:29 AM, Jason Brown <jasedbrown@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.odaira@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  
> >  
>  

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message