Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)

[John D. Ament]

I think my argument is need vs require.  Basically with this policy, we
would be telling people there are certain tools you may not use.

John

On Tue, Jan 24, 2017 at 5:04 PM Ted Dunning  wrote:

> The single case that I can see for mystery jars in binary form is when a
> test case needs to cover malformed binaries or binaries produced on
> obsolete platforms (does anybody have a Java 1.3 compiler handy).
>
>
> (don't answer that, I wouldn't be surprised if a fair number of people
> still require 1.3 compatibility)
>
>
>
>
> On Tue, Jan 24, 2017 at 1:36 AM, Tom Barber  wrote:
>
> > Yeah, Paul makes a very good point. When you're new to a platform and
> > trying to debug tests, trying to find out whats hidden inside mysterious
> > test jars etc is often tedious at best. Build at test time is ideal.
> >
> > Tom
> >
> > On Tue, Jan 24, 2017 at 9:16 AM, Bertrand Delacretaz <
> > bdelacre...@codeconsult.ch> wrote:
> >
> > > On Tue, Jan 24, 2017 at 6:48 AM, Paul King  wrote:
> > > > ...I actually think what we ended up with does make it clearer
> > > > exactly what is going on
> > >
> > > Definitely - what Groovy did avoids having Mysterious Binaries in
> > > their releases, which we don't want.
> > >
> > > -Bertrand
> > >
> > > -
> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > > For additional commands, e-mail: general-h...@incubator.apache.org
> > >
> > >
> >
> >
> > --
> > Tom Barber
> > CTO Spicule LTD
> > t...@spicule.co.uk
> >
> > http://spicule.co.uk
> >
> > @spiculeim 
> >
> > Schedule a meeting with me 
> >
> > GB: +44(0)5603641316 <+44%2056%200364%201316>
> > US: +18448141689 <(844)%20814-1689>
> >
> > 
> >
>

Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)

[Ted Dunning]

The single case that I can see for mystery jars in binary form is when a
test case needs to cover malformed binaries or binaries produced on
obsolete platforms (does anybody have a Java 1.3 compiler handy).


(don't answer that, I wouldn't be surprised if a fair number of people
still require 1.3 compatibility)




On Tue, Jan 24, 2017 at 1:36 AM, Tom Barber  wrote:

> Yeah, Paul makes a very good point. When you're new to a platform and
> trying to debug tests, trying to find out whats hidden inside mysterious
> test jars etc is often tedious at best. Build at test time is ideal.
>
> Tom
>
> On Tue, Jan 24, 2017 at 9:16 AM, Bertrand Delacretaz <
> bdelacre...@codeconsult.ch> wrote:
>
> > On Tue, Jan 24, 2017 at 6:48 AM, Paul King  wrote:
> > > ...I actually think what we ended up with does make it clearer
> > > exactly what is going on
> >
> > Definitely - what Groovy did avoids having Mysterious Binaries in
> > their releases, which we don't want.
> >
> > -Bertrand
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>
>
> --
> Tom Barber
> CTO Spicule LTD
> t...@spicule.co.uk
>
> http://spicule.co.uk
>
> @spiculeim 
>
> Schedule a meeting with me 
>
> GB: +44(0)5603641316
> US: +18448141689
>
> 
>

Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)

[Tom Barber]

Yeah, Paul makes a very good point. When you're new to a platform and
trying to debug tests, trying to find out whats hidden inside mysterious
test jars etc is often tedious at best. Build at test time is ideal.

Tom

On Tue, Jan 24, 2017 at 9:16 AM, Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> On Tue, Jan 24, 2017 at 6:48 AM, Paul King  wrote:
> > ...I actually think what we ended up with does make it clearer
> > exactly what is going on
>
> Definitely - what Groovy did avoids having Mysterious Binaries in
> their releases, which we don't want.
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>


-- 
Tom Barber
CTO Spicule LTD
t...@spicule.co.uk

http://spicule.co.uk

@spiculeim 

Schedule a meeting with me 

GB: +44(0)5603641316
US: +18448141689

Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)

[Bertrand Delacretaz]

On Tue, Jan 24, 2017 at 6:48 AM, Paul King  wrote:
> ...I actually think what we ended up with does make it clearer
> exactly what is going on

Definitely - what Groovy did avoids having Mysterious Binaries in
their releases, which we don't want.

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)

[Paul King]

Just FYI, Groovy had numerous such "test" jars and wrapper files and
such initially. It turned out to only be a couple of hours work to
remove them and build them on the fly within the build files. While I
certainly see both sides of the argument about whether some
"binary-like" artifacts might be considered as special and okay to
include, I actually think what we ended up with does make it clearer
exactly what is going on.

Cheers, Paul.

On Tue, Jan 24, 2017 at 3:51 AM, John D. Ament  wrote:
> On Mon, Jan 23, 2017 at 8:04 AM Marvin Humphrey 
> wrote:
>
>> On Mon, Jan 23, 2017 at 4:35 AM, John D. Ament 
>> wrote:
>>
>> > 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.
>>
>> No.  Bundling jar files is not OK in general and it is definitely the
>> intent of the policy to exclude them.  (Source: I led the redrafting
>> effort for the official policy.) Among other reasons, they are
>> potential trojan horses, because they cannot be audited by a PMC.
>>
>> We might choose to make exceptions in some edge cases, like when the
>> jar files are used as data for tests. That does not invalidate the
>> policy.
>>
>>
> I'm thinking then we need to explicitly call this out.  Perhaps we need to
> add a section next to
> http://www.apache.org/legal/release-policy.html#what-must-every-release-contain
> that
> says "What must each release archive explicitly not contain" and list out
> what's being called out.  By only saying what it must contain, we don't say
> what is not allowed.
>
> Sorry if my thick headedness is getting frustrating, as it seems like there
> is a big gap between what expectations are and what's actually written
> down.  My goal is simply to get written down what the true expectations are.
>
>
>> > I'm personally in favor of
>> > having the gradle wrapper (and maven wrapper) present since it helps
>> build
>> > the code.
>>
>> The gradle wrapper and similar are also not permitted. Build processes
>> need to bootstrap it.
>>
>>
> I would like to understand why, from a legal standpoint, these are not
> allowed.
>
>
>> This isn't a big deal in practice because most people don't care about
>> the security implications of consuming the convenience binary and just
>> use that.
>>
>> Marvin Humphrey
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0

[Justin Mclean]

Hi,

> - The following test jars have been replaced with code to compile source
> and build jars at runtime

Great!

> With regard to sbt, Apache Spark includes a build
> script for sbt here: https://github.com/apache/spark/blob/master/build/sbt Can
> we grab that script and use it?

Sure.

> - With regard to the copyrights being in the LICENSE file, that should only
> be happening for our binary distribution.

I’m not sure they need to be in the binary either. The only reason a copyright 
needs to be mentioned in NOTICE is if it been relocated from a source file 
header. [1] Only a few thing need to go in NOTICE. [2]

>  Is there a specific place we should put the extra license information

No it's up to you.

> Should people be able to build the binary distribution LICENSE, NOTICE, etc 
> from source?


Generally yes. The binary must be made from what’s in the source release see 
[3].

Thanks,
Justin

1. https://www.apache.org/legal/src-headers.html#headers
2. https://www.apache.org/legal/src-headers.html#notice
3. http://www.apache.org/legal/release-policy.html#compiled-packages
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)

[Alex Harui]

On 1/23/17, 9:51 AM, "John D. Ament"  wrote:
>>
>> The gradle wrapper and similar are also not permitted. Build processes
>> need to bootstrap it.
>>
>>
>I would like to understand why, from a legal standpoint, these are not
>allowed.

I don't think it is a legal issue.  It is an ASF policy that the ASF only
officially releases source materials.

As Marvin has mentioned many times already, you can't easily audit
compiled code to be sure there isn't something wrong with it.

For folks in the incubator, IMO it would be to their advantage to take the
time to eradicate compiled code from the source package before proposing
to release it.  It makes the IPMC reviewers job much more efficient.

My 2 cents,
-Alex


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)

[John D. Ament]

On Mon, Jan 23, 2017 at 8:04 AM Marvin Humphrey 
wrote:

> On Mon, Jan 23, 2017 at 4:35 AM, John D. Ament 
> wrote:
>
> > 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.
>
> No.  Bundling jar files is not OK in general and it is definitely the
> intent of the policy to exclude them.  (Source: I led the redrafting
> effort for the official policy.) Among other reasons, they are
> potential trojan horses, because they cannot be audited by a PMC.
>
> We might choose to make exceptions in some edge cases, like when the
> jar files are used as data for tests. That does not invalidate the
> policy.
>
>
I'm thinking then we need to explicitly call this out.  Perhaps we need to
add a section next to
http://www.apache.org/legal/release-policy.html#what-must-every-release-contain
that
says "What must each release archive explicitly not contain" and list out
what's being called out.  By only saying what it must contain, we don't say
what is not allowed.

Sorry if my thick headedness is getting frustrating, as it seems like there
is a big gap between what expectations are and what's actually written
down.  My goal is simply to get written down what the true expectations are.


> > I'm personally in favor of
> > having the gradle wrapper (and maven wrapper) present since it helps
> build
> > the code.
>
> The gradle wrapper and similar are also not permitted. Build processes
> need to bootstrap it.
>
>
I would like to understand why, from a legal standpoint, these are not
allowed.


> This isn't a big deal in practice because most people don't care about
> the security implications of consuming the convenience binary and just
> use that.
>
> Marvin Humphrey
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0

[Chip Senkbeil]

Hi everyone,

Based on feedback we've received regarding issues with this release
candidate, we are preparing a new candidate to address those issues.

- The following test jars have been replaced with code to compile source
and build jars at runtime to provide the same test functionality:
- ScalaTestJar.jar
- TestJar.jar
- TestJar2.jar
- The sparkr_bundle.tar.gz archive has been removed. We were maintaining a
fork of SparkR that added functionality we needed to support a SparkR
interpreter. We have remedied this to use private SparkR APIs directly.
- Likewise, the sparktestjar_2.10-1.0.jar file has been removed since we no
longer need to maintain a fork of SparkR.

Our build system required sbt to build our source code and we currently
have some logic that depends on you being inside a git project. We didn't
consider that the source release was not a git project. We'll have to look
into rectifying that. With regard to sbt, Apache Spark includes a build
script for sbt here: https://github.com/apache/spark/blob/master/build/sbt Can
we grab that script and use it? That would work to fix the problem of not
having sbt installed.

Justin, with regard to your comments about the LICENSE and NOTICE files:
- The copyright date is wrong in the NOTICE file as you said. My fault for
not changing it after the new year. I'll address that.
- With regard to the copyrights being in the LICENSE file, that should only
be happening for our binary distribution. It's a bug in our build that is
also including the copyrights in the source distribution. I'll remedy the
source version to not include the copyrights in the LICENSE file. We do
still need those in the binary distribution, correct? We've been told a
variety of items to include and not include, so I want to make sure we get
them right.
- With the removal of the SparkR fork from our code, there should be no 3rd
party source code in our release for the next candidate; so, no worries
about ASF headers there.
- I never noticed the \n literal character appearing in our generated
LICENSE and NOTICE files. I'll address that as well.

As for the failure to build with make: *** No rule to make target
`etc/legal/LICENSE_extras, we are planning to get rid of that target from
our Makefile as we are not generating that file. Is there a specific place
we should put the extra license information (etc/legal/LICENSE_extras is
where it lives now in our repo)? We were not including the file in our
source distribution because it was being concatenated with the LICENSE
directly as part of packaging the source distribution (which should only be
done for binary distributions?). Should people be able to build the binary
distribution LICENSE, NOTICE, etc from source?

Signed,
Chip Senkbeil

On Fri, Jan 13, 2017 at 4:43 PM Chip Senkbeil 
wrote:

> Please vote on releasing the following candidate as Apache Toree
> (incubating) version 0.1.0.
>
> A vote on this release has passed within the Toree PPMC.
>
> PPMC vote result thread:
>
> https://lists.apache.org/thread.html/5589e9b729333b0d95ccea639fcacf03fdc3d9480aaeb8e80399ad35@
> 
>
> PPMC vote thread:
>
> https://lists.apache.org/thread.html/493874de453d9ccbdbc3aecc2f527dea6af82d657104732d726e07f9@
> 
>
> The tag to be voted on is v0.1.0-rc4
> (1d526954ecaba1d5dc0f40ec555dd598b2b11df7), located here:
>
> https://github.com/apache/incubator-toree/commit/1d526954ecaba1d5dc0f40ec555dd598b2b11df7
>
> All distribution packages, including signatures, digests, etc. can be
> found at:
> https://dist.apache.org/repos/dist/dev/incubator/toree/0.1.0/rc4/
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/chipsenkbeil.asc
>
> The list of keys associated with Toree is available at:
> https://people.apache.org/keys/group/toree.asc
>
> Staging artifacts can be found at:
> https://repository.apache.org/content/repositories/orgapachetoree-1002/
>
> Please vote on releasing this package as Apache Toree 0.1.0-incubating!
>
> The vote is open for 72 hours - until Monday, January 16, at 22:43 UTC -
> and passes if a majority of at least 3 +1 IPMC votes are cast.
>
> [ ] +1 Release this package as Apache Toree 0.1.0-incubating
> [ ] -1 Do not release this package because ...
>
> To learn more about Apache Toree, please see
> http://toree.incubator.apache.org/
>

Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)

[Marvin Humphrey]

On Mon, Jan 23, 2017 at 4:35 AM, John D. Ament  wrote:

> 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.

No.  Bundling jar files is not OK in general and it is definitely the
intent of the policy to exclude them.  (Source: I led the redrafting
effort for the official policy.) Among other reasons, they are
potential trojan horses, because they cannot be audited by a PMC.

We might choose to make exceptions in some edge cases, like when the
jar files are used as data for tests. That does not invalidate the
policy.

> I'm personally in favor of
> having the gradle wrapper (and maven wrapper) present since it helps build
> the code.

The gradle wrapper and similar are also not permitted. Build processes
need to bootstrap it.

This isn't a big deal in practice because most people don't care about
the security implications of consuming the convenience binary and just
use that.

Marvin Humphrey

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)

[John D. Ament]

On Mon, Jan 23, 2017 at 3:19 AM Justin Mclean 
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

Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)

[Justin Mclean]

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?

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 :-)

Thanks
Justin

Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)

[John D. Ament]

On Sun, Jan 22, 2017 at 10:24 PM Marvin Humphrey 
wrote:

> On Sat, Jan 21, 2017 at 9:34 AM, John D. Ament 
> wrote:
> > On Sat, Jan 21, 2017 at 12:19 PM Marvin Humphrey  >
> > wrote:
> >
> >> On Sat, Jan 21, 2017 at 6:41 AM, John D. Ament 
> >> wrote:
> >> > However, regarding the
> >> > binaries.  In a recent discussion (on legal-discuss) it was decided
> that
> >> > this was OK.  Ideally the NOTICE would include the information on the
> >> > binary's source of origin (assuming that the source was eligible to be
> >> > licensed this way).  In this case, the .tar.gz  is actually the
> >> > distribution of Apache Spark R that looks like its required to build
> >> Toree.
> >>
> >> I must have missed this on legal-discuss, and it's counter to my
> >> understanding. Can you please provide a link?
> >>
> >> Here is something I wrote to legal-discuss recently, which talks about
> >> some of the security reasons why bundling a binary dependency is
> >> problematic: https://s.apache.org/OuNX
> >>
> >>
> > Same thread.  Specifically Mark T's response [1] and Craig's affirmation
> [2]
> >
> > [1]:
> >
> https://lists.apache.org/thread.html/995d9ddda07363faff5306154ff3a3aa100a07aad191785d866ae097@%3Clegal-discuss.apache.org%3E
> > [2]:
> >
> https://lists.apache.org/thread.html/5f10a28e5f7bf117599d35e14a00290453c1741d614605950ca897c1@%3Clegal-discuss.apache.org%3E
>
> Let me be clear: compiled code does not belong in our official source
> releases.
>
> Here's the relevant policy clause:
>
>   http://www.apache.org/legal/release-policy#compiled-packages
>
>
My interpretation of the term "compiled code" means compiled versions of
the source code within the package.  When I look at Toree's package I see
three different use cases.

1. Is exactly like what OWB was doing.  They're doing dynamic JAR loading
and want to test that you can load a class in a JAR.  That covers these
files:
./scala-interpreter/src/test/resources/ScalaTestJar.jar
./scala-interpreter/src/test/resources/TestJar.jar
./scala-interpreter/src/test/resources/TestJar2.jar

2. There are external dependencies for executing tests.  There is seemingly
a convenience in packaging an external JAR.  It does look like it
originates from Apache Spark, and was fixed back in July on their side
https://issues.apache.org/jira/browse/SPARK-10683
So it may be that Toree needs to include a similar fix.

sparkr-interpreter/src/main/resources/R/pkg/inst/test_support/sparktestjar_2.10-1.0.jar

3. The R source code provided by Apache Spark's R module, the tar.gz file.

sparkr-interpreter/src/main/resources/sparkr_bundle.tar.gz

For the last 2, I have no clear understanding of how they're used in the
build.  But other than asking that the source files be included in the
distribution somewhere, and that the build structure be updated to
dynamically create these files.

I'll point out that situations like this are exactly why I pushed to remove
most of the incubator specific release policy and instead push for improved
foundation wide policy.  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.




>   The Apache Software Foundation produces open source software. All
> releases
>   are in the form of the source materials needed to make changes to the
>   software being released.
>
> Creating releases which adhere to this policy is almost always
> straightforward.  Just because there are some edge cases where we have to
> apply judgment doesn't invalidate the policy and allow willy-nilly
> bundling of
> binaries.
>
> The OpenWebBeans case from legal-discuss was just such an edge case.  The
> .class file wasn't on the class path and was used only when running unit
> tests
> for some bytecode stuff.  This is quite difficult to exploit.
>
> The debate on legal-discuss was over whether it was worth doing anything
> about, because it was more of a binary resource (like a .jpeg) than
> compiled
> object form.  In the end we didn't even make a policy exception because the
> project applied a workaround -- they extracted the bytecode out of the
> .class
> file and encoded it as a static variable in the source file.
>
>
This wasn't my interpretation of the conversation on legal-discuss.  It may
be that we need to circle back on that thread and get a definitive answer.


> Now, that's not really all that different from a test-time security
> standpoint
> from having the .class file in a test dir outside the classpath or renaming
> `Foo.class` to `Foo.dat` or `Foo.bin`.  It is better though from an
> auditing
> perspective because when changes are made there will be a human-readable
> diff
> in the commit notification email.
>
> And that brings me to the bundling of SparkR in Toree.  The standard
> procedure
> would be for the user to fetch that 

Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)

[Marvin Humphrey]

On Sat, Jan 21, 2017 at 9:34 AM, John D. Ament  wrote:
> On Sat, Jan 21, 2017 at 12:19 PM Marvin Humphrey 
> wrote:
>
>> On Sat, Jan 21, 2017 at 6:41 AM, John D. Ament 
>> wrote:
>> > However, regarding the
>> > binaries.  In a recent discussion (on legal-discuss) it was decided that
>> > this was OK.  Ideally the NOTICE would include the information on the
>> > binary's source of origin (assuming that the source was eligible to be
>> > licensed this way).  In this case, the .tar.gz  is actually the
>> > distribution of Apache Spark R that looks like its required to build
>> Toree.
>>
>> I must have missed this on legal-discuss, and it's counter to my
>> understanding. Can you please provide a link?
>>
>> Here is something I wrote to legal-discuss recently, which talks about
>> some of the security reasons why bundling a binary dependency is
>> problematic: https://s.apache.org/OuNX
>>
>>
> Same thread.  Specifically Mark T's response [1] and Craig's affirmation [2]
>
> [1]:
> https://lists.apache.org/thread.html/995d9ddda07363faff5306154ff3a3aa100a07aad191785d866ae097@%3Clegal-discuss.apache.org%3E
> [2]:
> https://lists.apache.org/thread.html/5f10a28e5f7bf117599d35e14a00290453c1741d614605950ca897c1@%3Clegal-discuss.apache.org%3E

Let me be clear: compiled code does not belong in our official source
releases.

Here's the relevant policy clause:

  http://www.apache.org/legal/release-policy#compiled-packages

  The Apache Software Foundation produces open source software. All releases
  are in the form of the source materials needed to make changes to the
  software being released.

Creating releases which adhere to this policy is almost always
straightforward.  Just because there are some edge cases where we have to
apply judgment doesn't invalidate the policy and allow willy-nilly bundling of
binaries.

The OpenWebBeans case from legal-discuss was just such an edge case.  The
.class file wasn't on the class path and was used only when running unit tests
for some bytecode stuff.  This is quite difficult to exploit.

The debate on legal-discuss was over whether it was worth doing anything
about, because it was more of a binary resource (like a .jpeg) than compiled
object form.  In the end we didn't even make a policy exception because the
project applied a workaround -- they extracted the bytecode out of the .class
file and encoded it as a static variable in the source file.

Now, that's not really all that different from a test-time security standpoint
from having the .class file in a test dir outside the classpath or renaming
`Foo.class` to `Foo.dat` or `Foo.bin`.  It is better though from an auditing
perspective because when changes are made there will be a human-readable diff
in the commit notification email.

And that brings me to the bundling of SparkR in Toree.  The standard procedure
would be for the user to fetch that dependency themselves.  By embedding it,
we actually make it *harder* for security-minded consumers to understand where
their dependencies are coming from.

I don't see a strong rationale for bundling this dependency.  It isn't
compiled code, it's compressed source -- but when it's updated, there's no
diff because the tar.gz is binary.  Why not treat it like any other
dependency?

Marvin Humphrey

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)

[John D. Ament]

On Sun, Jan 22, 2017 at 8:58 PM Marvin Humphrey 
wrote:

> On Sun, Jan 22, 2017 at 5:47 PM, John D. Ament 
> wrote:
>
> > [3]:
> http://www.apache.org/dev/release.html#what-must-every-release-contain
>
> That document has been superseded.  Official Release Policy, curated
> by VP Legal, is here:
>
> http://www.apache.org/legal/release-policy
>
>
Where have you been all my life? I'll reach out to legal as that page has a
couple of bad links.

It seems to me that perhaps a few links on
http://www.apache.org/dev/#releases should be updated to point to legal
docs.


> Marvin Humphrey
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)

[John D. Ament]

Sorry, I'll clarify.

On Sun, Jan 22, 2017 at 9:01 PM Justin Mclean 
wrote:

> Hi,
>
> > If you look in the tar.gz you'll see that it's R source code, and a JAR
> for
> > testing.  Its not compiled code.
>
> Looks like the jars contain compiled code to me:
> ./sparkr-interpreter/src/main/resources/sparkr_bundle.tar.gz - Contains R
> code and a jar that contains class files.
> ./sparkr-interpreter/src/main/resources/R/pkg/inst/test_support/sparktestjar_2.10-1.0.jar
> - Contains class files.
> ./scala-interpreter/src/test/resources/TestJar2.jar - Contains a class
> file (under a com ibm package which seems odd)
> ./scala-interpreter/src/test/resources/ScalaTestJar.jar - as above
> ./scala-interpreter/src/test/resources/TestJar.jar - as above
>
>
None of these are compiled versions of the source code contained in the
project.  Each of the JARs mentioned are "test" JARs, used to build and
test the code.


> Class files are compiled java code right?
>
> How hard would it be to package these / compile these from source code as
> part of the build process?
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)

[Justin Mclean]

Hi,

> If you look in the tar.gz you'll see that it's R source code, and a JAR for
> testing.  Its not compiled code.

Looks like the jars contain compiled code to me:
./sparkr-interpreter/src/main/resources/sparkr_bundle.tar.gz - Contains R code 
and a jar that contains class files.
./sparkr-interpreter/src/main/resources/R/pkg/inst/test_support/sparktestjar_2.10-1.0.jar
 - Contains class files.
./scala-interpreter/src/test/resources/TestJar2.jar - Contains a class file 
(under a com ibm package which seems odd)
./scala-interpreter/src/test/resources/ScalaTestJar.jar - as above
./scala-interpreter/src/test/resources/TestJar.jar - as above

Class files are compiled java code right?

How hard would it be to package these / compile these from source code as part 
of the build process?

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)

[Marvin Humphrey]

On Sun, Jan 22, 2017 at 5:47 PM, John D. Ament  wrote:

> [3]: http://www.apache.org/dev/release.html#what-must-every-release-contain

That document has been superseded.  Official Release Policy, curated
by VP Legal, is here:

http://www.apache.org/legal/release-policy

Marvin Humphrey

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)

[John D. Ament]

On Sun, Jan 22, 2017 at 4:59 PM Justin Mclean 
wrote:

> Hi,
>
> > Same thread.  Specifically Mark T's response [1] and Craig's affirmation
> [2]
>
> Not sure that applies here as I think we have compiled code without the
> corresponding source. Can someone on the project confirm?
>
>
If you look in the tar.gz you'll see that it's R source code, and a JAR for
testing.  Its not compiled code.


> Even then I would expect that to be an unusual exception where there was
> no other way of not including the source code. If it’s compiled it not
> really open source is it?
>
> Documentation (recently changed) [1][2] has been clear that source
> releases should not contain jar files. Both of these pages use to contain a
> release checklist that contained:
> "This package may not contain compiled components (such as "jar" files)
> because compiled components are not open source, even if they were built
> from open source.”
>
> BTW that checklist was quite useful perhaps we should put it back
> somewhere?
>

The reason that these contents were removed (and now I'm glad I did CTR).
The foundation's policy does not mention JARs or any of these provenances.
It doesn't make sense for these policies to apply to podlings when they
don't apply to TLPs.

I'd be fine adding something like a checklist to [3].

John

[3]: http://www.apache.org/dev/release.html#what-must-every-release-contain


>
> Thanks,
> Justin
>
> 1.
> https://web.archive.org/web/20161120035911/http://incubator.apache.org/guides/releasemanagement.html#check-list
> 2.
> https://web.archive.org/web/20160803190705/https://incubator.apache.org/guides/release.html
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)

[Justin Mclean]

Hi,

> Same thread.  Specifically Mark T's response [1] and Craig's affirmation [2]

Not sure that applies here as I think we have compiled code without the 
corresponding source. Can someone on the project confirm?

Even then I would expect that to be an unusual exception where there was no 
other way of not including the source code. If it’s compiled it not really open 
source is it?

Documentation (recently changed) [1][2] has been clear that source releases 
should not contain jar files. Both of these pages use to contain a release 
checklist that contained:
"This package may not contain compiled components (such as "jar" files) because 
compiled components are not open source, even if they were built from open 
source.”

BTW that checklist was quite useful perhaps we should put it back somewhere?

Thanks,
Justin

1.https://web.archive.org/web/20161120035911/http://incubator.apache.org/guides/releasemanagement.html#check-list
2. 
https://web.archive.org/web/20160803190705/https://incubator.apache.org/guides/release.html


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Binary file inclusion (was [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0)

[John D. Ament]

On Sat, Jan 21, 2017 at 12:19 PM Marvin Humphrey 
wrote:

> On Sat, Jan 21, 2017 at 6:41 AM, John D. Ament 
> wrote:
> > However, regarding the
> > binaries.  In a recent discussion (on legal-discuss) it was decided that
> > this was OK.  Ideally the NOTICE would include the information on the
> > binary's source of origin (assuming that the source was eligible to be
> > licensed this way).  In this case, the .tar.gz  is actually the
> > distribution of Apache Spark R that looks like its required to build
> Toree.
>
> I must have missed this on legal-discuss, and it's counter to my
> understanding. Can you please provide a link?
>
> Here is something I wrote to legal-discuss recently, which talks about
> some of the security reasons why bundling a binary dependency is
> problematic: https://s.apache.org/OuNX
>
>
Same thread.  Specifically Mark T's response [1] and Craig's affirmation [2]

[1]:
https://lists.apache.org/thread.html/995d9ddda07363faff5306154ff3a3aa100a07aad191785d866ae097@%3Clegal-discuss.apache.org%3E
[2]:
https://lists.apache.org/thread.html/5f10a28e5f7bf117599d35e14a00290453c1741d614605950ca897c1@%3Clegal-discuss.apache.org%3E

John


> Marvin Humphrey
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0

[Marvin Humphrey]

On Sat, Jan 21, 2017 at 6:41 AM, John D. Ament  wrote:
> However, regarding the
> binaries.  In a recent discussion (on legal-discuss) it was decided that
> this was OK.  Ideally the NOTICE would include the information on the
> binary's source of origin (assuming that the source was eligible to be
> licensed this way).  In this case, the .tar.gz  is actually the
> distribution of Apache Spark R that looks like its required to build Toree.

I must have missed this on legal-discuss, and it's counter to my
understanding. Can you please provide a link?

Here is something I wrote to legal-discuss recently, which talks about
some of the security reasons why bundling a binary dependency is
problematic: https://s.apache.org/OuNX

Marvin Humphrey

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0

[John D. Ament]

Justin,

Agreed on the -1 due to licensing issues.  However, regarding the
binaries.  In a recent discussion (on legal-discuss) it was decided that
this was OK.  Ideally the NOTICE would include the information on the
binary's source of origin (assuming that the source was eligible to be
licensed this way).  In this case, the .tar.gz  is actually the
distribution of Apache Spark R that looks like its required to build Toree.

John

On Fri, Jan 20, 2017 at 5:25 PM Justin Mclean 
wrote:

> Hi,
>
> Sorry but it’s -1 binding due to unexpected binary in source release and
> can’t compile from source. There are some license and notice issue that
> also need to be sorted.
>
> I checked:
> - signatures and hashes exist
> - DISCLAIMER exists
> - LICENSE needs some work  (has a “\n” in plain text in it btw)
> - NOTICE is OK but has incorrect year (also a “\n”)
> - Unexpected binaries in source release (see below)
> - Source files have ASF headers
> - Can’t compile from source
>
> Source release contains several unexpected binary files:
> ./sparkr-interpreter/src/main/resources/sparkr_bundle.tar.gz
>
> ./sparkr-interpreter/src/main/resources/R/pkg/inst/test_support/sparktestjar_2.10-1.0.jar
> ./scala-interpreter/src/test/resources/TestJar2.jar
> ./scala-interpreter/src/test/resources/ScalaTestJar.jar
> ./scala-interpreter/src/test/resources/TestJar.jar
>
> Several of these contain compiled code.
>
> For the license file:
> - Why does it contain a list of copyrights?
> - Why does it include dependancies, only 3rd party code bundled with the
> release should be mentioned in license. [1]
> - In fact I can see no obvious 3rd party code in the release. Is any 3rd
> party code bundled in the release?
> - If there is 3rd party code have the original headers has been replaced
> with an ASF headers?
>
> Following the release instruction I did a make dev and got "make: *** No
> rule to make target `etc/legal/LICENSE_extras', needed by
> `dist/toree-legal/LICENSE'.  Stop.”. Is something missing from the release?
> It may just be that my environment is not set up.
>
> A nice to have the artefacts signed with an apache email rather than a
> gmail address.
>
> Thanks,
> Justin
>
> 1. http://www.apache.org/dev/licensing-howto.html#guiding-principle
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0

[Justin Mclean]

Hi,

Sorry but it’s -1 binding due to unexpected binary in source release and can’t 
compile from source. There are some license and notice issue that also need to 
be sorted.

I checked:
- signatures and hashes exist
- DISCLAIMER exists
- LICENSE needs some work  (has a “\n” in plain text in it btw)
- NOTICE is OK but has incorrect year (also a “\n”)
- Unexpected binaries in source release (see below)
- Source files have ASF headers
- Can’t compile from source

Source release contains several unexpected binary files:
./sparkr-interpreter/src/main/resources/sparkr_bundle.tar.gz
./sparkr-interpreter/src/main/resources/R/pkg/inst/test_support/sparktestjar_2.10-1.0.jar
./scala-interpreter/src/test/resources/TestJar2.jar
./scala-interpreter/src/test/resources/ScalaTestJar.jar
./scala-interpreter/src/test/resources/TestJar.jar

Several of these contain compiled code.

For the license file:
- Why does it contain a list of copyrights?
- Why does it include dependancies, only 3rd party code bundled with the 
release should be mentioned in license. [1]
- In fact I can see no obvious 3rd party code in the release. Is any 3rd party 
code bundled in the release?
- If there is 3rd party code have the original headers has been replaced with 
an ASF headers?

Following the release instruction I did a make dev and got "make: *** No rule 
to make target `etc/legal/LICENSE_extras', needed by 
`dist/toree-legal/LICENSE'.  Stop.”. Is something missing from the release? It 
may just be that my environment is not set up.

A nice to have the artefacts signed with an apache email rather than a gmail 
address.

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html#guiding-principle
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0

[Ian Dunlop]

Hello,

TL/DR +1 (non-binding).

So I had a go at running toree & jupyter from the artifacts and it all
seems ok although there were a couple of things I noticed.

I downloaded toree-pip from
https://dist.apache.org/repos/dist/dev/incubator/toree/0.1.0/rc4/ since
that is what the original vote thread suggests
(https://lists.apache.org/thread.html/493874de453d9ccbdbc3aecc2f527dea6af82d657104732d726e07f9@%3Cdev.toree.apache.org%3E)rather
than attempting to build from source. I did try to build the source from
https://dist.apache.org/repos/dist/dev/incubator/toree/0.1.0/rc4/toree-src/apache-toree-0.1.0-incubating-source-release.tar.gz

but 'make release' resulted in "fatal: Not a git repository (or any
parent up to mount point /home/ian)". I then git cloned the repo from
github and tried again. This resulted in "/bin/sh: 1: sbt: not found
". I have no idea what sbt is and the readme at
https://github.com/apache/incubator-toree didn't help.

It would be worth mentioning the spark install process via
http://spark.apache.org/downloads.html. I just downloaded the suggested
1.6.x version (1.6.3 in fact), unzipped it and placed it in my home
directory and used that as spark_home for the jupyter toree install
part. Would probably be a good idea if the email to general included as
much info as the original vote thread.

I'm also not sure what I'm supposed to do with
https://dist.apache.org/repos/dist/dev/incubator/toree/0.1.0/rc4/toree-pip/apache_toree.egg-info/


I checked the md5 and sha512 sums for all the artifacts and they match.

I'll give it a +1 (non-binding) since it seems to work and the sums are
ok but maybe a bit more is needed in the docs to help people build it
from source.

Cheers,

Ian


On 16/01/17 19:36, Luciano Resende wrote:
> It's ok, let's concentrate on getting the reviews done and 3 required
> binding votes from IPMC members.
>
> On Mon, Jan 16, 2017 at 10:57 AM, Chip Senkbeil 
> wrote:
>
>> Can't tell if my other mail got through. Do I need to open a new thread to
>> indicate that the vote stays open for more than 72 hours? Or is it okay to
>> make that statement here and keep this thread open?
>>
>> On Mon, Jan 16, 2017 at 11:19 AM Ian Dunlop  wrote:
>>
>>> Hello,
>>>
>>> I wonder if it would be better to say
>>>
>>> "The vote is open for *at least* 72 hours " (ie will not be closed until
>>> at least 72 hours have passed)
>>>
>>> rather than
>>>
>>> "The vote is open for 72 hours " (ie will definitely be closed in 72
>> hours
>>> regardless of votes)
>>>
>>> The first version means that you have the option to keep the vote open
>>> after the 72 hours have passed in case you don't have enough votes
>> gathered.
>>> Cheers,
>>>
>>> Ian
>>>
>>>
>>> On 16/01/17 15:34, Luciano Resende wrote:
>>>
>>> Bringing up my +1 from dev list.
>>>
>>> On Fri, Jan 13, 2017 at 2:43 PM, Chip Senkbeil 
>> 
>>> wrote:
>>>
>>>
>>> Please vote on releasing the following candidate as Apache Toree
>>> (incubating) version 0.1.0.
>>>
>>> A vote on this release has passed within the Toree PPMC.
>>>
>>> PPMC vote result thread:https://lists.apache.org/thread.html/
>> 5589e9b729333b0d95ccea639fcacf
>>> 03fdc3d9480aaeb8e80399ad35@
>>> 
>>>
>>> PPMC vote thread:https://lists.apache.org/thread.html/
>> 493874de453d9ccbdbc3aecc2f527d
>>> ea6af82d657104732d726e07f9@
>>> 
>>>
>>> The tag to be voted on is v0.1.0-rc4
>>> (1d526954ecaba1d5dc0f40ec555dd598b2b11df7), located here:
>> https://github.com/apache/incubator-toree/commit/
>>> 1d526954ecaba1d5dc0f40ec555dd598b2b11df7
>>>
>>> All distribution packages, including signatures, digests, etc. can be
>> found
>>> at:https://dist.apache.org/repos/dist/dev/incubator/toree/0.1.0/rc4/
>>>
>>> Release artifacts are signed with the following key:
>> https://people.apache.org/keys/committer/chipsenkbeil.asc
>>> The list of keys associated with Toree is available at:
>> https://people.apache.org/keys/group/toree.asc
>>> Staging artifacts can be found at:https://repository.apache.
>> org/content/repositories/orgapachetoree-1002/
>>> Please vote on releasing this package as Apache Toree 0.1.0-incubating!
>>>
>>> The vote is open for 72 hours - until Monday, January 16, at 22:43 UTC -
>>> and passes if a majority of at least 3 +1 IPMC votes are cast.
>>>
>>> [ ] +1 Release this package as Apache Toree 0.1.0-incubating
>>> [ ] -1 Do not release this package because ...
>>>
>>> To learn more about Apache Toree, please seehttp://toree.incubator.
>> apache.org/
>>>
>>>
>>>
>>>
>
>




signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0

[Luciano Resende]

It's ok, let's concentrate on getting the reviews done and 3 required
binding votes from IPMC members.

On Mon, Jan 16, 2017 at 10:57 AM, Chip Senkbeil 
wrote:

> Can't tell if my other mail got through. Do I need to open a new thread to
> indicate that the vote stays open for more than 72 hours? Or is it okay to
> make that statement here and keep this thread open?
>
> On Mon, Jan 16, 2017 at 11:19 AM Ian Dunlop  wrote:
>
> > Hello,
> >
> > I wonder if it would be better to say
> >
> > "The vote is open for *at least* 72 hours " (ie will not be closed until
> > at least 72 hours have passed)
> >
> > rather than
> >
> > "The vote is open for 72 hours " (ie will definitely be closed in 72
> hours
> > regardless of votes)
> >
> > The first version means that you have the option to keep the vote open
> > after the 72 hours have passed in case you don't have enough votes
> gathered.
> >
> > Cheers,
> >
> > Ian
> >
> >
> > On 16/01/17 15:34, Luciano Resende wrote:
> >
> > Bringing up my +1 from dev list.
> >
> > On Fri, Jan 13, 2017 at 2:43 PM, Chip Senkbeil 
> 
> > wrote:
> >
> >
> > Please vote on releasing the following candidate as Apache Toree
> > (incubating) version 0.1.0.
> >
> > A vote on this release has passed within the Toree PPMC.
> >
> > PPMC vote result thread:https://lists.apache.org/thread.html/
> 5589e9b729333b0d95ccea639fcacf
> > 03fdc3d9480aaeb8e80399ad35@
> > 
> >
> > PPMC vote thread:https://lists.apache.org/thread.html/
> 493874de453d9ccbdbc3aecc2f527d
> > ea6af82d657104732d726e07f9@
> > 
> >
> > The tag to be voted on is v0.1.0-rc4
> > (1d526954ecaba1d5dc0f40ec555dd598b2b11df7), located here:
> https://github.com/apache/incubator-toree/commit/
> > 1d526954ecaba1d5dc0f40ec555dd598b2b11df7
> >
> > All distribution packages, including signatures, digests, etc. can be
> found
> > at:https://dist.apache.org/repos/dist/dev/incubator/toree/0.1.0/rc4/
> >
> > Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/chipsenkbeil.asc
> >
> > The list of keys associated with Toree is available at:
> https://people.apache.org/keys/group/toree.asc
> >
> > Staging artifacts can be found at:https://repository.apache.
> org/content/repositories/orgapachetoree-1002/
> >
> > Please vote on releasing this package as Apache Toree 0.1.0-incubating!
> >
> > The vote is open for 72 hours - until Monday, January 16, at 22:43 UTC -
> > and passes if a majority of at least 3 +1 IPMC votes are cast.
> >
> > [ ] +1 Release this package as Apache Toree 0.1.0-incubating
> > [ ] -1 Do not release this package because ...
> >
> > To learn more about Apache Toree, please seehttp://toree.incubator.
> apache.org/
> >
> >
> >
> >
> >
>



-- 
Luciano Resende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

Re: [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0

[Chip Senkbeil]

Can't tell if my other mail got through. Do I need to open a new thread to
indicate that the vote stays open for more than 72 hours? Or is it okay to
make that statement here and keep this thread open?

On Mon, Jan 16, 2017 at 11:19 AM Ian Dunlop  wrote:

> Hello,
>
> I wonder if it would be better to say
>
> "The vote is open for *at least* 72 hours " (ie will not be closed until
> at least 72 hours have passed)
>
> rather than
>
> "The vote is open for 72 hours " (ie will definitely be closed in 72 hours
> regardless of votes)
>
> The first version means that you have the option to keep the vote open
> after the 72 hours have passed in case you don't have enough votes gathered.
>
> Cheers,
>
> Ian
>
>
> On 16/01/17 15:34, Luciano Resende wrote:
>
> Bringing up my +1 from dev list.
>
> On Fri, Jan 13, 2017 at 2:43 PM, Chip Senkbeil  
> 
> wrote:
>
>
> Please vote on releasing the following candidate as Apache Toree
> (incubating) version 0.1.0.
>
> A vote on this release has passed within the Toree PPMC.
>
> PPMC vote result 
> thread:https://lists.apache.org/thread.html/5589e9b729333b0d95ccea639fcacf
> 03fdc3d9480aaeb8e80399ad35@
> 
>
> PPMC vote 
> thread:https://lists.apache.org/thread.html/493874de453d9ccbdbc3aecc2f527d
> ea6af82d657104732d726e07f9@
> 
>
> The tag to be voted on is v0.1.0-rc4
> (1d526954ecaba1d5dc0f40ec555dd598b2b11df7), located 
> here:https://github.com/apache/incubator-toree/commit/
> 1d526954ecaba1d5dc0f40ec555dd598b2b11df7
>
> All distribution packages, including signatures, digests, etc. can be found
> at:https://dist.apache.org/repos/dist/dev/incubator/toree/0.1.0/rc4/
>
> Release artifacts are signed with the following 
> key:https://people.apache.org/keys/committer/chipsenkbeil.asc
>
> The list of keys associated with Toree is available 
> at:https://people.apache.org/keys/group/toree.asc
>
> Staging artifacts can be found 
> at:https://repository.apache.org/content/repositories/orgapachetoree-1002/
>
> Please vote on releasing this package as Apache Toree 0.1.0-incubating!
>
> The vote is open for 72 hours - until Monday, January 16, at 22:43 UTC -
> and passes if a majority of at least 3 +1 IPMC votes are cast.
>
> [ ] +1 Release this package as Apache Toree 0.1.0-incubating
> [ ] -1 Do not release this package because ...
>
> To learn more about Apache Toree, please seehttp://toree.incubator.apache.org/
>
>
>
>
>

Re: [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0

[Ian Dunlop]

Hello,

I wonder if it would be better to say

"The vote is open for _at least_ 72 hours " (ie will not be closed until
at least 72 hours have passed)

rather than

"The vote is open for 72 hours " (ie will definitely be closed in 72
hours regardless of votes)

The first version means that you have the option to keep the vote open
after the 72 hours have passed in case you don't have enough votes gathered.


Cheers,

Ian

On 16/01/17 15:34, Luciano Resende wrote:
> Bringing up my +1 from dev list.
>
> On Fri, Jan 13, 2017 at 2:43 PM, Chip Senkbeil 
> wrote:
>
>> Please vote on releasing the following candidate as Apache Toree
>> (incubating) version 0.1.0.
>>
>> A vote on this release has passed within the Toree PPMC.
>>
>> PPMC vote result thread:
>> https://lists.apache.org/thread.html/5589e9b729333b0d95ccea639fcacf
>> 03fdc3d9480aaeb8e80399ad35@
>> 
>>
>> PPMC vote thread:
>> https://lists.apache.org/thread.html/493874de453d9ccbdbc3aecc2f527d
>> ea6af82d657104732d726e07f9@
>> 
>>
>> The tag to be voted on is v0.1.0-rc4
>> (1d526954ecaba1d5dc0f40ec555dd598b2b11df7), located here:
>> https://github.com/apache/incubator-toree/commit/
>> 1d526954ecaba1d5dc0f40ec555dd598b2b11df7
>>
>> All distribution packages, including signatures, digests, etc. can be found
>> at:
>> https://dist.apache.org/repos/dist/dev/incubator/toree/0.1.0/rc4/
>>
>> Release artifacts are signed with the following key:
>> https://people.apache.org/keys/committer/chipsenkbeil.asc
>>
>> The list of keys associated with Toree is available at:
>> https://people.apache.org/keys/group/toree.asc
>>
>> Staging artifacts can be found at:
>> https://repository.apache.org/content/repositories/orgapachetoree-1002/
>>
>> Please vote on releasing this package as Apache Toree 0.1.0-incubating!
>>
>> The vote is open for 72 hours - until Monday, January 16, at 22:43 UTC -
>> and passes if a majority of at least 3 +1 IPMC votes are cast.
>>
>> [ ] +1 Release this package as Apache Toree 0.1.0-incubating
>> [ ] -1 Do not release this package because ...
>>
>> To learn more about Apache Toree, please see
>> http://toree.incubator.apache.org/
>>
>
>



signature.asc
Description: OpenPGP digital signature

Re: [VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0

[Luciano Resende]

Bringing up my +1 from dev list.

On Fri, Jan 13, 2017 at 2:43 PM, Chip Senkbeil 
wrote:

> Please vote on releasing the following candidate as Apache Toree
> (incubating) version 0.1.0.
>
> A vote on this release has passed within the Toree PPMC.
>
> PPMC vote result thread:
> https://lists.apache.org/thread.html/5589e9b729333b0d95ccea639fcacf
> 03fdc3d9480aaeb8e80399ad35@
> 
>
> PPMC vote thread:
> https://lists.apache.org/thread.html/493874de453d9ccbdbc3aecc2f527d
> ea6af82d657104732d726e07f9@
> 
>
> The tag to be voted on is v0.1.0-rc4
> (1d526954ecaba1d5dc0f40ec555dd598b2b11df7), located here:
> https://github.com/apache/incubator-toree/commit/
> 1d526954ecaba1d5dc0f40ec555dd598b2b11df7
>
> All distribution packages, including signatures, digests, etc. can be found
> at:
> https://dist.apache.org/repos/dist/dev/incubator/toree/0.1.0/rc4/
>
> Release artifacts are signed with the following key:
> https://people.apache.org/keys/committer/chipsenkbeil.asc
>
> The list of keys associated with Toree is available at:
> https://people.apache.org/keys/group/toree.asc
>
> Staging artifacts can be found at:
> https://repository.apache.org/content/repositories/orgapachetoree-1002/
>
> Please vote on releasing this package as Apache Toree 0.1.0-incubating!
>
> The vote is open for 72 hours - until Monday, January 16, at 22:43 UTC -
> and passes if a majority of at least 3 +1 IPMC votes are cast.
>
> [ ] +1 Release this package as Apache Toree 0.1.0-incubating
> [ ] -1 Do not release this package because ...
>
> To learn more about Apache Toree, please see
> http://toree.incubator.apache.org/
>



-- 
Luciano Resende
http://twitter.com/lresende1975
http://lresende.blogspot.com/

[VOTE] Apache Toree (incubating) 0.1.0-rc4 as 0.1.0

[Chip Senkbeil]

Please vote on releasing the following candidate as Apache Toree
(incubating) version 0.1.0.

A vote on this release has passed within the Toree PPMC.

PPMC vote result thread:
https://lists.apache.org/thread.html/5589e9b729333b0d95ccea639fcacf03fdc3d9480aaeb8e80399ad35@


PPMC vote thread:
https://lists.apache.org/thread.html/493874de453d9ccbdbc3aecc2f527dea6af82d657104732d726e07f9@


The tag to be voted on is v0.1.0-rc4
(1d526954ecaba1d5dc0f40ec555dd598b2b11df7), located here:
https://github.com/apache/incubator-toree/commit/1d526954ecaba1d5dc0f40ec555dd598b2b11df7

All distribution packages, including signatures, digests, etc. can be found
at:
https://dist.apache.org/repos/dist/dev/incubator/toree/0.1.0/rc4/

Release artifacts are signed with the following key:
https://people.apache.org/keys/committer/chipsenkbeil.asc

The list of keys associated with Toree is available at:
https://people.apache.org/keys/group/toree.asc

Staging artifacts can be found at:
https://repository.apache.org/content/repositories/orgapachetoree-1002/

Please vote on releasing this package as Apache Toree 0.1.0-incubating!

The vote is open for 72 hours - until Monday, January 16, at 22:43 UTC -
and passes if a majority of at least 3 +1 IPMC votes are cast.

[ ] +1 Release this package as Apache Toree 0.1.0-incubating
[ ] -1 Do not release this package because ...

To learn more about Apache Toree, please see
http://toree.incubator.apache.org/