+1 for me. I think we can use a wiki for maintaining third party interpreters.
On Thu, May 14, 2015 at 10:23 AM, Alexander Bezzubov <[email protected]> wrote: > Hi, > > Damien, thanks for bringing the discussion in, and thank everybody for > opinions: it is indeed very timely as we see more and more submodules with > interpreters implementations and having a consistent strategy on how to > deal with them is very important now. > > What I see right now is: > - *number of interpreters is potentially unbounded* > that means that bringing all of them to the root repo is neither > feasible nor a maintainable solution: we need then not only to make sure > that patches with such contributions are good but also that ALL maintainers > will stick around long enough to support further evolution of API until at > least a stable release like 1.0 > As zeppelin is 0.x and is far from being stable on API level - this will > bring us to the situation when the project does not compile because of some > interpret is not update really quick. > > - *example of other successful extendable systems* > Other systems like Apache Corduva (while being a Phonegap) or Homebrew > in early days all had a repos with extension code but then moved to just a > 'registry' model, meaning that they just host a registry in 'npm' fashion > and only provide a tools and a workflow to use\contribute those extensions. > I.e Ipython does not host all kernels in main repo rather just list all > them in the project wiki > > - *importance of keeping Zeppelin codebase small and simple for fast > iterations* > Last but not least, this is kind of implication from the first statement > but is very important for longevity of the project. The whole field of > large scale data analytics systems is very dynamic, and it makes perfect > sense, at least to me to, to keep the focus of the project on delivering > the core value rather then covering all potential applications. > > That being said, if this would be the vote I would support a > "registry-like" model, with an external codebases for interpreters AND some > tools on zeppelin side to simplify management like install\update\delete > interpreters i.e from Maven or local\remote filesystem URL. > > Those changes would require further discussion in case we have a consensus > here. > > > On Wed, May 13, 2015 at 9:13 PM, James Carman <[email protected]> > wrote: > > > Consider this a huge -1 from me > > On Wed, May 13, 2015 at 7:39 AM James Carman <[email protected] > > > > wrote: > > > > > Why not invite the contributors to be committers? You don't want to > > leave > > > the contributors out in the cold. Likewise, the interpreters are less > > > likely to attract new contributions outside the ASF. You want to > build a > > > community around the code. Vote them in! > > > > > > On Wed, May 13, 2015 at 4:18 AM Corneau Damien <[email protected]> > > > wrote: > > > > > >> Hi, > > >> > > >> I just want to open a discussion about Zeppelin Interpreters. > > >> > > >> Currently we are accepting interpreters and merging them to the > Zeppelin > > >> Branch when people have some done. > > >> > > >> I see more and more issues/post on the mailing list regarding some > > >> problems > > >> with interpreters, while it is a big part of Zeppelin, I think it will > > >> become quickly hard to maintain. > > >> > > >> It could be a better approach to separate Interpreters from the build > > >> (kinda like plugins/package), that people can include easily depending > > on > > >> their needs, and let the creator take care of issues related to it. > > >> > > >> Any thoughts? > > >> > > > > > > -- 이종열, Jongyoul Lee, 李宗烈 http://madeng.net
