On Mon, Jan 23, 2017 at 3:19 AM Justin Mclean <jus...@classsoftware.com> wrote:
> Hi, > > > 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? > > I'm not saying it is. What I'm trying to make sure we're agreeing to is that the problem isn't that there is a JAR to .tar.gz file in the distribution. Its that the original source is missing. > 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? > > I feel like you ignored my notes on what's in those JARs and how they're used, or I wasn't clear enough on them. > 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. > > That's what I'm trying to help draw out as a conclusion. If its that its a build tool and can be identified as such, or a precompiled test library that needs to be there for some reason and the source and provenance are known, great. Maybe that's a good first step. I'm personally in favor of having the gradle wrapper (and maven wrapper) present since it helps build the code. > > 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 :-) > > That's exactly the point I'm trying to make. > Thanks > Justin
