incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Mclean <>
Subject Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)
Date Mon, 23 Jan 2017 08:19:07 GMT

> My interpretation of the term "compiled code" means compiled versions of the source code
within the package.

So how is including a jar in a source release to which there is no source code included (or
even a pointer to that code that I can see) actually open source software?

Given this can be easily resolved by including the code and not the jars / changing the build
process why is there a need to include the compile code in the source release?

But lets assume we allow this in a source release. It seems minor (it’s only test code as
you say), but once we do allow jars / compiled code in source releases where do we draw the
line? Is it OK to include gradle wrapper jars for instance? Or 3rd party dependancy jars?
Or our compiled source code as well? All of these situations have resulted in -1 votes on
incubator (and TLP) releases before.

> I suspect that Toree did all of this in their
> release package because Apache Spark was already doing that, and they were
> leveraging spark functionality, and if a TLP is doing it, it must be correct.

Just because it's being done by a TLP doesn’t automatically make it correct :-)

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