Re: Toree's One Release Constraint

As we have to add a DISCLAIMER file with incubation details, I would add a DISCLAIMER-LGPL to make it more visible then embedded in the middle of the README.md. On Fri, May 20, 2016 at 12:56 PM, Gino Bustelo wrote: > @shane > > As part of building, we put together a more

Re: Toree's One Release Constraint

@shane As part of building, we put together a more comprehensive LICENSE and NOTICE file that includes the extra information under https://github.com/apache/incubator-toree/blob/master/etc/legal/LICENSE_extras. The installer of the pip package prints out the LGPL disclaimer during installation.

Re: Toree's One Release Constraint

Gino Bustelo wrote on 5/19/16 12:30 PM: ... > In Toree we have an LGPL dependency that is not a simple rip an replace. > The library is JeroMQ and it is a JVM binding to 0MQ. This is THE protocol > layer used in Jupyter between clients and kernels (Toree serves as a > Jupyter kernel). Over the

Re: Toree's One Release Constraint

Yes this is the other benefit to abstracting an API. You can mock test with the API or provide a drop in replacement if once exists. IE I do not integration tests Java projects using mysql, I use h2 or derby. On Fri, May 20, 2016 at 2:17 PM, Shankar Venkataraman <

Re: Toree's One Release Constraint

In addition, if the LGPL (or a less open licensing) dependency makes it hard to set up and run automated tests on an ongoing basis, it does nullify the spirit of the one release doctrine. To honor the doctrine may lead to painful refactoring, but I do think it is essential for Toree to be truly

Re: Toree's One Release Constraint

On 5/20/16, 9:32 AM, "Edward Capriolo" wrote: >Yes if you are using a feature specific to a specific product it is >obvious >even if you wrap cruft around it. however when I see something that uses >"rabbit mq" i generally think to wrap an interface around it so I can

Re: Toree's One Release Constraint

Yes if you are using a feature specific to a specific product it is obvious even if you wrap cruft around it. however when I see something that uses "rabbit mq" i generally think to wrap an interface around it so I can replace with Apache Kafka :).I am wondering if the same be done here. On Fri,

Re: Toree's One Release Constraint

On 5/20/16, 8:57 AM, "Edward Capriolo" wrote: >" You could argue that it makes the dependency optional" >Yes that is what I am saying. Like in a JDBC application you may be >connecting to postgres or mysql you are not concerned how those are >licensed because you are

Re: Toree's One Release Constraint

" You could argue that it makes the dependency optional" Yes that is what I am saying. Like in a JDBC application you may be connecting to postgres or mysql you are not concerned how those are licensed because you are linked to the shim/driver. You could even bring in the Microsoft SQL server as a

Re: Toree's One Release Constraint

On 5/20/16, 7:23 AM, "Edward Capriolo" wrote: >Would it be acceptable to develop a shim layer toree can link to that and >the provider is dropped in at runtime like the jdbc interface? AIUI, a shim doesn't break the dependency chain. You could argue that it makes the

Re: Toree's One Release Constraint

Would it be acceptable to develop a shim layer toree can link to that and the provider is dropped in at runtime like the jdbc interface? On Thursday, May 19, 2016, Craig Russell wrote: > I found Jim’s message from February 24 in which he says that for one > release,

Re: Toree's One Release Constraint

I found Jim’s message from February 24 in which he says that for one release, he’s ok with having the LGPL dependency. Given that substantial progress has been made and continues to be made on getting the dependency relicensed, I expect that asking for permission for another release in the

Re: Toree's One Release Constraint

"one release constraint" as in we can only have one release with the LGPL dependency. No other release until that dependency is resolved. On Thu, May 19, 2016 at 1:33 PM, Mike Jumper wrote: > On May 19, 2016 10:30 AM, "Gino Bustelo" wrote: > > > > I

Re: Toree's One Release Constraint

On May 19, 2016 10:30 AM, "Gino Bustelo" wrote: > > I write this to start a discussion about the "One release constraint" > placed on Toree and what I feel is an unreasonable constraint on a project > that is undergoing incubation. A brief background first... > > In Toree we

Toree's One Release Constraint

I write this to start a discussion about the "One release constraint" placed on Toree and what I feel is an unreasonable constraint on a project that is undergoing incubation. A brief background first... In Toree we have an LGPL dependency that is not a simple rip an replace. The library is