incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gino Bustelo <>
Subject Toree's One Release Constraint
Date Thu, 19 May 2016 17:30:13 GMT
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 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 past months, we've worked with the JeroMQ
community to help move along a license change to MPL v2 ( The progress showed huge
promised at the start and we are down to 3 committers out of 31 who have
not responded. The JeroMQ community is moving towards code remediation.

In my opinion, this effort shows great inter-OS community cooperation and
something that should be valued by Apache. Why rewrite and maintain code
that already exist? Why not allow the process to take place? Isn't that
what the incubation period is for? Allow projects to resolve concerns
before they graduate?

So my question is, why one release? This has been our biggest impediment in
putting an official incubation release out. We are ready. We have all the
disclaimer in place alerting the user that Toree contains LGPL code. The
biggest concern is releasing and discovering a defect that we would not be
able to fix due to the "One release constraint".

Again... I just wish to start the discussion and find a resolution that
will allow Toree to properly grow and move forward with its incubation.


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