Re: [PROPOSAL] Storm for Apache Incubator

[Ted Dunning]

ed Individual
> > Contributor License Agreements for all committers on the project.
> >
> > Yahoo! is also willing to move Storm-on-YARN code from github to be a
> > subproject of Apache Storm project. Storm-on-YARN is currently licensed
> > under Apache License 2.0 and receive contribution under Apache style CLA.
> > Upon entering Apache, Yahoo! will sign over copyright to Apache
> foundation.
> >
> > == External Dependencies ==
> >
> > To the best of our knowledge, all of Storm dependencies (except 0MQ/JMQ)
> > are distributed under Apache compatible licenses. Upon acceptance to the
> > incubator, we would begin a thorough analysis of all transitive
> > dependencies to verify this fact and introduce license checking into the
> > build and release process (for instance integrating Apache Rat).
> >
> > Storm has used 0MQ and JMQ as the default mechanism for internal
> messaging
> > layer, and 0MQ/JMQ is licensed under GNU Lesser General Public License.
> > Recently, we have made Storm messaging layer pluggable, and plan to use
> > Netty (which is licensed under Apache License v2) as our default
> messaging
> > plugin (while keep 0MQ as an optional plugin).
> >
> > == Cryptography ==
> >
> > We do not expect Storm to be a controlled export item due to the use of
> > encryption.
> >
> > Storm enable encryptions via 2 plugins:
> >
> >  * SASL authentication plugins … Currently, we have provide “no-op”
> > authentication and digest authentication. In near future, we will
> introduce
> > Kerberos authentication.
> >  * Tuple payload serialization plugins … Storm provides plugins for
> > plain-object serialization and blowfish encryption.
> >
> > == Required Resources ==
> >
> > === Mailing lists ===
> >
> > * storm-user
> > * storm-dev
> > * storm-private (with moderated subscriptions)
> >
> > === Subversion Directory ===
> >
> > Git is the preferred source control system: git://git.apache.org/storm
> >
> > === Issue Tracking ===
> >
> > JIRA Storm (STORM)
> >
> > == Initial Committers ==
> >
> >  * Nathan Marz 
> >  * James Xu 
> >  * Jason Jackson 
> >  * Andy Feng 
> >  * Flip Kromer  
> >  * David Lao 
> >  * P. Taylor Goetz 
> >
> > == Affiliations ==
> >
> >  * Nathan Marz - Nathan’s Startup
> >  * James Xu - Alibaba
> >  * Jason Jackson - Twitter
> >  * Andy Feng - Yahoo!
> >  * Flip Kromer - Infochimps
> >  * David Lao - Microsoft
> >  * P. Taylor Goetz - Health Market Science
> >
> > == Sponsors ==
> >
> > === Champion ===
> >
> >  * Doug Cutting  
> >
> > === Nominated Mentors ===
> >
> > * Ted Dunning 
> > * Arvind Prabhaker 
> > * Devaraj Das 
> >
> > === Sponsoring Entity ===
> >
> > The Apache Incubator
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [PROPOSAL] Storm for Apache Incubator

[Ted Dunning]

.
> >>>
> >>> === Relationships with Other Apache Products ===
> >>>
> >>> As mentioned in the Alignment section, Storm is closely integrated with
> >>> Hadoop,
> >>> Zookeeper, Thrift, YARN and Mesos in a numerous ways. We look forward
> to
> >>> collaborating with those communities, as well as other Apache
> communities
> >>> (including Apache S4 which focuses on stateful low-latency processing).
> >>>
> >>> === An Excessive Fascination with the Apache Brand ===
> >>>
> >>> Storm is already a healthy and well known open source project. This
> >>> proposal is not for the purpose of generating publicity. Rather, the
> >>> primary benefits to joining Apache are those outlined in the Rationale
> >>> section.
> >>>
> >>> == Documentation ==
> >>>
> >>> The reader will find these websites highly relevant:
> >>>
> >>>  * Storm website: http://storm-project.net
> >>>  * Storm documentation: https://github.com/nathanmarz/storm/wiki
> >>>  * Codebase: https://github.com/nathanmarz/storm
> >>>  * User group: https://groups.google.com/group/storm-user
> >>>
> >>> == Source and Intellectual Property Submission Plan ==
> >>>
> >>> The Storm codebase is currently hosted on Github:
> >>> https://github.com/nathanmarz/storm.
> >>>
> >>> This is the exact codebase that we would migrate to the Apache
> >> foundation.
> >>>
> >>> The Storm source code is currently licensed under Eclipse Public
> License
> >>> Version 1.0. Some source code was contributed under a contributor
> >> agreement
> >>> based on the Sun contributor agreement (v1.5). More recent code has
> been
> >>> contributed under an Apache style agreement (see
> >>>
> https://dl.dropboxusercontent.com/u/133901206/storm-apache-style-cla.txt
> >> ).
> >>>
> >>> Upon entering Apache, Storm will migrate to an Apache License 2.0 with
> >> all
> >>> contributions licensed to the Apache Foundation. In certain cases where
> >>> individuals or organizations hold copyright, we will ensure they grant
> a
> >>> license to the Apache Foundation. Going forward, all commits will be
> >>> licensed directly to the Apache foundation through our signed
> Individual
> >>> Contributor License Agreements for all committers on the project.
> >>>
> >>> Yahoo! is also willing to move Storm-on-YARN code from github to be a
> >>> subproject of Apache Storm project. Storm-on-YARN is currently licensed
> >>> under Apache License 2.0 and receive contribution under Apache style
> CLA.
> >>> Upon entering Apache, Yahoo! will sign over copyright to Apache
> >> foundation.
> >>>
> >>> == External Dependencies ==
> >>>
> >>> To the best of our knowledge, all of Storm dependencies (except
> 0MQ/JMQ)
> >>> are distributed under Apache compatible licenses. Upon acceptance to
> the
> >>> incubator, we would begin a thorough analysis of all transitive
> >>> dependencies to verify this fact and introduce license checking into
> the
> >>> build and release process (for instance integrating Apache Rat).
> >>>
> >>> Storm has used 0MQ and JMQ as the default mechanism for internal
> >> messaging
> >>> layer, and 0MQ/JMQ is licensed under GNU Lesser General Public License.
> >>> Recently, we have made Storm messaging layer pluggable, and plan to use
> >>> Netty (which is licensed under Apache License v2) as our default
> >> messaging
> >>> plugin (while keep 0MQ as an optional plugin).
> >>>
> >>> == Cryptography ==
> >>>
> >>> We do not expect Storm to be a controlled export item due to the use of
> >>> encryption.
> >>>
> >>> Storm enable encryptions via 2 plugins:
> >>>
> >>>  * SASL authentication plugins … Currently, we have provide “no-op”
> >>> authentication and digest authentication. In near future, we will
> >> introduce
> >>> Kerberos authentication.
> >>>  * Tuple payload serialization plugins … Storm provides plugins for
> >>> plain-object serialization and blowfish encryption.
> >>>
> >>> == Required Resources ==
> >>>
> >>> === Mailing lists ===
> >>>
> >>> * storm-user
> >>> * storm-dev
> >>> * storm-private (with moderated subscriptions)
> >>>
> >>> === Subversion Directory ===
> >>>
> >>> Git is the preferred source control system: git://git.apache.org/storm
> >>>
> >>> === Issue Tracking ===
> >>>
> >>> JIRA Storm (STORM)
> >>>
> >>> == Initial Committers ==
> >>>
> >>>  * Nathan Marz 
> >>>  * James Xu 
> >>>  * Jason Jackson 
> >>>  * Andy Feng 
> >>>  * Flip Kromer  
> >>>  * David Lao 
> >>>  * P. Taylor Goetz 
> >>>
> >>> == Affiliations ==
> >>>
> >>>  * Nathan Marz - Nathan’s Startup
> >>>  * James Xu - Alibaba
> >>>  * Jason Jackson - Twitter
> >>>  * Andy Feng - Yahoo!
> >>>  * Flip Kromer - Infochimps
> >>>  * David Lao - Microsoft
> >>>  * P. Taylor Goetz - Health Market Science
> >>>
> >>> == Sponsors ==
> >>>
> >>> === Champion ===
> >>>
> >>>  * Doug Cutting  
> >>>
> >>> === Nominated Mentors ===
> >>>
> >>> * Ted Dunning 
> >>> * Arvind Prabhaker 
> >>> * Devaraj Das 
> >>>
> >>> === Sponsoring Entity ===
> >>>
> >>> The Apache Incubator
> >>
> >>
> >>
> >> --
> >> 
> >> Srinath Perera, Ph.D.
> >>  Director, Research, WSO2 Inc.
> >>  Visiting Faculty, University of Moratuwa
> >>  Member, Apache Software Foundation
> >>  Research Scientist, Lanka Software Foundation
> >>  Blog: http://srinathsview.blogspot.com/
> >>  Photos: http://www.flickr.com/photos/hemapani/
> >>   Phone: 0772360902
> >>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [PROPOSAL] Storm for Apache Incubator

[Ted Dunning]

ebase: https://github.com/nathanmarz/storm
> >> * User group: https://groups.google.com/group/storm-user
> >>
> >> == Source and Intellectual Property Submission Plan ==
> >>
> >> The Storm codebase is currently hosted on Github:
> >> https://github.com/nathanmarz/storm.
> >>
> >> This is the exact codebase that we would migrate to the Apache
> foundation.
> >>
> >> The Storm source code is currently licensed under Eclipse Public License
> >> Version 1.0. Some source code was contributed under a contributor
> agreement
> >> based on the Sun contributor agreement (v1.5). More recent code has been
> >> contributed under an Apache style agreement (see
> >>
> https://dl.dropboxusercontent.com/u/133901206/storm-apache-style-cla.txt).
> >>
> >> Upon entering Apache, Storm will migrate to an Apache License 2.0 with
> all
> >> contributions licensed to the Apache Foundation. In certain cases where
> >> individuals or organizations hold copyright, we will ensure they grant a
> >> license to the Apache Foundation. Going forward, all commits will be
> >> licensed directly to the Apache foundation through our signed Individual
> >> Contributor License Agreements for all committers on the project.
> >>
> >> Yahoo! is also willing to move Storm-on-YARN code from github to be a
> >> subproject of Apache Storm project. Storm-on-YARN is currently licensed
> >> under Apache License 2.0 and receive contribution under Apache style
> CLA.
> >> Upon entering Apache, Yahoo! will sign over copyright to Apache
> foundation.
> >>
> >> == External Dependencies ==
> >>
> >> To the best of our knowledge, all of Storm dependencies (except 0MQ/JMQ)
> >> are distributed under Apache compatible licenses. Upon acceptance to the
> >> incubator, we would begin a thorough analysis of all transitive
> >> dependencies to verify this fact and introduce license checking into the
> >> build and release process (for instance integrating Apache Rat).
> >>
> >> Storm has used 0MQ and JMQ as the default mechanism for internal
> messaging
> >> layer, and 0MQ/JMQ is licensed under GNU Lesser General Public License.
> >> Recently, we have made Storm messaging layer pluggable, and plan to use
> >> Netty (which is licensed under Apache License v2) as our default
> messaging
> >> plugin (while keep 0MQ as an optional plugin).
> >>
> >> == Cryptography ==
> >>
> >> We do not expect Storm to be a controlled export item due to the use of
> >> encryption.
> >>
> >> Storm enable encryptions via 2 plugins:
> >>
> >> * SASL authentication plugins … Currently, we have provide “no-op”
> >> authentication and digest authentication. In near future, we will
> introduce
> >> Kerberos authentication.
> >> * Tuple payload serialization plugins … Storm provides plugins for
> >> plain-object serialization and blowfish encryption.
> >>
> >> == Required Resources ==
> >>
> >> === Mailing lists ===
> >>
> >> * storm-user
> >> * storm-dev
> >> * storm-private (with moderated subscriptions)
> >>
> >> === Subversion Directory ===
> >>
> >> Git is the preferred source control system: git://git.apache.org/storm
> >>
> >> === Issue Tracking ===
> >>
> >> JIRA Storm (STORM)
> >>
> >> == Initial Committers ==
> >>
> >> * Nathan Marz 
> >> * James Xu 
> >> * Jason Jackson 
> >> * Andy Feng 
> >> * Flip Kromer  
> >> * David Lao 
> >> * P. Taylor Goetz 
> >>
> >> == Affiliations ==
> >>
> >> * Nathan Marz - Nathan’s Startup
> >> * James Xu - Alibaba
> >> * Jason Jackson - Twitter
> >> * Andy Feng - Yahoo!
> >> * Flip Kromer - Infochimps
> >> * David Lao - Microsoft
> >> * P. Taylor Goetz - Health Market Science
> >>
> >> == Sponsors ==
> >>
> >> === Champion ===
> >>
> >> * Doug Cutting  
> >>
> >> === Nominated Mentors ===
> >>
> >> * Ted Dunning 
> >> * Arvind Prabhaker 
> >> * Devaraj Das 
> >>
> >> === Sponsoring Entity ===
> >>
> >> The Apache Incubator
> >>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [Drill] - Re: Shepherd assignments, September 2013

[Ted Dunning]

Dave,

I would take some issue with your comments here.

If you look at what is happening right now, the entire Drill team is
focussed on making a release and particularly focussed on getting the IP
issues right.  There have been several release candidates posted and the
community members have been reviewing these and working through the
identified issues very systematically.  This is the first release of this
code under Apache guidelines and most of the developers are new to Apache.
 As such, it is hardly surprising that there is a lack of experience in
getting the form right for IP clearance.  The current process is a good
learning experience and contributors are pitching in whole-heartedly and
almost all issues have been addressed.

As I pointed out when you asked a question on the mailing list, the lack of
incubator disclaimer had already been noted, a JIRA filed and a patch
posted even before you noticed it.  I would like to also point out also
that all of the mentors have been active in reviewing release candidates
and the mentors were the ones who first raised the IP issues.

I would request that you rephrase or retract the comment "does not seem to
include any drive to make any release".  There is absolutely a drive for a
release and it is bearing fruit as we write.

We do appreciate your positive comment on our community building efforts.
 We are working *very* hard on that (along with building kick-ass
technology into kick-ass code packaged up in a kick-ass and fully IP
cleared release).


On Tue, Sep 10, 2013 at 6:56 PM, Dave Fisher  wrote:

> Hi -
>
> I am concerned the podling is missing the DISCLAIMER in its source code
> and on most web pages.
>
> There is a lot of activity but it does not seem to include any drive to
> make any release.
>
> There is tremendous community building activity.
>
> Heavy on community and light on IP clearance.
>
> Regards,
> Dave
>
> On Sep 4, 2013, at 9:47 PM, Marvin Humphrey wrote:
>
> > Greets,
> >
> > Here are shepherd assignments for our September 2013 report:
> >
> >SHEPHERD   PODLING
> >--
> >Alan Cabrera   Falcon
> >Alan Cabrera   MetaModel
> >Alan Cabrera   Tajo
> >Dave FisherDrill
> >Dave FisherS4
> >Matt Franklin  Olingo
> >Matt Franklin  Provisionr
> >Ross Gardler   Wave
> >Matt Hogstrom  Sentry
> >Benson Marguilies  Spark
> >Suresh Marru   Allura
> >Suresh Marru   Samza
> >Roman Shaposhnik   Kalumet
> >Roman Shaposhnik   MRQL
> >Roman Shaposhnik   Streams
> >
> > Please add your reports to the wiki by the end of next Tuesday,
> September 10.
> > I will collect all of them into a single email and send to
> general@incubator
> > after the report is filed.
> >
> > Thanks!
> >
> > 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] Accept Storm into the Incubator

[Ted Dunning]

integrating
> Apache Rat).
> 
> Storm has used 0MQ and JMQ as the default mechanism for internal
> messaging layer, and 0MQ/JMQ is licensed under GNU Lesser General
> Public License. Recently, we have made Storm messaging layer
> pluggable, and plan to use Netty (which is licensed under Apache
> License v2) as our default messaging plugin (while keep 0MQ as an
> optional plugin).
> 
> == Cryptography ==
> 
> We do not expect Storm to be a controlled export item due to the use
> of encryption.
> Storm enable encryptions via 2 plugins:
>   * SASL authentication plugins … Currently, we have provide “no-op”
> authentication and digest authentication. In near future, we will
> introduce Kerberos authentication.
>   * Tuple payload serialization plugins … Storm provides plugins for
> plain-object serialization and blowfish encryption.
> 
> == Required Resources ==
> 
> === Mailing lists ===
> 
> * storm-user
> * storm-dev
> * storm-commits
> * storm-private (with moderated subscriptions)
> 
> === Subversion Directory ===
> 
> Git is the preferred source control system: git://git.apache.org/storm
> 
> 
> === Issue Tracking ===
> 
> JIRA Storm (STORM)
> 
> == Initial Committers ==
> 
>   * Nathan Marz 
>   * James Xu 
>   * Jason Jackson 
>   * Andy Feng 
>   * Flip Kromer  
>   * David Lao 
>   * P. Taylor Goetz 
> 
> == Affiliations ==
> 
>   * Nathan Marz - Nathan’s Startup
>   * James Xu - Alibaba
>   * Jason Jackson - Twitter
>   * Andy Feng - Yahoo!
>   * Flip Kromer - Infochimps
>   * David Lao - Microsoft
>   * P. Taylor Goetz - Health Market Science
> 
> == Sponsors ==
> 
> 
> === Champion ===
> 
>   * Doug Cutting  
> 
> === Nominated Mentors ===
> 
>  * Ted Dunning 
>  * Arvind Prabhakar 
>  * Devaraj Das 
>  * Matt Franklin 
>  * Benjamin Hindman 
> 
> === Sponsoring Entity ===
> 
> The Apache Incubator
> 
> -
> 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: [Drill] - Re: Shepherd assignments, September 2013

[Ted Dunning]

On Thu, Sep 12, 2013 at 1:37 PM, Marvin Humphrey wrote:

> Thanks to Dave for his long record of contributing as a shepherd.
>

Indeed.

And thanks to Dave for checking out Drill.  More eyes on a project is
always a good thing.

Re: [Drill] - Re: Shepherd assignments, September 2013

[Ted Dunning]

On Thu, Sep 12, 2013 at 12:54 PM, Dave Fisher  wrote:

> Sorry for any consternation. Best of luck. I do think that once your
> podling does release that TLP status should come soon.
>

I would say that we have a little more practice needed in incubator.  But
the progress is happening.

One issue that Drill does have is that the committer pool is a bit small so
getting enough binding votes takes a bit of coordination.  There are lots
and lots of contributors who should be moved up a notch, though, so that
problem is easy to fix.

[VOTE] first milestone release of Apache Drill (incubating)

[Ted Dunning]

We've held a vote on drill-dev to release the first milestone release.

The vote thread can be found here:

http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3ccaka9qdkmxjp-r8v+zwabm5e4b5osrypjyp+dupvq2lr-d70...@mail.gmail.com%3E

The vote passed with

4 x +1 binding votes
7 x +1 non-binding votes

An additional non-binding +1 vote was received after the vote closed.

A summary email can be found here:

http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3CCAKa9qDn1+TnKVP=p_=Lh==mOS=azctuz6_qvsm4u3z4gdhh...@mail.gmail.com%3E

The source only release artifactscan be found together with signatures here:

http://people.apache.org/~jacques/apache-drill-1.0.0-m1.rc4/
Please vote on this release

Re: [VOTE] first milestone release of Apache Drill (incubating)

[Ted Dunning]

Lest anybody not understand my implicit vote:

+1 (binding)



On Tue, Sep 17, 2013 at 5:13 PM, Dave Fisher  wrote:

> Wonderful.
>
> On Sep 17, 2013, at 3:29 PM, Ted Dunning wrote:
>
> > We've held a vote on drill-dev to release the first milestone release.
> >
> > The vote thread can be found here:
> >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3ccaka9qdkmxjp-r8v+zwabm5e4b5osrypjyp+dupvq2lr-d70...@mail.gmail.com%3E
> >
> > The vote passed with
> >
> > 4 x +1 binding votes
> > 7 x +1 non-binding votes
> >
> > An additional non-binding +1 vote was received after the vote closed.
> >
> > A summary email can be found here:
> >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3CCAKa9qDn1+TnKVP=p_=Lh==mOS=azctuz6_qvsm4u3z4gdhh...@mail.gmail.com%3E
> >
> > The source only release artifactscan be found together with signatures
> here:
> >
> > http://people.apache.org/~jacques/apache-drill-1.0.0-m1.rc4/
> > Please vote on this release
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] first milestone release of Apache Drill (incubating)

[Ted Dunning]

Benson,

The disclaimer is in the README now:

README.md:Apache Drill is an effort undergoing incubation at The Apache
> Software Foundation (ASF), sponsored by the Apache Incubator. Incubation is
> required of all newly accepted projects until a further review indicates
> that the infrastructure, communications, and decision making process have
> stabilized in a manner consistent with other successful ASF projects. While
> incubation status is not necessarily a reflection of the completeness or
> stability of the code, it does indicate that the project has yet to be
> fully endorsed by the ASF.


Subsequent to the construction of this RC, a DISCLAIMER file has been
created that will appear in the next release.

Given that

* the disclaimer is actually there,

* this is a milestone release which should be supplanted by another release
in a month or two

and

* this will be fixed

Would you reconsider?







On Wed, Sep 18, 2013 at 4:39 AM, Benson Margulies wrote:

> -1 binding. I don't see the standard disclaimer in any of the possible
> locations.
>
> In Maven, the standard disclaimer as a remote resource via
> org.apache:apache-incubator-disclaimer-resource-bundle.
>
> The text looks like:
>
> #if(${projectName})${projectName}#else${project.name}#end is an effort
> undergoing incubation at the Apache Software
> Foundation (ASF), sponsored by the Apache Incubator PMC.
>
> Incubation is required of all newly accepted projects until a further
> review
> indicates that the infrastructure, communications, and decision making
> process
> have stabilized in a manner consistent with other successful ASF projects.
>
> While incubation status is not necessarily a reflection of the completeness
> or stability of the code, it does indicate that the project has yet to be
> fully endorsed by the ASF.
>
>
>
> On Wed, Sep 18, 2013 at 6:24 AM, Grant Ingersoll 
> wrote:
> > +1, binding
> >
> > On Sep 17, 2013, at 6:29 PM, Ted Dunning  wrote:
> >
> >> We've held a vote on drill-dev to release the first milestone release.
> >>
> >> The vote thread can be found here:
> >>
> >>
> http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3ccaka9qdkmxjp-r8v+zwabm5e4b5osrypjyp+dupvq2lr-d70...@mail.gmail.com%3E
> >>
> >> The vote passed with
> >>
> >> 4 x +1 binding votes
> >> 7 x +1 non-binding votes
> >>
> >> An additional non-binding +1 vote was received after the vote closed.
> >>
> >> A summary email can be found here:
> >>
> >>
> http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3CCAKa9qDn1+TnKVP=p_=Lh==mOS=azctuz6_qvsm4u3z4gdhh...@mail.gmail.com%3E
> >>
> >> The source only release artifactscan be found together with signatures
> here:
> >>
> >> http://people.apache.org/~jacques/apache-drill-1.0.0-m1.rc4/
> >> Please vote on this release
> >
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] first milestone release of Apache Drill (incubating)

[Ted Dunning]

Thanks for reviewing at all!  Even more thanks for reviewing when you
should be sleeping.



On Wed, Sep 18, 2013 at 12:40 PM, Benson Margulies wrote:

> On Wed, Sep 18, 2013 at 11:42 AM, Ted Dunning 
> wrote:
> > Benson,
> >
> > The disclaimer is in the README now:
>
> Which is to say, README.md.
>
> OK, I was too tired last night. -1 -> +1.
>
>
> >
> > README.md:Apache Drill is an effort undergoing incubation at The Apache
> >> Software Foundation (ASF), sponsored by the Apache Incubator.
> Incubation is
> >> required of all newly accepted projects until a further review indicates
> >> that the infrastructure, communications, and decision making process
> have
> >> stabilized in a manner consistent with other successful ASF projects.
> While
> >> incubation status is not necessarily a reflection of the completeness or
> >> stability of the code, it does indicate that the project has yet to be
> >> fully endorsed by the ASF.
> >
> >
> > Subsequent to the construction of this RC, a DISCLAIMER file has been
> > created that will appear in the next release.
> >
> > Given that
> >
> > * the disclaimer is actually there,
> >
> > * this is a milestone release which should be supplanted by another
> release
> > in a month or two
> >
> > and
> >
> > * this will be fixed
> >
> > Would you reconsider?
> >
> >
> >
> >
> >
> >
> >
> > On Wed, Sep 18, 2013 at 4:39 AM, Benson Margulies  >wrote:
> >
> >> -1 binding. I don't see the standard disclaimer in any of the possible
> >> locations.
> >>
> >> In Maven, the standard disclaimer as a remote resource via
> >> org.apache:apache-incubator-disclaimer-resource-bundle.
> >>
> >> The text looks like:
> >>
> >> #if(${projectName})${projectName}#else${project.name}#end is an effort
> >> undergoing incubation at the Apache Software
> >> Foundation (ASF), sponsored by the Apache Incubator PMC.
> >>
> >> Incubation is required of all newly accepted projects until a further
> >> review
> >> indicates that the infrastructure, communications, and decision making
> >> process
> >> have stabilized in a manner consistent with other successful ASF
> projects.
> >>
> >> While incubation status is not necessarily a reflection of the
> completeness
> >> or stability of the code, it does indicate that the project has yet to
> be
> >> fully endorsed by the ASF.
> >>
> >>
> >>
> >> On Wed, Sep 18, 2013 at 6:24 AM, Grant Ingersoll 
> >> wrote:
> >> > +1, binding
> >> >
> >> > On Sep 17, 2013, at 6:29 PM, Ted Dunning 
> wrote:
> >> >
> >> >> We've held a vote on drill-dev to release the first milestone
> release.
> >> >>
> >> >> The vote thread can be found here:
> >> >>
> >> >>
> >>
> http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3ccaka9qdkmxjp-r8v+zwabm5e4b5osrypjyp+dupvq2lr-d70...@mail.gmail.com%3E
> >> >>
> >> >> The vote passed with
> >> >>
> >> >> 4 x +1 binding votes
> >> >> 7 x +1 non-binding votes
> >> >>
> >> >> An additional non-binding +1 vote was received after the vote closed.
> >> >>
> >> >> A summary email can be found here:
> >> >>
> >> >>
> >>
> http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3CCAKa9qDn1+TnKVP=p_=Lh==mOS=azctuz6_qvsm4u3z4gdhh...@mail.gmail.com%3E
> >> >>
> >> >> The source only release artifactscan be found together with
> signatures
> >> here:
> >> >>
> >> >> http://people.apache.org/~jacques/apache-drill-1.0.0-m1.rc4/
> >> >> Please vote on this release
> >> >
> >> >
> >>
> >> -
> >> 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] first milestone release of Apache Drill (incubating)

[Ted Dunning]

This vote has been open for nearly 24 hours out of 72 hours and has just
over 48 hours to run.

This is a tickler in case somebody wants to vote, but has been distracted.

The current tally is 4 binding +1, 1 ambiguous, none against.



On Tue, Sep 17, 2013 at 3:29 PM, Ted Dunning  wrote:

> We've held a vote on drill-dev to release the first milestone release.
>
> The vote thread can be found here:
>
>
> http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3ccaka9qdkmxjp-r8v+zwabm5e4b5osrypjyp+dupvq2lr-d70...@mail.gmail.com%3E
>
> The vote passed with
>
> 4 x +1 binding votes
> 7 x +1 non-binding votes
>
> An additional non-binding +1 vote was received after the vote closed.
>
> A summary email can be found here:
>
>
> http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3CCAKa9qDn1+TnKVP=p_=Lh==mOS=azctuz6_qvsm4u3z4gdhh...@mail.gmail.com%3E
>
> The source only release artifactscan be found together with signatures
> here:
>
> http://people.apache.org/~jacques/apache-drill-1.0.0-m1.rc4/
> Please vote on this release
>
>

Re: [VOTE] first milestone release of Apache Drill (incubating)

[Ted Dunning]

It is in version control as per custom.  Drill uses git so it might not be
quite as obvious if you are used to SVN.

See, for instance,

https://git-wip-us.apache.org/repos/asf?p=incubator-drill.git;a=blob;f=KEYS;h=205469b84b8bda60fcb87486182d4fb7caf0485d;hb=HEAD


On Wed, Sep 18, 2013 at 8:25 PM, Dave Brondsema  wrote:

> Do you have a KEYS file posted somewhere besides within the release?
>
> On 09/17/2013 06:29 PM, Ted Dunning wrote:
> > We've held a vote on drill-dev to release the first milestone release.
> >
> > The vote thread can be found here:
> >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3ccaka9qdkmxjp-r8v+zwabm5e4b5osrypjyp+dupvq2lr-d70...@mail.gmail.com%3E
> >
> > The vote passed with
> >
> > 4 x +1 binding votes
> > 7 x +1 non-binding votes
> >
> > An additional non-binding +1 vote was received after the vote closed.
> >
> > A summary email can be found here:
> >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3CCAKa9qDn1+TnKVP=p_=Lh==mOS=azctuz6_qvsm4u3z4gdhh...@mail.gmail.com%3E
> >
> > The source only release artifactscan be found together with signatures
> here:
> >
> > http://people.apache.org/~jacques/apache-drill-1.0.0-m1.rc4/
> > Please vote on this release
> >
>
>
> --
> Dave Brondsema : d...@brondsema.net
> http://www.brondsema.net : personal
> http://www.splike.com : programming
><><
>
>

Re: [VOTE] first milestone release of Apache Drill (incubating)

[Ted Dunning]

Christian,

You reported DRILL-12 <https://issues.apache.org/jira/browse/DRILL-12>some
time ago.

In response, I did the search and documented my results here:

https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-16

Can you explain what is missing?





On Sun, Sep 22, 2013 at 6:44 AM, Christian Grobmeier wrote:

> Hi,
>
> Could you please explain why the projects thinks a trademark process is
> not required?
> http://incubator.apache.org/**projects/drill.html<http://incubator.apache.org/projects/drill.html>
>
> For me it is required to clear the name before a product is published:
> http://www.apache.org/**foundation/marks/naming.html<http://www.apache.org/foundation/marks/naming.html>
> I don't see why Drill is an exception, but maybe I have missed something.
>
> Until I know more, I need to -1 this.
>
> Thanks!
>
>
>
>  On Tue, Sep 17, 2013 at 03:29:46PM -0700, Ted Dunning wrote:
>>
>>> We've held a vote on drill-dev to release the first milestone release.
>>>
>>> The vote thread can be found here:
>>>
>>> http://mail-archives.apache.**org/mod_mbox/incubator-drill-**
>>> dev/201309.mbox/%**3CCAKa9qDkMxJp-r8v+**ZwabM5E4b5osrypJyp+DuPvq2LR-**
>>> d70...@mail.gmail.com%3E<http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3ccaka9qdkmxjp-r8v+zwabm5e4b5osrypjyp+dupvq2lr-d70...@mail.gmail.com%3E>
>>>
>>> The vote passed with
>>>
>>> 4 x +1 binding votes
>>> 7 x +1 non-binding votes
>>>
>>> An additional non-binding +1 vote was received after the vote closed.
>>>
>>> A summary email can be found here:
>>>
>>> http://mail-archives.apache.**org/mod_mbox/incubator-drill-**
>>> dev/201309.mbox/%3CCAKa9qDn1+**TnKVP=p_=Lh==mOS=azctUz6_**
>>> Qvsm4U3Z4gdhHHgQ@mail.gmail.**com%3E<http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3CCAKa9qDn1+TnKVP=p_=Lh==mOS=azctuz6_qvsm4u3z4gdhh...@mail.gmail.com%3E>
>>>
>>> The source only release artifactscan be found together with signatures
>>> here:
>>>
>>> http://people.apache.org/~**jacques/apache-drill-1.0.0-m1.**rc4/<http://people.apache.org/~jacques/apache-drill-1.0.0-m1.rc4/>
>>> Please vote on this release
>>>
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> general-unsubscribe@incubator.**apache.org
>> For additional commands, e-mail: 
>> general-help@incubator.apache.**org
>>
>

Re: [VOTE] first milestone release of Apache Drill (incubating)

[Ted Dunning]

- moving trademarks@ to bcc to avoid mixing private and public lists

*Christian*,

Do you withdraw this -1 now that Shane has said that we don't have to wait
for PODLINGNAMESEARCH-16 to close?

I will edit the product status page to reflect current (non) progress.


On Sun, Sep 22, 2013 at 6:44 AM, Christian Grobmeier wrote:

> Hi,
>
> Could you please explain why the projects thinks a trademark process is
> not required?
> http://incubator.apache.org/**projects/drill.html<http://incubator.apache.org/projects/drill.html>
>
> For me it is required to clear the name before a product is published:
> http://www.apache.org/**foundation/marks/naming.html<http://www.apache.org/foundation/marks/naming.html>
> I don't see why Drill is an exception, but maybe I have missed something.
>
> Until I know more, I need to -1 this.
>
> Thanks!
>
>
>
>  On Tue, Sep 17, 2013 at 03:29:46PM -0700, Ted Dunning wrote:
>>
>>> We've held a vote on drill-dev to release the first milestone release.
>>>
>>> The vote thread can be found here:
>>>
>>> http://mail-archives.apache.**org/mod_mbox/incubator-drill-**
>>> dev/201309.mbox/%**3CCAKa9qDkMxJp-r8v+**ZwabM5E4b5osrypJyp+DuPvq2LR-**
>>> d70...@mail.gmail.com%3E<http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3ccaka9qdkmxjp-r8v+zwabm5e4b5osrypjyp+dupvq2lr-d70...@mail.gmail.com%3E>
>>>
>>> The vote passed with
>>>
>>> 4 x +1 binding votes
>>> 7 x +1 non-binding votes
>>>
>>> An additional non-binding +1 vote was received after the vote closed.
>>>
>>> A summary email can be found here:
>>>
>>> http://mail-archives.apache.**org/mod_mbox/incubator-drill-**
>>> dev/201309.mbox/%3CCAKa9qDn1+**TnKVP=p_=Lh==mOS=azctUz6_**
>>> Qvsm4U3Z4gdhHHgQ@mail.gmail.**com%3E<http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3CCAKa9qDn1+TnKVP=p_=Lh==mOS=azctuz6_qvsm4u3z4gdhh...@mail.gmail.com%3E>
>>>
>>> The source only release artifactscan be found together with signatures
>>> here:
>>>
>>> http://people.apache.org/~**jacques/apache-drill-1.0.0-m1.**rc4/<http://people.apache.org/~jacques/apache-drill-1.0.0-m1.rc4/>
>>> Please vote on this release
>>>
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> general-unsubscribe@incubator.**apache.org
>> For additional commands, e-mail: 
>> general-help@incubator.apache.**org
>>
>

Re: [VOTE] first milestone release of Apache Drill (incubating)

[Ted Dunning]

- trademarks@ to avoid mixing public and private threads

Christian,

Shane has answered your worry about whether VP Brands has to close the name
search before DRILL can release.

I have created the link you requested on the podling status page.  Note
again that the name search was done *a year ago*.  Far from neglecting
naming issues, this podling has been very far out in front on this issue.
 The hangup is entirely with VP Brands.

Release votes are majority votes in any case [1].  I would prefer it if we
had complete consensus here, so if you can update your vote, I would
appreciate it.






On Sun, Sep 22, 2013 at 6:44 AM, Christian Grobmeier wrote:

> Hi,
>
> Could you please explain why the projects thinks a trademark process is
> not required?
> http://incubator.apache.org/**projects/drill.html<http://incubator.apache.org/projects/drill.html>
>
> For me it is required to clear the name before a product is published:
> http://www.apache.org/**foundation/marks/naming.html<http://www.apache.org/foundation/marks/naming.html>
> I don't see why Drill is an exception, but maybe I have missed something.
>
> Until I know more, I need to -1 this.
>
> Thanks!
>
>
>
>  On Tue, Sep 17, 2013 at 03:29:46PM -0700, Ted Dunning wrote:
>>
>>> We've held a vote on drill-dev to release the first milestone release.
>>>
>>> The vote thread can be found here:
>>>
>>> http://mail-archives.apache.**org/mod_mbox/incubator-drill-**
>>> dev/201309.mbox/%**3CCAKa9qDkMxJp-r8v+**ZwabM5E4b5osrypJyp+DuPvq2LR-**
>>> d70...@mail.gmail.com%3E<http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3ccaka9qdkmxjp-r8v+zwabm5e4b5osrypjyp+dupvq2lr-d70...@mail.gmail.com%3E>
>>>
>>> The vote passed with
>>>
>>> 4 x +1 binding votes
>>> 7 x +1 non-binding votes
>>>
>>> An additional non-binding +1 vote was received after the vote closed.
>>>
>>> A summary email can be found here:
>>>
>>> http://mail-archives.apache.**org/mod_mbox/incubator-drill-**
>>> dev/201309.mbox/%3CCAKa9qDn1+**TnKVP=p_=Lh==mOS=azctUz6_**
>>> Qvsm4U3Z4gdhHHgQ@mail.gmail.**com%3E<http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3CCAKa9qDn1+TnKVP=p_=Lh==mOS=azctuz6_qvsm4u3z4gdhh...@mail.gmail.com%3E>
>>>
>>> The source only release artifactscan be found together with signatures
>>> here:
>>>
>>> http://people.apache.org/~**jacques/apache-drill-1.0.0-m1.**rc4/<http://people.apache.org/~jacques/apache-drill-1.0.0-m1.rc4/>
>>> Please vote on this release
>>>
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> general-unsubscribe@incubator.**apache.org
>> For additional commands, e-mail: 
>> general-help@incubator.apache.**org
>>
>

Re: [RESULT] first milestone release of Apache Drill (incubating)

[Ted Dunning]

This vote has closed and has passed according to majority vote because it
has at least 3 +1 votes and more +1 than -1 votes.

The final tally is this:

*Binding +1 votes*

Ted Dunning
Steve Loughran
Benson Margulies
Grant Ingersoll
Henry Saputra
Isabel Drost-Fromm

*Binding -1 votes*

Christian Grobmeier


As a side note, Christian's negative vote had to do with name search
hygiene which has, in fact, been completed but not approved by VP Brands
(Shane).  Shane has said that approval should not gate the release and if
we delayed the result of this vote, I expect that Christian would reverse
his vote, based on his off-thread comments.



On Mon, Sep 23, 2013 at 3:42 PM, Ted Dunning  wrote:

> - trademarks@ to avoid mixing public and private threads
>
> Christian,
>
> Shane has answered your worry about whether VP Brands has to close the
> name search before DRILL can release.
>
> I have created the link you requested on the podling status page.  Note
> again that the name search was done *a year ago*.  Far from neglecting
> naming issues, this podling has been very far out in front on this issue.
>  The hangup is entirely with VP Brands.
>
> Release votes are majority votes in any case [1].  I would prefer it if we
> had complete consensus here, so if you can update your vote, I would
> appreciate it.
>
>
>
>
>
>
> On Sun, Sep 22, 2013 at 6:44 AM, Christian Grobmeier 
> wrote:
>
>> Hi,
>>
>> Could you please explain why the projects thinks a trademark process is
>> not required?
>> http://incubator.apache.org/**projects/drill.html<http://incubator.apache.org/projects/drill.html>
>>
>> For me it is required to clear the name before a product is published:
>> http://www.apache.org/**foundation/marks/naming.html<http://www.apache.org/foundation/marks/naming.html>
>> I don't see why Drill is an exception, but maybe I have missed something.
>>
>> Until I know more, I need to -1 this.
>>
>> Thanks!
>>
>>
>>
>>  On Tue, Sep 17, 2013 at 03:29:46PM -0700, Ted Dunning wrote:
>>>
>>>> We've held a vote on drill-dev to release the first milestone release.
>>>>
>>>> The vote thread can be found here:
>>>>
>>>> http://mail-archives.apache.**org/mod_mbox/incubator-drill-**
>>>> dev/201309.mbox/%**3CCAKa9qDkMxJp-r8v+**ZwabM5E4b5osrypJyp+DuPvq2LR-**
>>>> d70...@mail.gmail.com%3E<http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3ccaka9qdkmxjp-r8v+zwabm5e4b5osrypjyp+dupvq2lr-d70...@mail.gmail.com%3E>
>>>>
>>>> The vote passed with
>>>>
>>>> 4 x +1 binding votes
>>>> 7 x +1 non-binding votes
>>>>
>>>> An additional non-binding +1 vote was received after the vote closed.
>>>>
>>>> A summary email can be found here:
>>>>
>>>> http://mail-archives.apache.**org/mod_mbox/incubator-drill-**
>>>> dev/201309.mbox/%3CCAKa9qDn1+**TnKVP=p_=Lh==mOS=azctUz6_**
>>>> Qvsm4U3Z4gdhHHgQ@mail.gmail.**com%3E<http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201309.mbox/%3CCAKa9qDn1+TnKVP=p_=Lh==mOS=azctuz6_qvsm4u3z4gdhh...@mail.gmail.com%3E>
>>>>
>>>> The source only release artifactscan be found together with signatures
>>>> here:
>>>>
>>>> http://people.apache.org/~**jacques/apache-drill-1.0.0-m1.**rc4/<http://people.apache.org/~jacques/apache-drill-1.0.0-m1.rc4/>
>>>> Please vote on this release
>>>>
>>>
>>> --**--**
>>> -
>>> To unsubscribe, e-mail: 
>>> general-unsubscribe@incubator.**apache.org
>>> For additional commands, e-mail: 
>>> general-help@incubator.apache.**org
>>>
>>
>

Re: Too many late reports

[Ted Dunning]

On Sun, Oct 6, 2013 at 9:28 PM, Roman Shaposhnik  wrote:

> If my shepherding perspective is any indication this has been quite chronic
> (although this month feels particularly bad). I think you're absolutely
> right
> in suggesting that we should try and address this somehow.
>

One thing that has helped Drill respond to late notifications is to start
the next report the day after the previous one is done.

We have our community builders note things of interest as they happen in a
kind of a log entry fashion.  This is really easy to fashion into a report
when the time comes which in turn means that it is (much) easier to find
the manpower on short notice.

Re: Licensing question for new incubator project

[Ted Dunning]

On Fri, Oct 11, 2013 at 12:11 PM, Christian Grobmeier
wrote:

> company. I would therefore like to verify that, in order to contribute the
>> project to ASF, they will be required to sign a Corporate CLA, and a
>> Software Grant Agreement.
>>
>
> yes, the company will need to sign a software grant and imho should sign a
> corporate CLA.


If they are making a single grant, then the corporate CLA is probably not
necessary.  Might be nice to have, but if you are leaving and you are the
open source guy, then it probably will become moot since the set of
contributors under the CCLA will become empty.

Re: Cultivating Outstanding IP Stewards

[Ted Dunning]

On Thu, Nov 7, 2013 at 11:13 AM, Marvin Humphrey wrote:

> The Incubator has a fundamental structural flaw: it lacks a mechanism to
> reward merit earned by individual podling contributors.  Instead, we teach
> people to hate the Incubator by placing their projects at the mercy of
> Mentors.  Our Mentors care, but they don't care enough.  They don't care
> like
> core developers care.
>

Nominate these meritorious contributors as IPMC members.

Re: [VOTE] Accept Twill for Incubation

[Ted Dunning]

+1 (binding)




On Thu, Nov 7, 2013 at 9:32 PM, Patrick Hunt  wrote:

> +1 Accept Twill into the Incubator
>
> Patrick
>
> On Thu, Nov 7, 2013 at 1:04 PM, Andreas Neumann  wrote:
> > The discussion about the Weave proposal has calmed. As the outcome of the
> > discussion, we have chosen a new name for the project, Twill. I would
> like
> > to call a vote for Twill to become an incubated project.
> >
> > The proposal is pasted below, and also available at:
> > https://wiki.apache.org/incubator/TwillProposal
> >
> > Let's keep this vote open for three business days, closing the voting on
> > Tuesday 11/12.
> >
> > [ ] +1 Accept Twill into the Incubator
> > [ ] +0 Don't care.
> > [ ] -1 Don't accept Twill because...
> >
> > -Andreas.
> >
> > = Abstract =
> >
> > Twill is an abstraction over Apache Hadoop® YARN that reduces the
> > complexity of developing distributed applications, allowing developers to
> > focus more on their business logic.
> >
> > = Proposal =
> >
> > Twill is a set of libraries that reduces the complexity of developing
> > distributed applications. It exposes the distributed capabilities of
> Apache
> > Hadoop® YARN via a simple and intuitive programming model similar to Java
> > threads. Twill also has built-in capabilities required by many
> distributed
> > applications, such as real-time application logs and metrics collection,
> > application lifecycle management, and network service discovery.
> >
> > = Background =
> >
> > Hadoop YARN is a generic cluster resource manager that supports any type
> of
> > distributed application. However, YARN’s interfaces are too low level for
> > rapid application development. It requires a great deal of boilerplate
> code
> > even for a simple application, creating a high ramp up cost that can turn
> > developers away.
> >
> > Twill is designed to improve this situation with a programming model that
> > makes running distributed applications as easy as running Java threads.
> > With the abstraction provided by Twill, applications can be executed in
> > process threads during development and unit testing and then be deployed
> to
> > a YARN cluster without any modifications.
> >
> > Twill also has built-in support for real-time application logs and
> metrics
> > collection, delegation token renewal, application lifecycle management,
> and
> > network service discovery. This greatly reduces the pain that developers
> > face when developing, debugging, deploying and monitoring distributed
> > applications.
> >
> > Twill is not a replacement for YARN, it’s a framework that operates on
> top
> > of YARN.
> >
> > = Rationale =
> >
> > Developers who write YARN applications typically find themselves
> > implementing the same (or similar) boilerplate code over and over again
> > for every application. It makes sense to distill this common code into a
> > reusable set of libraries that is perpetually maintained and improved by
> a
> > diverse community of developers.
> >
> > Twill’s simple thread-like programming model will enable many Java
> > programmers to develop distributed applications. We believe that this
> > simplicity will attract developers who would otherwise be discouraged by
> > complexity, and many new use cases will emerge for the usage of YARN.
> >
> > Incubating Twill as an Apache project makes sense because Twill is a
> > framework built on top of YARN, and Twill uses Apache Zookeeper, HDFS,
> > Kafka, and other Apache software (see the External Dependencies section).
> >
> > = Current Status =
> >
> > Twill was initially developed at Continuuity under the name of Weave. The
> > Weave codebase is currently hosted in a public repository at github.com,
> > which will seed the Apache git repository after renaming to Twill.
> >
> > == Meritocracy ==
> >
> > Our intent with this incubator proposal is to start building a diverse
> > developer community around Twill following the Apache meritocracy model.
> > Since Twill was initially developed in early 2013, we have had fast
> > adoption and contributions within Continuuity. We are looking forward to
> > new contributors. We wish to build a community based on Apache's
> > meritocracy principles, working with those who contribute significantly
> to
> > the project and welcoming them to be committers both during the
> incubation
> > process and beyond.
> >
> > == Community ==
> >
> > Twill is currently being used internally at Continuuity and is at the
> core
> > of our products. We hope to extend our contributor base significantly and
> > we will invite all who are interested in simplifying the development of
> > distributed applications to participate.
> >
> > == Core Developers ==
> >
> > Twill is currently being developed by five engineers at Continuuity:
> > Terence Yim, Andreas Neumann, Gary Helmling, Poorna Chandra and Albert
> > Shau.
> > Terence Yim is an Apache committer for Helix, Andreas is an Apache
> > committer and PMC member for Oozie, and Gary Helmling is an Apache
> > committer

Re: Do we need a disclaimer? (Storm)

[Ted Dunning]

First few words should read "A disclaimer ..."

I blame a combo of jet lag and *really* slow net link.  Not the guy who hit
send without proofing, of course.

On Fri, Nov 15, 2013 at 7:41 AM, Ted Dunning  wrote:

>
> I disclaimer to clarify that the 0.9.0 release is neither an Apache
> top-level project release nor an Apache incubator release is probably good.
>  A file name like DISCLAIMER might be good.
>
> I would worry about it being clear rather than being totally crafted by a
> true legal mind.
>
>
> On Fri, Nov 15, 2013 at 4:48 AM, P. Taylor Goetz wrote:
>
>> The Strom project is just entering the incubator. We have promised our
>> community that we will issue a stable 0.9.0 release prior to switching over
>> to the Apache release process. We are currently in a release candidate
>> process.
>>
>> Now that we are an Incubator project, but not yet releasing under the
>> Apache process, should we be including a disclaimer with our pre-Apache
>> releases stating so?
>>
>> It feels like we should have some sort legalese in place.
>>
>> - Taylor
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>

Re: [VOTE] Phoenix for incubator project

[Ted Dunning]

+1 (binding)



On Thu, Dec 5, 2013 at 3:42 PM, Anil Gupta  wrote:

> +1
>
> Hope to see Phoenix in Apache family.
>
> Sent from my iPhone
>
> > On Dec 5, 2013, at 1:43 PM, Stack  wrote:
> >
> > Discussion of the Phoenix proposal has settled since its original
> > posting on November 7th.  Feedback has been incorporated.
> >
> > Let us now move to a vote.
> >
> > Should Phoenix become an Apache incubator project?
> >
> > [] +1 Accept Phoenix into the Incubator
> > [] +0 Don't care whether or which
> > [] -1 Do not accept Phoenix into the Incubator because...
> >
> > The latest version of the proposal can be found here [1].  It is
> > also posted below for your convenience.
> >
> > Let the vote run 72 hours.
> >
> > Thank you,
> > St.Ack
> >
> > 1. https://wiki.apache.org/incubator/PhoenixProposal
> >
> >
> >
> >
> > Abstract
> >
> > Phoenix is an open source SQL query engine for Apache HBase, a NoSQL data
> > store. It is accessed as a JDBC driver and enables querying and managing
> > HBase tables using SQL.
> >
> > Proposal
> >
> > Phoenix is an open source SQL skin over HBase delivered as a
> > client-embedded JDBC driver targeting low latency queries over HBase
> data.
> > Phoenix takes your SQL query, compiles it into a series of HBase scans,
> and
> > orchestrates the running of those scans to produce regular JDBC result
> > sets. The table metadata is stored in an HBase table and versioned, such
> > that snapshot queries over prior versions will automatically use the
> > correct schema. Direct use of the HBase API, along with coprocessors and
> > custom filters, results in performance on the order of milliseconds for
> > small queries, or seconds for tens of millions of rows. Phoenix
> interfaces
> > with both Pig and Map-reduce for the input and output of data.
> >
> > Background
> >
> > Phoenix initially started as an internal project at Salesforce.com to
> > efficiently analyze big data stored in HBase. It was open sourced on
> Github
> > about a year ago in Jan 2013. Over time Phoenix, together with HBase as
> the
> > storage tier, has begun to evolve into a general SQL database with
> support
> > for metadata management, secondary indexes, joins, query optimization,
> and
> > multi-tenancy. This is expected to continue as Phoenix implements a
> > cost-based query optimizer and potentially transaction support, and
> > surfaces new HBase security features such as encryption and cell-level
> > security. Phoenix's developer community has also grown to include
> > additional companies such as Intel, who have contributed join support to
> > Phoenix, as well as Hortonworks, who are in the process of porting
> Phoenix
> > to the 0.96 release of HBase.
> >
> > Rationale
> >
> > As usage and the number of contributors to Phoenix has grown, we have
> > sought for a long-term home for the project, and we believe the Apache
> > foundation would be a great fit. Joining Apache would ensure that tried
> and
> > true processes and procedures are in place for the growing number of
> > organizations interested in contributing to Phoenix. Phoenix is also a
> good
> > fit for the Apache foundation: Phoenix already interoperates with several
> > existing Apache projects (HBase, Hadoop, Pig, BigTop). The Phoenix team
> is
> > familiar with the Apache process and and believes in the Apache mission -
> > the team already includes multiple Apache committers.
> >
> > Initial Goals
> >
> > The initial goals will be to move the existing codebase to Apache and
> > integrate with the Apache development process. Once this is accomplished,
> > we plan for incremental development and releases that follow the Apache
> > guidelines.
> >
> > Current Status
> >
> > Phoenix has undergone two major and three minor releases (1.0, 1.1, 1.2,
> > 2.0, and 2.1) as well as many patch releases. Phoenix is being used in
> > production by Salesforce.com as well as at other organizations. The
> Phoenix
> > codebase is currently hosted at github.com, which will form the basis of
> > the Apache git repository.
> >
> > Meritocracy
> >
> > The Phoenix project already operates on meritocratic principles. Phoenix
> > has several developers from various organizations outside of
> Salesforce.com
> > who have contributed major new features. While this process has remained
> > mostly informal, as we do not have an official committer list, an
> implicit
> > organization exists in which individuals who contribute major components
> > act as maintainers for those modules. If accepted, the Phoenix project
> > would include several of these participants as initial committers. We
> will
> > work to identify all committers and PPMC members for the project and to
> > operate under the ASF meritocratic principles.
> >
> > Community
> >
> > Acceptance into the Apache foundation would bolster the already strong
> user
> > and developer community around Phoenix. That community includes many
> > contributors from various other companies, and an active mailing list
> 

Re: Engaging Mentors

[Ted Dunning]

On Mon, Dec 9, 2013 at 5:45 AM, Matt Franklin wrote:

> Christian is right.  We are watching the lists and follow the discussions,
> but do look for DISCUSS, VOTE, or MENTOR flags especially.
>
>
> On Thu, Dec 5, 2013 at 3:07 AM, Christian Grobmeier  >wrote:
>
> > Taylor,
> >
> > your mentors should read the mailing lists. Why I would not expect to get
> > answers when a question is hidden in a technical detail question, a
> subject
> > line with [MENTOR] in it should draw attention. I expect mentors to read
> > all subject lines.
>


I should point out that this discussion caught my eye (being a mentor of
Storm).

Re: IP Clearance before releasing

[Ted Dunning]

A point which is often missed by new comers is that votes aren't final
until they vote closes and is tallied.

That allows a vote that uncovers a serious defect to trigger a bunch of
defecting votes (if the vote isn't just canceled)


On Thu, Dec 12, 2013 at 11:02 AM, Doug Cutting  wrote:

> On Thu, Dec 12, 2013 at 7:38 AM, Alex Harui  wrote:
>
> > There's no whistleblower provision
> > for someone who thinks they see something that puts the foundation at
> risk
> > from stopping those to don't see it.
> >
>
> If there's a clear legal problem with a release candidate I'd expect others
> to acknowledge it and cancel the vote.  If they don't then that could be
> escalated to the Incubator PMC.
>
> Doug
>

Re: [VOTE] Accept DataFu into the Incubator

[Ted Dunning]

+1 Binding


On Tue, Dec 31, 2013 at 1:19 PM, Joe Stein  wrote:

> +1 (non-binding)
>
> Awesome! Happy New Year!!!
>
> - Joe Stein
>
>
> On Dec 31, 2013, at 3:48 PM, Roman Shaposhnik  wrote:
>
> > On Tue, Dec 31, 2013 at 12:39 PM, Jakob Homan  wrote:
> >> Incubator-
> >>
> >> Following the discussion earlier, I'm calling a vote to accept DataFu
> as a
> >> new Incubator project.
> >>
> >> The proposal draft is available at:
> >> https://wiki.apache.org/incubator/DataFuProposal, and is also included
> >> below.
> >>
> >> Vote is open for at least 96h and closes at the earliest on 4 Jan 13:00
> >> PDT.  I'm letting the vote run an extra day as we're in the holiday
> season.
> >>
> >> [ ] +1 accept DataFu in the Incubator
> >> [ ] +/-0
> >> [ ] -1 because...
> >>
> >> Here's my binding +1.
> >
> > +1 (binding)
> >
> > Thanks,
> > Roman.
> >
> > -
> > 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: GSoC Donation and/or clearance

[Ted Dunning]

The standard rules all apply to GSoC students.  They should do their code
in as close to the standard way as possible (which would have precluded the
code being outside at this point) and they should file and ICLA if they do
enough to warrant it.



On Wed, Jan 8, 2014 at 4:32 AM, Alexander Broekhuis
wrote:

> Hi all,
>
> Perhaps this has been asked before, but I couldn't find a complete answer..
>
> This summer a GSoC student implemented something for Celix which we now
> want to include. Since this code is written outside of the foundation, I
> would assume a standard code grant and clearance is needed.
>
> Is this correct? And if so, who is the owner of that code? In other words,
> who needs to send in the grant?
>
> Any feedback is appreciated!
>
> --
> Met vriendelijke groet,
>
> Alexander Broekhuis
>

Re: Hoya Proposal

[Ted Dunning]

Too many people will read that as Jena, the city in Thuringia.

https://en.wikipedia.org/wiki/Jena

-1




On Mon, Jan 13, 2014 at 1:57 PM, Andy Seaborne  wrote:

> On 13/01/14 20:25, Bertrand Delacretaz wrote:
>
>> On Mon, Jan 13, 2014 at 5:36 PM, Bertrand Delacretaz
>>  wrote:
>>
>>> On Mon, Jan 13, 2014 at 3:33 PM, Steve Loughran 
>>> wrote:
>>>
 ...What do people think about a project name "Hyena"? It's close
 enough, lives
 in the savannah...

>>>
>>> I think it's too close to http://jena.apache.org/
>>>
>>
>> to be clear, this is a strong -1 from me, having confusing project
>> names inside Apache is not ok. Hyena and Jena sound exactly the same
>> in several languages, unfortunately.
>>
>
> The "j-e-n" in "Jena" is like "Jen-kins" or "Gen-er-al".
>
> It is derived from "Jennifer"
>
> http://en.wikipedia.org/wiki/Jennifer_%28given_name%29
>
> which is often, but not here, with "nn":
>
> http://en.wikipedia.org/wiki/Jenna
>
> Andy
>
>
>> -Bertrand
>>
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Graduation of Apache Spark from the Incubator

[Ted Dunning]

+1




On Fri, Jan 31, 2014 at 6:04 PM, Matei Zaharia wrote:

> Hi folks,
>
> The Apache Spark community has VOTEd to graduate from the Apache incubator
> (vote thread: http://s.apache.org/kq, discussion thread:
> http://s.apache.org/aEQ).
>
> I’m now calling an official IPMC VOTE to make this happen as well. Here’s
> the community tally:
>
> +1
> Matei Zaharia
> Reynold Xin
> Tathagata Das
> Sean McNamara
> Patrick Wendell
> Mark Hamstra
> Chris Mattmann *
> Tom Graves
> Henry Saputra *
> Andy Konwinski
> Josh Rosen
> Mosharaf Chowdhury
> Mridul Muralidharan
> Nick Pentreath
> Andrew Xia
> Haoyuan Li
> Sandy Ryza
> Sebastian Schelter *
> Kostas Sakellis
> Christopher Nguyen
> Aaron Davidson
> Shivaram Venkataraman
> Kay Ousterhout
> Evan Sparks
> Xuefeng Wu
> Konstantin Boudnik
> Rahul Chugh
> Prashant Sharma
> Stephen Haberman
> Prabeesh K.
> Saisai Shao
> Junfeng Feng
> Jason Dai
> Stevo Slavic
> Heiko Braun
> Xia Zhu
> Manoj Awasthi
>
> +0
> (none)
>
> -1
> (none)
>
> * indicates IPMC member
>
> We’ve made three releases in the incubator, added new committers and IPMC
> members, checked off the various requirements to migrate the development
> process to the ASF, and more generally worked to build this community in
> the Apache way.
>
> Please VOTE to graduate Apache Spark from the incubator. I’ll leave the
> VOTE open for 96 hours, until February 4th, 2014. The graduation resolution
> is pasted below.
>
> Thanks!
>
> Matei and the Apache Spark community
>
>  snip
>
> WHEREAS, the Board of Directors deems it to be in the best
> interests of the Foundation and consistent with the
> Foundation's purpose to establish a Project Management
> Committee charged with the creation and maintenance of
> open-source software, for distribution at no charge to the
> public, related to fast and flexible large-scale data analysis
> on clusters.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> Committee (PMC), to be known as the "Apache Spark Project", be
> and hereby is established pursuant to Bylaws of the Foundation;
> and be it further
>
> RESOLVED, that the Apache Spark Project be and hereby is
> responsible for the creation and maintenance of software
> related to efficient cluster management, resource isolation
> and sharing across distributed applications; and be it further
> RESOLVED, that the office of "Vice President, Apache Spark" be
> and hereby is created, the person holding such office to serve
> at the direction of the Board of Directors as the chair of the
> Apache Spark Project, and to have primary responsibility for
> management of the projects within the scope of responsibility
> of the Apache Spark Project; and be it further
> RESOLVED, that the persons listed immediately below be and
> hereby are appointed to serve as the initial members of the
> Apache Spark Project:
>
> * Mosharaf Chowdhury 
> * Jason Dai 
> * Tathagata Das 
> * Ankur Dave 
> * Aaron Davidson 
> * Thomas Dudziak 
> * Robert Evans 
> * Thomas Graves 
> * Andy Konwinski 
> * Stephen Haberman 
> * Mark Hamstra 
> * Shane Huang 
> * Ryan LeCompte 
> * Haoyuan Li 
> * Sean McNamara 
> * Mridul Muralidharam 
> * Kay Ousterhout 
> * Nick Pentreath 
> * Imran Rashid 
> * Charles Reiss 
> * Josh Rosen 
> * Prashant Sharma 
> * Ram Sriharsha 
> * Shivaram Venkataraman 
> * Patrick Wendell 
> * Andrew Xia 
> * Reynold Xin 
> * Matei Zaharia 
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Matei Zaharia be
> appointed to the office of Vice President, Apache Spark, to
> serve in accordance with and subject to the direction of the
> Board of Directors and the Bylaws of the Foundation until
> death, resignation, retirement, removal or disqualification, or
> until a successor is appointed; and be it further
>
> RESOLVED, that the Apache Spark Project be and hereby is
> tasked with the migration and rationalization of the Apache
> Incubator Spark podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache
> Incubator Spark podling encumbered upon the Apache Incubator
> Project are hereafter discharged.
>
> 
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Graduation of Apache Spark from the Incubator

[Ted Dunning]

+1 (binding)

These wrinkles are not as big as they appear.  For instance, the issue with 
some committers not noticing that their accounts were live is actually due to a 
better submission and review process than most tlp's exhibit.

The spark community has more of the apache spirit in it than most incubator 
projects lately. Notably they also take feedback about how to tune their 
processes very well.  

Sent from my iPhone

On Feb 7, 2014, at 4:05, David Nalley  wrote:

>> 
>> Hope this helps to ease your concern about Spark podling readiness to
>> become TLP.
> 
> 
> I am a bit conflicted. Part of me is inclined to join Craig, Sebb, and
> Bertand and issue a -1. At the same time, there exist many +1s here
> from folks that I respect and trust, including the mentors of the
> podling; and I think they are far better placed than me to judge the
> true state of the podling.
> 
> The part that disturbs me is that after the vote passed in the
> community, and came to the IPMC a mentor is still having to remind
> folks that things like strategy and roadmap discussions need to happen
> on the mailing list. That's a pretty foundational concept in my mind
> for an Apache project.
> 
> The missing account issues are somewhat troubling, but also not really
> within the purview of the podling to fix either; though I find it odd
> that people committed to the podling (and many initial committers)
> haven't asked for their Apache account or needed to use it.
> 
> Love to hear opinions, even if they are stating that I am meddling or crazy :)
> 
> --David
> 
> -
> 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: Tool to generate disclaimer, NOTICE, etc. files

[Ted Dunning]

On Sat, Feb 8, 2014 at 7:42 PM, sebb  wrote:

> > WDYT?
>
> Non-trivial; maintaining the meta-data needed to accurately generate
> the NOTICE file is likely to require more effort than writing the
> NOTICE file itself.
>


Actually, this sounds like a case where the effort for any individual
project outweighs the benefit of saving the time, but the total effort
across many projects would make the effort somewhat worth while.  In
particular, something that enhances the communication between projects and
between the author of the dependency and the users of that dependency would
be very helpful.

As such, this sounds like a great thing to add to maven.  If it provided me
with a way to look at all my dependencies and examine my notices file for
missing acknowledgments, that would be helpful.  Moreover, if there were a
way for the community of users to upload sample acknowledgements and for
the owners of such packages to reject or accept these acknowledgments, this
would crowdsource the effort of approval.

My guess is that since getting NOTIFICATIONS right is a largely one shot
deal, it wouldn't be enough appeal to encourage somebody to actually
implement the system, but it would certainly make one's life easier in
small installments.

Re: Github pull request hooks

[Ted Dunning]

On Mon, Feb 10, 2014 at 7:01 AM, Sergio Fernández <
sergio.fernan...@salzburgresearch.at> wrote:

> On 10/02/14 14:49, Daniel Gruno wrote:
>
>> I would suggest you create a new JIRA ticket with this _wish_ and label
>> is as Git+Wilderness, and I'll try to figure out whether we can support
>> this or not.
>>
>
> I'd prefer it does not create new issues in Jira.
>
> What currently it does, post a comment if any issue is referenced, is
> enough. See for example:
>
> https://issues.apache.org/jira/browse/INFRA-7289?
> focusedCommentId=13896626&page=com.atlassian.jira.
> plugin.system.issuetabpanels:comment-tabpanel#comment-13896626



This sounds like exactly what Suresh was asking for.

Re: [VOTE] Graduation of Apache Spark from the Incubator

[Ted Dunning]

+1 (binding)




On Tue, Feb 11, 2014 at 3:52 AM, Alex Karasulu  wrote:

> +1 (binding)
>
>
> On Tue, Feb 11, 2014 at 6:50 AM, Mosharaf Chowdhury <
> mosharafka...@gmail.com
> > wrote:
>
> > +1
> >
> > --
> > Mosharaf Chowdhury
> > http://www.mosharaf.com/
> >
> >
> > On Mon, Feb 10, 2014 at 8:45 PM, Matei Zaharia  > >wrote:
> >
> > > +1
> > >
> > > On Feb 10, 2014, at 8:27 PM, Chris Mattmann 
> wrote:
> > >
> > > > Hi Everyone,
> > > >
> > > > This is a new VOTE to decide if Apache Spark should graduate
> > > > from the Incubator. Please VOTE on the resolution pasted below
> > > > the ballot. I'll leave this VOTE open for at least 72 hours.
> > > >
> > > > Thanks!
> > > >
> > > > [ ] +1 Graduate Apache Spark from the Incubator.
> > > > [ ] +0 Don't care.
> > > > [ ] -1 Don't graduate Apache Spark from the Incubator because..
> > > >
> > > > Here is my +1 binding for graduation.
> > > >
> > > > Cheers,
> > > > Chris
> > > >
> > > >  snip
> > > >
> > > > WHEREAS, the Board of Directors deems it to be in the best
> > > > interests of the Foundation and consistent with the
> > > > Foundation's purpose to establish a Project Management
> > > > Committee charged with the creation and maintenance of
> > > > open-source software, for distribution at no charge to the
> > > > public, related to fast and flexible large-scale data analysis
> > > > on clusters.
> > > >
> > > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> > > > Committee (PMC), to be known as the "Apache Spark Project", be
> > > > and hereby is established pursuant to Bylaws of the Foundation;
> > > > and be it further
> > > >
> > > > RESOLVED, that the Apache Spark Project be and hereby is
> > > > responsible for the creation and maintenance of software
> > > > related to fast and flexible large-scale data analysis
> > > > on clusters; and be it further RESOLVED, that the office
> > > > of "Vice President, Apache Spark" be and hereby is created,
> > > > the person holding such office to serve at the direction of
> > > > the Board of Directors as the chair of the Apache Spark
> > > > Project, and to have primary responsibility for management
> > > > of the projects within the scope of responsibility
> > > > of the Apache Spark Project; and be it further
> > > > RESOLVED, that the persons listed immediately below be and
> > > > hereby are appointed to serve as the initial members of the
> > > > Apache Spark Project:
> > > >
> > > > * Mosharaf Chowdhury 
> > > > * Jason Dai 
> > > > * Tathagata Das 
> > > > * Ankur Dave 
> > > > * Aaron Davidson 
> > > > * Thomas Dudziak 
> > > > * Robert Evans 
> > > > * Thomas Graves 
> > > > * Andy Konwinski 
> > > > * Stephen Haberman 
> > > > * Mark Hamstra 
> > > > * Shane Huang 
> > > > * Ryan LeCompte 
> > > > * Haoyuan Li 
> > > > * Sean McNamara 
> > > > * Mridul Muralidharam 
> > > > * Kay Ousterhout 
> > > > * Nick Pentreath 
> > > > * Imran Rashid 
> > > > * Charles Reiss 
> > > > * Josh Rosen 
> > > > * Prashant Sharma 
> > > > * Ram Sriharsha 
> > > > * Shivaram Venkataraman 
> > > > * Patrick Wendell 
> > > > * Andrew Xia 
> > > > * Reynold Xin 
> > > > * Matei Zaharia 
> > > >
> > > > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Matei Zaharia be
> > > > appointed to the office of Vice President, Apache Spark, to
> > > > serve in accordance with and subject to the direction of the
> > > > Board of Directors and the Bylaws of the Foundation until
> > > > death, resignation, retirement, removal or disqualification, or
> > > > until a successor is appointed; and be it further
> > > >
> > > > RESOLVED, that the Apache Spark Project be and hereby is
> > > > tasked with the migration and rationalization of the Apache
> > > > Incubator Spark podling; and be it further
> > > >
> > > > RESOLVED, that all responsibilities pertaining to the Apache
> > > > Incubator Spark podling encumbered upon the Apache Incubator
> > > > Project are hereafter discharged.
> > > >
> > > > 
> > > >
> > > >
> > > >
> > >
> > >
> >
>
>
>
> --
> Best Regards,
> -- Alex
>

Re: [VOTE] Release Apache Storm 0.9.1-incubating

[Ted Dunning]

+1 (binding)




On Sat, Feb 15, 2014 at 11:43 AM, Joseph Schaefer wrote:

> I would say that is the right approach, and
> that this vote should continue on.
>
> On Feb 15, 2014, at 2:34 PM, P. Taylor Goetz  wrote:
>
> > Hi Joseph,
> >
> > Thank you very much for the clarification.
> >
> > After checking the history of the NOTICE file [1], it turns out that
> those entries were made by Nathan and a Yahoo! employee.
> >
> > (I thought I had added Nathan to the file, but after checking the
> history, realized I didn’t, so there is a commit rollback in the history).
> >
> > I have reached out to both of them with a request to remove those
> entries.
> >
> > I’m assuming we can continue with the vote without having to start over
> at this point?
> >
> > Thanks again for your input.
> >
> > - Taylor
> >
> > On Feb 15, 2014, at 1:07 PM, Joseph Schaefer 
> wrote:
> >
> >> It means that unless Nathan Marz and an Yahoo! employee
> >> added those items to the NOTICE, you can remove them.  But
> >> if they did, than either Nathan Marz or a Y! employee should
> >> be asked to.
> >>
> >> In terms of being a release blocker, I’d say not.  If you fix
> >> this in HEAD that should be sufficient to continue.
> >>
> >> On Feb 15, 2014, at 1:02 PM, P. Taylor Goetz  wrote:
> >>
> >>> With the exception of some JavaScript code [1], all source code files
> use the Apache v2 license.
> >>>
> >>> Prior to entering the incubator, the project used the Eclipse Public
> License. In the incubator, all source files that did not have a license
> header already (the JavaScript files mentioned above), were updated with
> the Apache v2 license header.
> >>>
> >>> So from a LICENSE/NOTICE file perspective, where does that put us?
> >>>
> >>> -Taylor
> >>>
>  On Feb 15, 2014, at 12:10 PM, sebb  wrote:
> 
> > On 15 February 2014 16:44, P. Taylor Goetz 
> wrote:
> > Hi sebb,
> >
> > What specifically needs to be done to correct the NOTICE file?
> >
> > Should the references to Nathan Marz and Yahoo! be removed?
> 
>  As I already wrote, this depends on the exact license(s) of the
>  file(s) involved.
> 
> > Thanks,
> >
> > Taylor
> >
> >> On Feb 14, 2014, at 12:44 PM, sebb  wrote:
> >>
> >> If the code has not changed substantially in 2014 then the date can
> >> stay as 2013.
> >>
> >> As to the attribution, that depends on the _exact text_ of the
> license
> >> provided with the files.
> >> The license(s) should also be included in the LICENSE file.
> >>
> >> Note that attributions in the NOTICE file must be passed to
> downstream
> >> consumers so it is important not to include anything that is not
> >> required.
> >>
> >>
> >>> On 14 February 2014 17:31, Suresh Srinivas 
> wrote:
> >>> +1 (binding) from me.
> >>>
> >>> Sebb, can you please answer the question related to the NOTICE
> file. I
> >>> think while it may not be necessary to call out individual or
> companies
> >>> contributing large portions of the code, it should not block this
> release
> >>> and can be addressed later.
> >>>
> >>>
>  On Thu, Feb 13, 2014 at 7:49 AM, P. Taylor Goetz <
> ptgo...@gmail.com> wrote:
> 
>  Thanks for the input!
> 
>  The majority of the codebase was originally developed by Nathan
> Marz, and
>  it includes significant contributions from Yahoo!.
> 
>  The project was originally licensed under the Eclipse Public
> License, but
>  has not transitioned to the Apache v2 license.
> 
>  If putting those attributions in the NOTICE file is not the
> correct thing
>  to do, please let me know the right way to handle it.
> 
>  It was still 2013 when I last updated the NOTICE file. I'm not
> sure if
>  that is a blocker for release or not.
> 
>  - Taylor
> 
>  On Feb 13, 2014, at 5:59 AM, sebb  wrote:
> 
>  On 13 February 2014 07:00, P. Taylor Goetz 
> wrote:
> 
>  This is a call for a vote to release Apache Storm (incubating)
> version
>  0.9.1. This will be the first release of Apache Storm.
> 
>  A vote was held on the developer mailing list, and passed with 9
> +1 votes
>  (6
>  binding, 3 non-binding), no 0 votes, and no -1 votes.
> 
>  Release Vote:
> 
> 
> http://mail-archives.apache.org/mod_mbox/incubator-storm-dev/201402.mbox/%3c44c5baad-0fd8-454c-84d7-c8da92442...@gmail.com%3e
> 
>  Release Vote Result:
> 
> 
> http://mail-archives.apache.org/mod_mbox/incubator-storm-dev/201402.mbox/%3c3a207f1c-3b07-4029-93d4-87abeb412...@gmail.com%3e
> 
> 
>  The tag to be voted upon is v0.9.1-incubating:
> 
> 
> 
> https://git-wip-us.apache.org/repos/asf?p=incubator-storm.git;a=tree;

Re: How to handle "module" contributions

[Ted Dunning]

The basic idea is that you have to have the right to incorporate the code
and be able to demonstrate that right.

For example #1, you can switch your contributions to ASL2 and be good, but
you may have problems with the contributions of the others unless the
contributions are trivial.

For example #2, it is typically necessary to get a specific grant licensing
the code to Apache.  If the corporate entity were to relicense the code
being donated under ASL2, that would suffice, but a letter indicating
intent to donate would be nice.

Others may have additional opinions so don't assume my answer is definitive.




On Mon, Feb 17, 2014 at 3:04 PM, P. Taylor Goetz  wrote:

> My apologies if this has been asked before or is well documented
> somewhere. If it is I couldn't find it.
>
> What is the process for handling "contrib module" code donations from an
> IP clearance perspective?
>
> Example #1 (https://github.com/ptgoetz/storm-jms)
> An individual (me in this case) wishes to donate code that is licensed
> under the EPL, and has had a few contributions (no CLAs). Is switching to
> Apache v2 license and adding license headers all that would be necessary?
>
> Example #2 (https://github.com/hmsonline/storm-cassandra)
> Same story as the previous example, except this time it is a corporate
> entity. The project has transitioned to the Apache license.
>
> In each case, what is necessary to incorporate the code into an incubator
> project?
>
> (Sorry for the double post, I hit send accidentally.)
>
> -Taylor

Re: How to handle "module" contributions

[Ted Dunning]

yeah.

What Joe said.


On Mon, Feb 17, 2014 at 4:27 PM, Joseph Schaefer wrote:

> Judgement call depending on what you might
> consider a reasonable size for a minor fix
> versus an independent work (e.g. new module).
> The larger the patch the more likely you should
> consider having the author file some paperwork with
> Apache to cover the contribution.
>
> HTH
>
>
> On Feb 17, 2014, at 7:20 PM, P. Taylor Goetz  wrote:
>
> > Thanks Ted.
> >
> > Regarding contributions, if someone contributes (e.g. A pull request) to
> a project with an established license, couldn't that be considered an
> implicit grant of rights unless otherwise specified (e.g. License headers)?
>

Mentor needs wiki permissions

[Ted Dunning]

Sebastian Schelter is a new mentor for Drill and needs wiki write
permissions to sign off on monthly reports.

At his request, I have marked the report for this month, but he would like
to be able to do it himself before the next report.

Can somebody help by giving him permissions?  I copied him so you have his
apache email address.

Re: Mentor needs wiki permissions

[Ted Dunning]

Thanks Nick.

That's why I copied him.


On Tue, Mar 11, 2014 at 10:20 AM, Nick Burch  wrote:

> On Tue, 11 Mar 2014, Ted Dunning wrote:
>
>> Sebastian Schelter is a new mentor for Drill and needs wiki write
>> permissions to sign off on monthly reports.
>>
>> Can somebody help by giving him permissions?  I copied him so you have
>> his apache email address.
>>
>
> The important piece of information isn't his email address, it's his wiki
> username - permissions are granted based on usernames not emails
>
> Nick
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [PROPOSAL] Stratosphere

[Ted Dunning]

eral existing Apache projects: Apache
> HBase for storage, Apache Hadoop (HDFS for storage, YARN for resource
> management, and Stratosphere contains a generic wrapper for Hadoop
> MapReduce input formats), and Apache Avro (for serialization). Stratosphere
> uses Apache Maven and Apache Commons libraries internally. Stratosphere can
> be a great compilation target for Apache Pig and Apache Hive, although such
> functionality is not yet implemented.
>
> Stratosphere is also related with several projects undergoing incubation
> in the Apache Incubation project, such as Tez, Drill, and Spark
> (graduated). While all these projects target sufficiently different spaces
> and have different architectures, it would be interesting to explore code
> reuse possibilities. For example, we are currently basing our design for
> compiling SQL to Stratosphere on the Optiq library, also used by Apache
> Drill.
>
> === An Excessive Fascination with the Apache Brand ===
> We believe that the Apache brand will help us attract contributors to
> Stratosphere, by giving us a well-defined, transparent development process
> under a known brand. At the same time, Stratosphere already has a healthy
> community and current funding guarantees the further codebase development
> and growth of the project for the next 3-5 years. The reason for this
> proposal is not to gain publicity, but to further strengthen the longevity
> of the project as explained in the Rationale section.
>
> == Documentation ==
>  * [[https://stratosphere.eu|Project website]]
>  * [[http://stratosphere.eu/docs/0.4/|Documentation]]
>  * [[https://github.com/stratosphere/stratosphere|Codebase]]
>  * [[https://groups.google.com/forum/#!forum/stratosphere-dev|Mailinglist]]
>
> == Initial Source ==
> Stratosphere is hosted on [[
> https://github.com/stratosphere/stratosphere|GitHub]] . This is the
> codebase that we will migrate to the Apache Foundation. The code was
> previously hosted on a TU Berlin’s own git infrastructure. It has always
> been Apache 2.0 licensed.
>
> === Source and Intellectual Property Submission Plan ===
> All initial and past committers will sign a CLA with the ASF while the
> incubator proposal for Stratosphere is being discussed. All organizations
> that have employed Stratosphere contributors in the past will sign a SGA.
> Current contributors will sign a CCLA. All major contributors are still
> active in the project.
>
> === External Dependencies ===
> All critical dependencies are, to the extend of our knowledge, from other
> Apache projects. These include Apache Hadoop (for YARN and HDFS) and some
> libraries (log4j, commons codec, junit and more). Our web frontend uses
> some MIT-licensed JavaScript libraries.
>
> == Required Resources ==
>
> === Mailing list ===
> We will migrate our mailing lists to the following:
>  * us...@stratosphere.incubator.apache.org
>  * d...@stratosphere.incubator.apache.org
>  * priv...@stratosphere.incubator.apache.org
>  * comm...@stratosphere.incubator.apache.org
>
> === Source control ===
> We would like to use Git for source control and enable GitHib mirroring
> functionality, where code reviews on GitHub are automatically
> forwarded to the developer mailing list. (See also: [[
> https://blogs.apache.org/infra/entry/improved_integration_between_apache_and]
> ])
>
>
> === Issue tracking ===
> We are currently using GitHub for issue tracking. We request an
> Apache-hosted JIRA, and we will import existing issues there.
>
>
> == Initial committers ==
>  * Stephan Ewen - stephan.e...@tu-berlin.de
>  * Fabian Hueske - fabian.hue...@tu-berlin.de
>  * Daniel Warneke - warn...@posteo.de
>  * Robert Metzger - metrob...@gmail.com
>  * Ufuk Celebi - u.cel...@fu-berlin.de
>  * Aljoscha Krettek - aljoscha.kret...@gmail.com
>  * Kostas Tzoumas - kostas.tzou...@tu-berlin.de
>  * Sebastian Schelter  - s...@apache.org
>
> === Affiliations ===
>  * Stephan Ewen (TU Berlin)
>  * Fabian Hueske (TU Berlin)
>  * Daniel Warneke (Amadeus IT Group)
>  * Robert Metzger (TU Berlin)
>  * Ufuk Celebi (FU Berlin)
>  * Aljoscha Krettek (TU Berlin)
>  * Kostas Tzoumas (TU Berlin)
>  * Sebastian Schelter (TU Berlin)
>
> == Sponsors ==
> === Champion ===
> Alan Gates (ga...@apache.org)
>
> === Nominated Mentors ===
>  * Sean Owen (sro...@apache.org) (Note: Sean is an Apache member but not
> currently on the IPC, he will need to request IPMC membership)
>  * Ted Dunning (tdunn...@apache.org)
>  * Owen O'Malley (omal...@apache.org)
>
> === Sponsoring Entity ===
> The Apache Incubator
>
>
> --
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity to
> which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [PROPOSAL] Stratosphere

[Ted Dunning]

On Sun, Mar 30, 2014 at 10:26 AM, Sebastien Goasguen wrote:

> Maybe 'stratosphere' is too generic to be able to get trademarks
> established down the road.
>

That is a significant issue that will need to dealt with during incubation.

Good trademarks are very difficult to come up with.

Re: [DISCUSS] Meerkat as a Hama sub-module or sub-project

[Ted Dunning]

Edward,

Sub-projects are generally frowned on.  Incubator projects can graduate
eventually to a top-level project, but starting a project as a sub is not
so good.  The incubator docs on this are pretty good reading.

But if the committer community for your real-time BSP is (or can be) the
same as the committer community for Hama itself, you might want to just
fold this new code directly into Hama itself.  No need in that case for a
separate project.

If the committer community is very different, then a separate project is
warranted.

I don't think that the Hama development is such a high bandwidth thing that
splitting is required.  To my mind that says that joining groups together
is better than breaking them apart.  Together, the two efforts can feed off
each other.  Apart, they could each run down due to lack of interest.

You will know much better than any of us the details of your communities.





On Mon, Apr 28, 2014 at 4:23 AM, Edward J. Yoon wrote:

> Hi guys,
>
> As some people already might know, I'm recently working on real-time
> data processing project on top of Hama BSP model, called Meerkat[1]
> (currently only few developers (from two organizations, Kakaotalk and
> DataSayer) are involved in this project).
>
> According to our internal study, Storm-like DAG-style and
> fault-tolerant streaming processing framework can be implemented on
> top of Hama BSP model. And, furthermore, we're thinking, it may be
> possible to connect to other BSP applications using some smart input
> and output formats in the future e.g., streaming graph or learning BSP
> applications. Thus, we believe that we may be able to have an
> next-generation architecture that processes and analyzes the data
> rapidly in real-time, beyond complex old-style data collecting,
> storing, ordering, processing, and analyzing architecture.
>
> Does it make sense to you? If so, I'd like to start to move from
> github to ASF soon, although this is very *early* stage. Because, it's
> highly related with Apache Hama and others. Hama sub-module or
> sub-project, (or Apache incubator?). Which is best you think?
>
> I'm also CC'ing general@i.a.o to see more feedbacks (from Apache big
> data OSS communities).
>
> 1. https://github.com/datasayer/meerkat
>
> --
> Best Regards, Edward J. Yoon
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [PROPOSAL] Optiq

[Ted Dunning]

e resides in three projects, all hosted on github:
>
>  * https://github.com/julianhyde/optiq
>  * https://github.com/julianhyde/optiq-csv
>  * https://github.com/julianhyde/linq4j
>
> === Source and Intellectual Property Submission Plan ===
>
> The initial codebase is already distributed under the Apache 2.0 License.
> The owners of the IP have indicated willingness to sign the SGA.
>
> === External Dependencies ===
>
> Optiq and Linq4j have the following external dependencies.
>
>  * Java 1.6, 1.7 or 1.8
>  * Apache Maven, Commons
>  * JavaCC (BSD license)
>  * Sqlline 1.1.6 (BSD license)
>  * Junit 4.11 (EPL)
>  * Janino (BSD license)
>  * Guava (Apache 2.0 license)
>  * Eigenbase-resgen, eigenbase-xom, eigenbase-properties (Apache 2.0
> license)
>
> Some of Optiq's adapters (optiq-csv, optiq-mongodb, optiq-spark,
> optiq-splunk) are currently developed alongside core Optiq, and have the
> following additional dependencies:
>
>  * Open CSV 2.3 (Apache 2.0 license)
>  * Apache Incubator Spark
>  * Mongo Java driver (Apache 2.0 license)
> Upon acceptance to the incubator, we would begin a thorough analysis of all
> transitive dependencies to verify this information and introduce license
> checking into the build and release process by integrating with Apache Rat.
>
> === Cryptography ===
>
> Optiq will eventually support encryption on the wire. This is not one of
> the initial goals, and we do not expect Optiq to be a controlled export
> item due to the use of encryption.
>
> == Required Resources ==
>
> === Mailing Lists ===
>
>  * priv...@optiq.incubator.apache.org
>  * d...@optiq.incubator.apache.org (will be migrated from
> optiq-...@googlegroups.com)
>  * comm...@optiq.incubator.apache.org
>
> === Source control ===
>
> The Optiq team would like to use git for source control, due to our current
> use of git/github. We request a writeable git repo git://
> git.apache.org/incubator-optiq, and mirroring to be set up to github
> through INFRA.
>
> === Issue Tracking ===
>
> Optiq currently uses the github issue tracking system associated with its
> github repo: https://github.com/julianhyde/optiq/issues. We will migrate
> to
> the Apache JIRA: http://issues.apache.org/jira/browse/OPTIQ.
>
> == Initial Committers ==
>
>  * Julian Hyde (jhyde at apache dot org)
>  * Jacques Nadeau (jacques at apache dot org)
>  * James R. Taylor (jamestaylor at apache dot org)
>  * Chris Wensel (cwensel at apache dot org)
>
> === Affiliations ===
>
> The initial committers are employees of Concurrent, Hortonworks, MapR and
> Salesforce.com.
>
>  * Julian Hyde (Hortonworks)
>  * Jacques Nadeau (MapR Technologies)
>  * James R. Taylor (Salesforce.com)
>  * Chris Wensel (Concurrent)
>
> == Sponsors ==
>
> === Champion ===
>
>  * Ashutosh Chauhan (hashutosh at apache dot org)
>
> === Nominated Mentors ===
>
>  * Ted Dunning (tdunning at apache dot org) - Chief Application Architect
> at MapR Technologies; committer for Lucene, Mahout and ZooKeeper.
>  * Alan Gates (gates at apache dot org) - Architect at Hortonworks;
> committer for Pig, Hive and others.
>  * Steven Noels (stevenn at apache dot org) - Chief Technical Officer at
> NGDATA; committer for Cocoon and Forrest, mentor for Phoenix.
>
> === Sponsoring Entity ===
>
> The Apache Incubator.
>

Re: [PROPOSAL] Optiq

[Ted Dunning]

t;
> As mentioned in the Alignment section, Optiq is being used by Apache Hive
> and Apache Drill, and has adapters for Apache Phoenix and Apache Spark.
> Optiq often operates on data in a Hadoop environment, so collaboration with
> other Hadoop projects is desirable and highly likely.
>
> === An Excessive Fascination with the Apache Brand ===
>
> Optiq solves a real problem, as evidenced by its take-up by other projects.
> This proposal is not for the purpose of generating publicity. Rather, the
> primary benefits to joining Apache are those outlined in the Rationale
> section.
>
> == Documentation ==
>
> Additional documentation for Optiq may be found on its github site:
>
>  * [[https://github.com/julianhyde/optiq/blob/master/README.md|Overview]]
>  * [[
> https://github.com/julianhyde/optiq-csv/blob/master/TUTORIAL.md|Tutorial]]
>  * [[https://github.com/julianhyde/optiq/blob/master/HOWTO.md|HOWTO]]
>  * [[
> https://github.com/julianhyde/optiq/blob/master/REFERENCE.md|Referenceguide
> ]]
>
> === Presentation: ===
>
>  *[[
>
> https://github.com/julianhyde/share/blob/master/slides/optiq-richrelevance-2013.pdf?raw=true|
> SQL on Big Data using Optiq]]
> == Initial Source ==
>
> The initial code codebase resides in three projects, all hosted on github:
>
>  * https://github.com/julianhyde/optiq
>  * https://github.com/julianhyde/optiq-csv
>  * https://github.com/julianhyde/linq4j
>
> === Source and Intellectual Property Submission Plan ===
>
> The initial codebase is already distributed under the Apache 2.0 License.
> The owners of the IP have indicated willingness to sign the SGA.
>
> === External Dependencies ===
>
> Optiq and Linq4j have the following external dependencies.
>
>  * Java 1.6, 1.7 or 1.8
>  * Apache Maven, Commons
>  * JavaCC (BSD license)
>  * Sqlline 1.1.6 (BSD license)
>  * Junit 4.11 (EPL)
>  * Janino (BSD license)
>  * Guava (Apache 2.0 license)
>  * Eigenbase-resgen, eigenbase-xom, eigenbase-properties (Apache 2.0
> license)
>
> Some of Optiq's adapters (optiq-csv, optiq-mongodb, optiq-spark,
> optiq-splunk) are currently developed alongside core Optiq, and have the
> following additional dependencies:
>
>  * Open CSV 2.3 (Apache 2.0 license)
>  * Apache Incubator Spark
>  * Mongo Java driver (Apache 2.0 license)
> Upon acceptance to the incubator, we would begin a thorough analysis of all
> transitive dependencies to verify this information and introduce license
> checking into the build and release process by integrating with Apache Rat.
>
> === Cryptography ===
>
> Optiq will eventually support encryption on the wire. This is not one of
> the initial goals, and we do not expect Optiq to be a controlled export
> item due to the use of encryption.
>
> == Required Resources ==
>
> === Mailing Lists ===
>
>  * priv...@optiq.incubator.apache.org
>  * d...@optiq.incubator.apache.org (will be migrated from
> optiq-...@googlegroups.com)
>  * comm...@optiq.incubator.apache.org
>
> === Source control ===
>
> The Optiq team would like to use git for source control, due to our current
> use of git/github. We request a writeable git repo git://
> git.apache.org/incubator-optiq, and mirroring to be set up to github
> through INFRA.
>
> === Issue Tracking ===
>
> Optiq currently uses the github issue tracking system associated with its
> github repo: https://github.com/julianhyde/optiq/issues. We will migrate
> to
> the Apache JIRA: http://issues.apache.org/jira/browse/OPTIQ.
>
> == Initial Committers ==
>
>  * Julian Hyde (jhyde at apache dot org)
>  * Jacques Nadeau (jacques at apache dot org)
>  * James R. Taylor (jamestaylor at apache dot org)
>  * Chris Wensel (cwensel at apache dot org)
>
> === Affiliations ===
>
> The initial committers are employees of Concurrent, Hortonworks, MapR and
> Salesforce.com.
>
>  * Julian Hyde (Hortonworks)
>  * Jacques Nadeau (MapR Technologies)
>  * James R. Taylor (Salesforce.com)
>  * Chris Wensel (Concurrent)
>
> == Sponsors ==
>
> === Champion ===
>
>  * Ashutosh Chauhan (hashutosh at apache dot org)
>
> === Nominated Mentors ===
>
>  * Ted Dunning (tdunning at apache dot org) - Chief Application Architect
> at MapR Technologies; committer for Lucene, Mahout and ZooKeeper.
>  * Alan Gates (gates at apache dot org) - Architect at Hortonworks;
> committer for Pig, Hive and others.
>  * Steven Noels (stevenn at apache dot org) - Chief Technical Officer at
> NGDATA; committer for Cocoon and Forrest, mentor for Phoenix.
>
> === Sponsoring Entity ===
>
> The Apache Incubator.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [PROPOSAL] Optiq

[Ted Dunning]

On Thu, May 1, 2014 at 10:19 PM, Kasper Sørensen <
kasper.soren...@humaninference.com> wrote:

> - Can you explain or link to more information about the type inference you
> mention?
>

The type inferencing is used by Drill.

The problem is that strong typing is normally required to parse SQL
statements.  If you don't even yet know what columns exist, parsing a query
is difficult for normal SQL parsers. Generating good code for such
situations has to be delayed until type information is available.

See

http://tnachen.wordpress.com/2013/11/05/lifetime-of-a-query-in-drill-alpha-release/

https://docs.google.com/document/d/1QTL8warUYS2KjldQrGUse7zp8eA72VKtLOHwfXy6c7I/edit

Re: [VOTE] Accept Optiq into the incubator

[Ted Dunning]

On Fri, May 9, 2014 at 8:03 PM, Ashutosh Chauhan wrote:

> [X] +1 Accept Optiq into the Incubator
> [ ] +0 Indifferent to the acceptance of Stratosphere
> [ ] -1 Do not accept Optiq because ...
>

The appearance of Stratosphere is a clear typo.

I still vote to accept.

Re: Shepherding Summary - June 2014

[Ted Dunning]

I am working with the Drill team to help them get the report in.  The
community is very active with >200 Jiras reported and fixed in the last 30
days.

The problem with the report is likely due to the fact that the community
member who has been creating the reports (Ellen Friedman) has been diverted
by other (paying) gigs lately. Several others have volunteered to get the
report done but they didn't have much warning.



On Sun, Jun 8, 2014 at 5:43 PM, John D. Ament 
wrote:

> Hi all
>
> See below for the shepherd reports.  I've put some additional comments in.
>
> Drill/Konstantin Boudnik
>
> Shepherd/Mentor notes:
>
>   In the month of June the project's dev@ list was light on the traffc
> - 86 msgs vs 1183 in May. Traffic consists mostly from the JIRA
> notifications and review requests. I am not entirely sure what is the
> cause of the lowest activity since the end of 2012.
>
>   June report to the board hasn't been sent on time either.
>
>
> Flink/Konstantin Boudnik
>
> Shepherd/Mentor notes:
>
>   Mailing list in June is very light on the traffic and only covering
> the topic of the project's name change. Some of the mentors are active
> on the list and helping community. No visible issues.
>
>
> Cos,
>
>
> Thanks for both of these reports! Just to point out, the June report
> covers 1/May - 31/May.  We’re only 8 days into June… 86 msgs isn’t bad
> for 8 days in :-)  I'm not sure if you want to rephrase based on this,
> I made the same mistake last month w/ the board report.
>
>
> Kalumet/Justin Mclean
>
>
> Shepherd/Mentor notes:
>
>   Podling may be in a little trouble. Failed to report this month, mailing
>
>   list traffic and commits at a very low level. A mentor is still active
>
>   but looks likes like the last release candidate (October 2013) wasn't
>
>   voted on by the IPMC and a new release candidate hasn't been created.
>
>   Last report talked about graduation so perhaps they just need some help
>
>   in getting past the final hurdle?
>
>
> Justin,
>
>
> Thanks for bringing this up.  Since they’re moving to monthly, we’ll
> monitor and see if things improve in the next couple of months.
>
>
> Storm/John D. Ament
>
> Storm is showing a lot of progress and growth.  They have a lot of
> activity on JIRA and mailing lists, and are generally in good shape.
>
>
>
> Please be advised that the following podlings have not reported yet,
> and will be moved to monthly:
>
> Brooklyn
>
> DeviceMap
>
> Drill
>
> Kalumet
>
> S4
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Flink's report

[Ted Dunning]

Also, with a very new project, it is important to know that they have done
releases before coming to Apache.


On Sun, Jun 8, 2014 at 6:46 PM, Marvin Humphrey 
wrote:

> On Sun, Jun 8, 2014 at 6:08 PM, John D. Ament 
> wrote:
>
> > If anyone from Flink can answer...  as well as IPMC members.
> >
> > You have this listed in your report:
> >
> > Date of last release:
> >
> >   2014-05-31 (no incubator release yet)
> >
> > I don't think we can list non-incubator releases in the report.
>
> It's true that that pre-Apache releases are not what the IPMC or the
> Board is looking for, and though it's not a big deal it's probably
> better not to list such releases in the future.  But at least Flink
> made it clear that they weren't talking about an Apache release.
>
> My vote would be to keep it in because I think we should leave the
> Podling's work intact if we can.
>
> Marvin Humphrey
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Board Report Reminder

[Ted Dunning]

The Drill group just produced a report that I posted and signed off.

Is this too late to include?




On Sun, Jun 8, 2014 at 1:14 PM, Konstantin Boudnik  wrote:

> I am going to post my Drill Shepherd review to the June2014 page in a
> moment,
> but I wanted to reflect here that Drill project didn't reported after I
> have
> nudged them on the dev@ list and Ted Dunning forwarded the reminder from
> the
> board.
>
> Cos
>
> On Sat, Jun 07, 2014 at 10:50AM, John D. Ament wrote:
> > Hi all
> >
> > Don't forget, board reports were due on June 04.  Shepherd reports are
> > due tomorrow.
> >
> > The following podlings are considered to not have reported this month,
> thus far:
> >
> > Brooklyn
> > DeviceMap
> > Drill
> > Kalumet
> > MRQL
> > S4
> > Sentry
> > Tajo
> >
> > John
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
>

Re: DRAFT Board Report June 2014

[Ted Dunning]

Drill should probably be in that category as well.

300 issues resolved last 30 days, lots of contributors.

They have about as much stuff happening as HBase.



On Tue, Jun 10, 2014 at 6:13 PM, John D. Ament 
wrote:

> Marvin,
>
> What do you think about listing storm under ready to graduate instead
> of community growth?
>
> John
>
> On Tue, Jun 10, 2014 at 9:04 PM, Marvin Humphrey 
> wrote:
> > On Tue, Jun 10, 2014 at 9:35 AM, Joe Brockmeier  wrote:
> >> I'm going to put this up on the wiki, please let me know if there are
> >> any issues.
> >
> > The editorial copy looks good to me!
> >
> > It seems as though the summary may have been submitted in an
> > unfinished state -- many podlings were missing and some that
> > weren't in this month's report were present.  I've contributed a fix:
> >
> > https://wiki.apache.org/incubator/June2014?action=diff&rev1=54&rev2=55
> >
> > 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: DRAFT Board Report June 2014

[Ted Dunning]

On Tue, Jun 10, 2014 at 6:33 PM, John D. Ament 
wrote:

> On Tue, Jun 10, 2014 at 9:28 PM, Ted Dunning 
> wrote:
> > Drill should probably be in that category as well.
> >
> > 300 issues resolved last 30 days, lots of contributors.
> >
> > They have about as much stuff happening as HBase.
> >
>
> They're already there, but generally agreed.  I am concerned that
> their report came late though.
>

That's fair.

The problem was transition from one person to another.

Re: Do we still need release metrics as part of the report?

[Ted Dunning]

On Wed, Jun 11, 2014 at 1:38 PM, Roman Shaposhnik  wrote:

> One thing that I noticed in the report is that the detailed
> metrics around releases are missing. Do folks think
> there's a value in having them?
>

What metrics do you mean?

The metrics that really matter are up-take of the new version.  We can't
really see that.

The metrics that are easy to get (LoC and such) are generally pretty silly
and vacuous.

Re: Do we still need release metrics as part of the report?

[Ted Dunning]

Good point.  Thanks for clarifying.

Yes.  I think that those metrics are an excellent measure of community
health.



On Wed, Jun 11, 2014 at 1:55 PM, Roman Shaposhnik  wrote:

> On Wed, Jun 11, 2014 at 1:50 PM, Ted Dunning 
> wrote:
> > On Wed, Jun 11, 2014 at 1:38 PM, Roman Shaposhnik 
> wrote:
> >
> >> One thing that I noticed in the report is that the detailed
> >> metrics around releases are missing. Do folks think
> >> there's a value in having them?
>
> Here are the metrics that were provided in the May report:
>
>  It took 2-13 days for the third IPMC vote to arrive.
>
> Release   VOTE start  Third IMPC +1  Days
> -
> phoenix-3.0.0-incubating  April 01April 03   3
> phoenix-4.0.0-incubating  April 01April 03   3
> tez-0.4.0-incubating  April 01April 04   4
> hdt-0.0.1.incubating  April 18May 01 13
> apache-vxquery-0.3-incubating April 15April 17   3
> twill-0.2.0-incubatingApril 03April 07   4
> metamodel-4.1.0-incubatingMay 03  May 04 2
>
>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Retire the S4 podling

[Ted Dunning]

+1 for retirement (binding)




On Fri, Jun 13, 2014 at 1:23 PM, John D. Ament 
wrote:

> +1 Please go ahead and retire from the incubator. (binding)
>
> On Fri, Jun 13, 2014 at 2:36 PM, Joe Brockmeier  wrote:
> > Hi all,
> >
> > Per recent discussions on general@[1] and s4-dev@ [2], I went ahead and
> > called for a VOTE on the S4 dev@ mailing list [3] about retiring the
> > podling. That VOTE has passed with no -1s and 4 (binding) +1s from the
> > podling PMC/committers. (S4 only has committers, and doesn't distinguish
> > between PPMC/committer.)
> >
> > We didn't get a weigh-in from all mentors/PPMC on the retirement VOTE,
> > so I'm going ahead and asking for a vote here.
> >
> > This VOTE will be open for at least 72 hours. Please indicate (binding)
> > or (non-binding) when casting your VOTE.
> >
> > +1 [ ] Yes, I am in favor of retiring S4 from the Apache Incubator.
> > +0 [ ]
> > -1 [ ] No, I am not in favor of retiring S4 because...
> >
> > Note that we have one IPMC vote from Patrick already.
> >
> > [1] http://s.apache.org/7Gz
> > [2] http://s.apache.org/ig
> > [3] http://s.apache.org/OAU
> > --
> > Joe Brockmeier
> > j...@zonker.net
> > Twitter: @jzb
> > http://www.dissociatedpress.net/
> >
> > -
> > 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] Retire the S4 podling

[Ted Dunning]

This is a vote thread, not a discussion thread.  Read the earlier messages
which are included in this thread for more context.


On Mon, Jun 16, 2014 at 2:02 PM, abiola balogun  wrote:

> Why do u say so and who are you?
>
> Sent from my iPhone
>
> > On Jun 16, 26 Heisei, at 8:18, abiola balogun  wrote:
> >
> > Retire the S4 polling
> >
> > Sent from my iPhone
> >
> >> On Jun 15, 26 Heisei, at 16:58, Mark Struberg 
> wrote:
> >>
> >> +1 (binding)
> >>
> >> LIeGrue,
> >> strub
> >>
> >>
> >> On Saturday, 14 June 2014, 16:10, Dave Fisher  wrote:
> >>
> >>
> >>>
> >>>
> >>> +1, binding.
> >>>
> >>> Sent from my iPhone
> >>>
> > On Jun 13, 2014, at 3:18 PM, Roman Shaposhnik 
> wrote:
> >
> > On Fri, Jun 13, 2014 at 11:36 AM, Joe Brockmeier 
> wrote:
> > Hi all,
> >
> > Per recent discussions on general@[1] and s4-dev@ [2], I went ahead
> and
> > called for a VOTE on the S4 dev@ mailing list [3] about retiring the
> > podling. That VOTE has passed with no -1s and 4 (binding) +1s from
> the
> > podling PMC/committers. (S4 only has committers, and doesn't
> distinguish
> > between PPMC/committer.)
> >
> > We didn't get a weigh-in from all mentors/PPMC on the retirement
> VOTE,
> > so I'm going ahead and asking for a vote here.
> >
> > This VOTE will be open for at least 72 hours. Please indicate
> (binding)
> > or (non-binding) when casting your VOTE.
> >
> > +1 [ ] Yes, I am in favor of retiring S4 from the Apache Incubator.
> > +0 [ ]
> > -1 [ ] No, I am not in favor of retiring S4 because...
> 
>  +1 (binding)
> 
>  Thanks,
>  Roman.
> 
>  -
>  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
> >>>
> >>>
> >>>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Incubator exit criteria

[Ted Dunning]

On Wed, Jun 18, 2014 at 11:14 PM, Roman Shaposhnik  wrote:

> To this end, I'd like to prose a very simplistic criteria
> for a potential retirement from the incubator: unless both
> of of the following applies project get put to a retirement
> IPMC vote:
>* there has been a release in the past 12 months
>* there has been a bona-fine change to a community
>   structure in the past 12 months
>

Why the shorter list relative to the one that came out earlier?  It had
email activity and some other criteria that seemed plausible.

Re: [DISCUSS] Incubator exit criteria

[Ted Dunning]

On Wed, Jun 18, 2014 at 11:46 PM, Alexander Broekhuis  wrote:

> as the retirement criteria would IMO be too harsh for Celix when we
> started.
>

In a similar vein, Drill currently has about the same number of commits and
mail messages as Hive does, but hasn't had a release in a while.  They have
resolved >300 significant JIRA in the last 30 days alone.  I don't know
what bonafide change in the community is, but one could argue that just
adding committers isn't that.

A release is coming there, but I think that the criteria shouldn't need
special exceptional arguments.  The commit rate and JIRA resolution rates
are good distinctive marks that avoid this.

Re: Tez graduation [Was: Request for mentor assessment]

[Ted Dunning]

I think that this is a serious problem for Tez graduation.  So far, Tez has
been essentially a one-company show and essentially all of the participants
are there because of their day jobs.

It doesn't seem like it has to be that way, but it also doesn't seem like
there are organic drives to push it a different direction.




On Fri, Jun 20, 2014 at 8:02 PM, Konstantin Boudnik  wrote:

> Ok, I've reached out to the Tez project and it seems that they are wokring
> w/
> Chris Mattmann's on the graduation process (per an email exchange
> http://s.apache.org/K7g). What has caught my attention is the PPMC
> composition
> which is pretty much uniformly represented by a group with the same
> affiliation. Given that this page
> https://tez.incubator.apache.org/team-list.html
> is up to date.
>
> If I am reading
> https://incubator.apache.org/guides/graduation.html#community
> right, the PPMC and committers composition should be diversified. Is it a
> concern for graduation from the IPMC standpoint of view?
>
> Regards,
>   Cos
>
> On Mon, Jun 16, 2014 at 06:54PM, Chris Douglas wrote:
> > Tez is ready to graduate. Cos, if you can help us manage that process,
> > it'd certainly be appreciated. -C
> >
> > On Mon, Jun 16, 2014 at 12:53 PM, Konstantin Boudnik 
> wrote:
> > > I share the sentiment with NPanday - doesn't seem like anything is
> happening
> > > there really.
> > >
> > > If it of an interest to the incubator, I will volunteer to help
> mentoring Tez.
> > >
> > > Cos
> > >
> > >
> > > On Fri, Jun 13, 2014 at 12:55AM, Mattmann, Chris A (3980) wrote:
> > >> I think Tez needs some more help mentoring. I myself haven't had
> > >> as much time as possible so the more folks over there that can
> > >> help mentor the better.
> > >>
> > >> Good job starting this thread, Roman.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >> -Original Message-
> > >> From: Roman Shaposhnik 
> > >> Reply-To: "general@incubator.apache.org" <
> general@incubator.apache.org>
> > >> Date: Thursday, June 12, 2014 5:44 PM
> > >> To: "general@incubator.apache.org" 
> > >> Subject: Re: Request for mentor assessment
> > >>
> > >> >On Wed, Jun 11, 2014 at 5:47 PM, Henry Saputra <
> henry.sapu...@gmail.com>
> > >> >wrote:
> > >> >> Seems like NPanday should go to attic. One mentor I asked did not
> even
> > >> >> monitor it anymore
> > >> >
> > >> >I've had exactly the same experience. My plan here is to wait for
> folks
> > >> >to chime in on this thread and for those mentors who are MiA start
> > >> >different threads asking for additional (replacement) mentors.
> > >> >
> > >> >I really would like for things like retirement proposals to come from
> > >> >somebody who's spent time getting to know the community in greater
> > >> >details.
> > >> >
> > >> >Thanks,
> > >> >Roman.
> > >> >
> > >> >-
> > >> >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
> > >>
> > >
> > > -
> > > 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: Tez graduation [Was: Request for mentor assessment]

[Ted Dunning]

Chris

Regardless of whether it is an explicit requirement to have some specific level 
of diversity, there is a requirement that the group demonstrate community 
building.  

The page in question may be incorrect, but as it stands it does not appear that 
a diverse community has been built. 

I am sympathetic to the encouragement of company participation, but I don't 
think that it serves apache to have projects that are effective stalking horses 
for what are effectively private communities. 

My sensitivity on this point is largely informed by the efforts we have made to 
build the drill community beyond the core team funded by MapR. I felt at the 
beginning of that project and still feel strongly that it is critical for a 
project to develop into a truly open community. Building a real community is 
hard work and it doesn't happen by accident, especially in a high pressure 
competitive environment.  My own opinion is that this effort is not optional. 

If the problem is simply an out of date web page and a good level of diversity 
exists, that would be an excellent outcome. If the web page is, however, 
accurate then I do see this as a problem that needs to e addressed.  


Sent from my iPhone

> On Jun 22, 2014, at 8:31, "Mattmann, Chris A (3980)" 
>  wrote:
> 
> Hi Guys,
> 
> I will dig up the thread from Roy on this, but company-based diversity is
> not a graduation
> requirement. Basically the jist of it is that requiring such would
> discourage companies
> from specifically funding participation in a single open source project
> for fear of these
> types of constraints and we'd lose out on the contributions.
> 
> Cheers,
> Chris
> 
> 
> 
> 
> -Original Message-
> From: Henry Saputra 
> Reply-To: "general@incubator.apache.org" 
> Date: Saturday, June 21, 2014 10:18 PM
> To: "general@incubator.apache.org" 
> Subject: Re: Tez graduation [Was: Request for mentor assessment]
> 
>> Looks like the page is not updated because the proposal mentions more
>> diverse people [1]
>> 
>> [1] http://wiki.apache.org/incubator/TezProposal
>> 
>> On Fri, Jun 20, 2014 at 8:02 PM, Konstantin Boudnik 
>> wrote:
>>> Ok, I've reached out to the Tez project and it seems that they are
>>> wokring w/
>>> Chris Mattmann's on the graduation process (per an email exchange
>>> http://s.apache.org/K7g). What has caught my attention is the PPMC
>>> composition
>>> which is pretty much uniformly represented by a group with the same
>>> affiliation. Given that this page
>>> https://tez.incubator.apache.org/team-list.html
>>> is up to date.
>>> 
>>> If I am reading 
>>> https://incubator.apache.org/guides/graduation.html#community
>>> right, the PPMC and committers composition should be diversified. Is it
>>> a
>>> concern for graduation from the IPMC standpoint of view?
>>> 
>>> Regards,
>>>  Cos
>>> 
 On Mon, Jun 16, 2014 at 06:54PM, Chris Douglas wrote:
 Tez is ready to graduate. Cos, if you can help us manage that process,
 it'd certainly be appreciated. -C
 
 On Mon, Jun 16, 2014 at 12:53 PM, Konstantin Boudnik 
 wrote:
> I share the sentiment with NPanday - doesn't seem like anything is
 happening
> there really.
> 
> If it of an interest to the incubator, I will volunteer to help
 mentoring Tez.
> 
> Cos
> 
> 
>> On Fri, Jun 13, 2014 at 12:55AM, Mattmann, Chris A (3980) wrote:
>> I think Tez needs some more help mentoring. I myself haven't had
>> as much time as possible so the more folks over there that can
>> help mentor the better.
>> 
>> Good job starting this thread, Roman.
>> 
>> 
>> 
>> 
>> 
>> 
>> -Original Message-
>> From: Roman Shaposhnik 
>> Reply-To: "general@incubator.apache.org"
 
>> Date: Thursday, June 12, 2014 5:44 PM
>> To: "general@incubator.apache.org" 
>> Subject: Re: Request for mentor assessment
>> 
>>> On Wed, Jun 11, 2014 at 5:47 PM, Henry Saputra
 
>>> wrote:
 Seems like NPanday should go to attic. One mentor I asked did
 not even
 monitor it anymore
>>> 
>>> I've had exactly the same experience. My plan here is to wait for
 folks
>>> to chime in on this thread and for those mentors who are MiA start
>>> different threads asking for additional (replacement) mentors.
>>> 
>>> I really would like for things like retirement proposals to come
 from
>>> somebody who's spent time getting to know the community in greater
>>> details.
>>> 
>>> Thanks,
>>> Roman.
> -
>>> 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: g

Re: Spam

[Ted Dunning]

My position on this sort of thing has shifted a whole lot over the last few 
years.  I used to be very careful about  offending bots but after dealing 
hundreds of these accounts on MapR user facing sites, I am way less sympathetic.

Kudos for humanity but I recommend not losing much sleep here.  It is very 
likely this isn't somebody who is going to help.  

Sent from my iPhone

> On Jun 23, 2014, at 4:08, Julian Hyde  wrote:
> 
> Maybe contact them and ask them why they want to be on the list? We don't 
> want to ban "people", but the entity behind this email address has done 
> little to persuade me that they are a person.

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

Re: Tez graduation [Was: Request for mentor assessment]

[Ted Dunning]

On Sun, Jun 22, 2014 at 9:33 AM, Mattmann, Chris A (3980) <
chris.a.mattm...@jpl.nasa.gov> wrote:

> >Regardless of whether it is an explicit requirement to have some specific
> >level of diversity, there is a requirement that the group demonstrate
> >community building.
>
> I'm also sympathetic to this: you can see my thread here where originally
> I didn't
> think much had been going on until I explicitly checked the lists and went
> through
> the archives and saw ~7 IIRC PPMC members/committers added since entering
> [1]. That's
> community building regardless of what affiliation those new members came
> from.
>
> The other metrics and statistics (health of the mailing lists/open
> discussions have
> been increasing; releases have been made, etc.) are all there and outlined
> in [1].


As I read the private list, there has been absolutely no effort at adding
committers until last month when the topic of graduation has come up. There
is no substantive discussion on the list of the potential committers, but
simply rather perfunctory +1 votes.

In reading the thread about whether there should be/is a diversity
requirement, I come to a bit of a different conclusion as well.  What I see
in the discussion is that the participants seem to agree that

- there should not be a simple count-based diversity measure because this
would dissuade valuable commercial contributions

- the chance/likelihood of project failure due to a dominant commercial
contributor pulling out should not be considered since project dormancy or
retirement isn't a bad thing.  Better to try and fail than never try.

- there is clear recognition of the risk of commercial companies inventing
a project not so much because of a desire to build community but rather as
a marketing maneuver.

- there is no mention of the problems that have arisen in the Hadoop groups
relative to use of groups and Apache trademarks for marketing purposes.

I don't want to impute motives to actions since I cannot know what others
hold in their hearts, but I don't see evidence of efforts to really build
the community.  There was one meat-space meetup a year ago.  There have
been a few presentations of what Tez is.

I do see a fair number of public statements of the form "Tez is Hortonworks
answer to Impala" or "The future of Hadoop runs on Tez", most of which seem
to come out of Hortonworks' marketing department.

In looking at the dev list back to September of last year, I see a large
number of procedural messages (votes, results, release mechanics), a few
user questions (NPE in such and so, how do I install) and very few design
discussions.  There was one thread last November about combiners, another
in January about map parallelism, and one more in March about reducer
parallelism.  To me this looks a lot like a project where all design
discussions are occurring off-list.

What I would like to see would include

- a strong effort on the part of Tez to bring all design and implementation
discussions to the list,

- continuous community engagement efforts such as weekly hangouts in
different timezones to help new contributors understand what is happening
technically in the project in an interactive setting

- lots of public talks focussed on how outsiders can contribute and how the
design works

- cross posting on related projects offering cross pollination
opportunities.  Such related groups might be Drill, Optiq, Tajo and Spark.
 These postings would say things like "how could you guys help us with Tez"
or "Tez has this and such, would that be helpful to you guys".

- inviting contributors from related projects to give technical
presentations in the context of Tez

Now, my searches have been fairly cursory and could have missed important
activities, but I have a bit of a hard time believing that I have missed
major efforts along these lines.

Based on this evidence, it really does look to me like Tez is a purely
commercial development masquerading as an Apache community.

I agree that superficial diversity metrics are counter-productive, but I
also assert that there isn't any obvious evidence of serious community
building here and there is significant evidence that building community
isn't even the point of the project.  That *is* a substantive issue
relative to graduation.

Re: Tez graduation [Was: Request for mentor assessment]

[Ted Dunning]

Let me repeat that my desired outcome here is Tez graduation.

It is just that I want to see Tez graduate as a viable project.




On Mon, Jun 23, 2014 at 12:43 AM, Mattmann, Chris A (3980) <
chris.a.mattm...@jpl.nasa.gov> wrote:

> Thanks Ted, these are all important points that require responses. I have
> CC'ed the dev@tez.i.a.o
> list, where I hope the Tez community can respond to your points below in
> detail.
>
> Guys, please see Ted's comments below and please try to address them in
> light of the
>
> recent [DISCUSS] Graduation thread I raised. It's fine if the answer to
> some of the
> points is (1) we plan on addressing them by X date, with Y action; (2) we
> don't think
> this is a valid point *because* ..*explanation*; (3) you didn't consider
> this factoid
> _here_, etc.
>
> I'm hoping the other mentors on the project can step up and have some
> insight
> into the below. I look forward to the discussion.
>
>
> Cheers,
> Chris
>
>
> -Original Message-
> From: Ted Dunning 
> Reply-To: "general@incubator.apache.org" 
> Date: Monday, June 23, 2014 12:12 AM
> To: "general@incubator.apache.org" 
> Subject: Re: Tez graduation [Was: Request for mentor assessment]
>
> >On Sun, Jun 22, 2014 at 9:33 AM, Mattmann, Chris A (3980) <
> >chris.a.mattm...@jpl.nasa.gov> wrote:
> >
> >> >Regardless of whether it is an explicit requirement to have some
> >>specific
> >> >level of diversity, there is a requirement that the group demonstrate
> >> >community building.
> >>
> >> I'm also sympathetic to this: you can see my thread here where
> >>originally
> >> I didn't
> >> think much had been going on until I explicitly checked the lists and
> >>went
> >> through
> >> the archives and saw ~7 IIRC PPMC members/committers added since
> >>entering
> >> [1]. That's
> >> community building regardless of what affiliation those new members came
> >> from.
> >>
> >> The other metrics and statistics (health of the mailing lists/open
> >> discussions have
> >> been increasing; releases have been made, etc.) are all there and
> >>outlined
> >> in [1].
> >
> >
> >As I read the private list, there has been absolutely no effort at adding
> >committers until last month when the topic of graduation has come up.
> >There
> >is no substantive discussion on the list of the potential committers, but
> >simply rather perfunctory +1 votes.
> >
> >In reading the thread about whether there should be/is a diversity
> >requirement, I come to a bit of a different conclusion as well.  What I
> >see
> >in the discussion is that the participants seem to agree that
> >
> >- there should not be a simple count-based diversity measure because this
> >would dissuade valuable commercial contributions
> >
> >- the chance/likelihood of project failure due to a dominant commercial
> >contributor pulling out should not be considered since project dormancy or
> >retirement isn't a bad thing.  Better to try and fail than never try.
> >
> >- there is clear recognition of the risk of commercial companies inventing
> >a project not so much because of a desire to build community but rather as
> >a marketing maneuver.
> >
> >- there is no mention of the problems that have arisen in the Hadoop
> >groups
> >relative to use of groups and Apache trademarks for marketing purposes.
> >
> >I don't want to impute motives to actions since I cannot know what others
> >hold in their hearts, but I don't see evidence of efforts to really build
> >the community.  There was one meat-space meetup a year ago.  There have
> >been a few presentations of what Tez is.
> >
> >I do see a fair number of public statements of the form "Tez is
> >Hortonworks
> >answer to Impala" or "The future of Hadoop runs on Tez", most of which
> >seem
> >to come out of Hortonworks' marketing department.
> >
> >In looking at the dev list back to September of last year, I see a large
> >number of procedural messages (votes, results, release mechanics), a few
> >user questions (NPE in such and so, how do I install) and very few design
> >discussions.  There was one thread last November about combiners, another
> >in January about map parallelism, and one more in March about reducer
> >parallelism.  To me this looks a lot like a project where all design
> >discussions are occurring off-list.
&

Re: Tez graduation [Was: Request for mentor assessment]

[Ted Dunning]

I will look as soon as possible. I am on a trip right now and am occupied with 
day job stuff >12 hours a day. 

If you don't hear from me in a short time, move forward based in your best 
judgment.  I trust the group to consider my impressions and to think about what 
merit they may (or may not) have. 

Sent from my iPhone

> On Jun 23, 2014, at 23:27, "Mattmann, Chris A (3980)" 
>  wrote:
> 
> 
> I'll now wait to see what Ted thinks, but as far as I'm concerned you
> guys are moving in the direction I suspected (graduation) based on my
> admittedly limited searching of mail archives and basic metrics done
> the other day.

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

Re: Tez graduation [Was: Request for mentor assessment]

[Ted Dunning]

On Mon, Jun 23, 2014 at 2:23 PM, Bikas Saha  wrote:

> Community building is an organic process that grows on its own accord.
>

Really, I was going to run away for a bit, but my feeling is that this
statement is amazingly naive about how communities are built.

Community doesn't just happen.  Community doesn't just grow of its own
accord.  Community grows when people make serious, explicit actions to help
it grow, to bring in newcomers, to publish plans in many places *before*
code is written.

Building community is hard work that you have to intend to do.  If you
don't do the work, it won't just happen any more than code writes itself.

Re: July report project list

[Ted Dunning]

I feel your pain!

Sent from my iPhone

> On Jun 28, 2014, at 7:39, Marvin Humphrey  wrote:
> 
> Others are going to have to step up their game.
> 
> Marvin Humphrey

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

Re: [VOTE] Graduate Apache Tez from Apache Incubator to TLP

[Ted Dunning]

+1



On Tue, Jul 1, 2014 at 7:16 AM, Alan Gates  wrote:

> +1.
>
> Alan.
>
>   Hitesh Shah 
>  June 30, 2014 at 9:16 PM
> Hello folks
>
> Tez entered incubation in February, 2013. Since then, we have made
> progress towards graduation[1]. The Tez community recently voted positively
> towards graduation[2] with 27 +1s.
> Of the 27, there were 5 IPMC votes from our mentors:
> - Alan Gates
> - Arun C. Murthy
> - Chris Mattman
> - Chris Douglas
> - Jakob Homan
>
> Now, I would like to ask the IPMC to vote for the graduation of Apache Tez.
>
> Please VOTE to indicate if Apache Tez is ready to graduate as a Top Level
> Project. The board resolution is included below.
>
> [ ] +1 Graduate Apache Tez as a TLP
> [ ] +0 Don't care.
> [ ] -1 Don't graduate Apache Tez as a TLP because…
>
> The vote will remain open for 72 hours.
>
> thanks
> — Hitesh Shah ( on behalf of Tez PPMC )
>
> [1]
> http://mail-archives.apache.org/mod_mbox/incubator-tez-dev/201406.mbox/%3ccfc4fef8.16337a%25chris.a.mattm...@jpl.nasa.gov%3E
> [2]
> http://mail-archives.apache.org/mod_mbox/incubator-tez-dev/201406.mbox/%3ccaoapips7pjs_6hinkwk0uv0hnnrydqcg639dpf9vojeuto9...@mail.gmail.com%3E
>
> Board Resolution:
>
> --
> X. Establish the Apache Tez Project
>
> WHEREAS, the Board of Directors deems it to be in the best
> interests of the Foundation and consistent with the
> Foundation's purpose to establish a Project Management
> Committee charged with the creation and maintenance of
> open-source software, for distribution at no charge to the
> public, related to fast and flexible large-scale data analysis
> on clusters.
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> Committee (PMC), to be known as the "Apache Tez Project", be
> and hereby is established pursuant to Bylaws of the Foundation;
> and be it further
>
> RESOLVED, that the Apache Tez Project be and hereby is
> responsible for the creation and maintenance of software
> related to efficient cluster management, resource isolation
> and sharing across distributed applications; and be it further
> RESOLVED, that the office of "Vice President, Apache Tez" be
> and hereby is created, the person holding such office to serve
> at the direction of the Board of Directors as the chair of the
> Apache Tez Project, and to have primary responsibility for
> management of the projects within the scope of responsibility
> of the Apache Tez Project; and be it further
> RESOLVED, that the persons listed immediately below be and
> hereby are appointed to serve as the initial members of the
> Apache Tez Project:
>
> * Alan Gates  
> * Arun C. Murthy  
> * Ashutosh Chauhan  
> * Bill Graham  
> * Bikas Saha  
> * Chris Douglas  
> * Chris Mattmann  
> * Daryn Sharp  
> * Devaraj Das  
> * Gopal Vijayaraghavan  
> * Gunther Hagleitner  
> * Hitesh Shah  
> * Jitendra Pandey  
> * Jason Lowe  
> * Jakob Homan  
> * Julien Le Dem  
> * Kevin Wilfong  
> * Mike Liddell  
> * Mohammad Kamrul Islam  
> * Namit Jain  
> * Nathan Roberts  
> * Owen O’Malley  
> * Rajesh Balamohan  
> * Robert Evans  
> * Rohini Palaniswamy  
> * Siddharth Seth  
> * Tassapol Athiapinya  
> * Thomas Graves  
> * Tom White  
> * Vikram Dixit  
> * Vinod Kumar Vavilapalli  
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Hitesh Shah be
> appointed to the office of Vice President, Apache Tez, to
> serve in accordance with and subject to the direction of the
> Board of Directors and the Bylaws of the Foundation until
> death, resignation, retirement, removal or disqualification, or
> until a successor is appointed; and be it further
>
> RESOLVED, that the Apache Tez Project be and hereby is
> tasked with the migration and rationalization of the Apache
> Incubator Tez podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache
> Incubator Tez podling encumbered upon the Apache Incubator
> Project are hereafter discharged.
>
> --
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>
> --
> Sent with Postbox 
>
> CONFIDENTIALITY NOTICE
> NOTICE: This message is intended for the use of the individual or entity
> to which it is addressed and may contain information that is confidential,
> privileged and exempt from disclosure under applicable law. If the reader
> of this message is not the intended recipient, you are hereby notified that
> any printing, copying, dissemination, distribution, disclosure or
> forwarding of this communication is strictly prohibited. If you have
> received this communication in error, please contact the sender immediately
> and delete it from your system. Thank You.

Re: [PROPOSAL] Apache Argus Proposal

[Ted Dunning]

On Wed, Jul 16, 2014 at 1:20 AM, Chris Douglas  wrote:

> > So, I am fond of Henry's hope that the project will solicit a more
> diversified
> > set of mentors and initial committers.
>
> The committer and PPMC list should be honest. If there is no
> diversity, that fact must be visible for it to be tracked.
>
> Initial committers are a dodge that demonstrates nothing about the
> project's willingness to not only accept, but attract new ideas. The
> viability of an OSS project is not inaccurately *defined* as its
> ability to compete for that attention. Demanding pro forma adherence
> to heuristics is a harmful lesson to podlings, unless the goal is to
> teach them to evade accountability. -C


+1 to this.

Sham committers are more of a pain than lack of diversity, as much as I
dislike sock-puppet projects.

Re: Podling binding votes

[Ted Dunning]

Sounds right to me.

As a separate matter of etiquette and community building, it is usually
good form for mentors to vote last during the community vote and first in
the IPMC vote.




On Thu, Jul 24, 2014 at 8:44 PM, P. Taylor Goetz  wrote:

> My interpretation (and it's just that) is:
>
> Example: Release Vote
>
> A podling votes to release (VOTE email to dev@project). The PPMC and
> IPMC/PPMC (i.e. Mentors) member votes are binding at the PPMC level. This
> means that those votes are binding and community votes are non-binding.
>
> If the PPMC vote passes, the release vote can proceed to the IPMC level (a
> VOTE email to general@). At this point, PPMC votes are non-binding.
> Mentor (since mentors are by definition IPMC members) and any non-mentor
> IPMC member votes can carry over and are binding. Then it's a matter of
> getting enough additional binding IPMC votes to meet the requirement. At
> this point, PPMC and community votes are non-binding.
>
> Again, this is just my interpretation, and I may be off here.
>
> -Taylor
>
> > On Jul 24, 2014, at 6:57 PM, Justin Mclean 
> wrote:
> >
> > Hi,
> >
> > Anyone clarify this as it's not mentioned at [1].
> >
> > Whose votes are binding for releases on the podlings dev list? Obviously
> mentors and PPMC members, but are IPMC members votes binding? I would
> assume so but don't see it stated anywhere. Would Apache members votes be
> binding?
> >
> > Assuming IPMC votes are binding what happen if a podling release dev
> list vote got 3 +1 IPMC votes, would a voted need to done on general @
> incubator or not?
> >
> > Thanks,
> > Justin
> >
> > 1.http://incubator.apache.org/incubation/Incubation_Policy.html#Releases
> > -
> > 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 Drill 0.4.0-incubating release

[Ted Dunning]

I checked the source artifact and found several internal SNAPSHOT
dependencies (should be fixed) and one external SNAPSHOT dependency (must
be fixed).

The good news is that the external SNAPSHOT dependency is parquet version
1.5.0-SNAPSHOT.  Since parquet 1.5.0 has been released, this should be a
trivial fix.




On Mon, Aug 4, 2014 at 8:07 AM, Jacques Nadeau  wrote:

> We've held a vote on drill-dev to release the 0.4.0-incubating release of
> Apache Drill.
>
> The vote thread can be found here:
>
> http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201407.mbox/%3CCAKa9qD%3DKQURAMcS3RQJbUABSU4%3DDEGSewK2s4MAAidu4c%3DOjBg%40mail.gmail.com%3E
>
> The vote passed with:
> +6 binding
> +7 non-binding
>
> A summary email can be found here:
>
> http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201408.mbox/%3CCAKa9qDnyKYS%3D3qbv3%3DfUrcuuNvBKRcvPt4AgWojLhy4tr2ZYLA%40mail.gmail.com%3E
>
> You can find the artifacts for the release at this location:
> http://people.apache.org/~jacques/apache-drill-0.4.0.rc1/
>
> Please vote on this release.
>
> Thanks,
> Jacques
>

Re: [VOTE] Apache Drill 0.4.0-incubating release

[Ted Dunning]

Hmm

That really is quite different.  To add to the mix, the two projects in
question are in the process of entering the Apache incubator.  In Optiq's
case, at least, that means that they have made what they have stated to be
their last non-Apache release, but are not yet in a position to make an
Apache release yet.  That makes a temporary fork whose temporary nature is
somewhat non-standardly indicated by the SNAPSHOT enclitic much more
plausible.

+1 from me, then.

Thanks for the clarification.



On Tue, Aug 5, 2014 at 1:44 PM, Jacques Nadeau  wrote:

> Hey Ted,
>
> Those SNAPSHOT dependencies are a bit misleading.  Because Drill is so
> closely coupled to the Optiq and Parquet codebase, we need to generate
> separate artifacts.  As part of doing monthly releases, it is unfeasible to
> bind Drill releases to incorporating of all patches into upstream projects.
>  You can think of this as similar to how, for years, HBase released on top
> of a modified (non-released) Hadoop due to special requirements for append.
>
>
> As such, while slightly outside typical maven conventions, those SNAPSHOT
> are fixed and will not change in the future.  The github hashes for each
> changeset are as follows:
>
> parquet-format:
>
> https://github.com/jacques-n/incubator-parquet-format/commit/7001502877e0cfbf81d429656989057ccc5fafb2
> parquet-mr:
>
> https://github.com/jaltekruse/parquet-mr/commit/737500cbabd009eee065058fff2ccc8cc806c5b2
> optiq:
>
> https://github.com/jacques-n/optiq/commit/4508b617bd3ffed2840055fe16e6684e1c0a35d7
>
> Hopefully this satisfies the need to document the source references for
> third party dependencies within the Apache Drill 0.4.0 release.
>
> thanks,
> Jacques
>
>
>
>
> On Mon, Aug 4, 2014 at 12:07 PM, Ted Dunning 
> wrote:
>
> > I checked the source artifact and found several internal SNAPSHOT
> > dependencies (should be fixed) and one external SNAPSHOT dependency (must
> > be fixed).
> >
> > The good news is that the external SNAPSHOT dependency is parquet version
> > 1.5.0-SNAPSHOT.  Since parquet 1.5.0 has been released, this should be a
> > trivial fix.
> >
> >
> >
> >
> > On Mon, Aug 4, 2014 at 8:07 AM, Jacques Nadeau 
> wrote:
> >
> > > We've held a vote on drill-dev to release the 0.4.0-incubating release
> of
> > > Apache Drill.
> > >
> > > The vote thread can be found here:
> > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201407.mbox/%3CCAKa9qD%3DKQURAMcS3RQJbUABSU4%3DDEGSewK2s4MAAidu4c%3DOjBg%40mail.gmail.com%3E
> > >
> > > The vote passed with:
> > > +6 binding
> > > +7 non-binding
> > >
> > > A summary email can be found here:
> > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201408.mbox/%3CCAKa9qDnyKYS%3D3qbv3%3DfUrcuuNvBKRcvPt4AgWojLhy4tr2ZYLA%40mail.gmail.com%3E
> > >
> > > You can find the artifacts for the release at this location:
> > > http://people.apache.org/~jacques/apache-drill-0.4.0.rc1/
> > >
> > > Please vote on this release.
> > >
> > > Thanks,
> > > Jacques
> > >
> >
>

Re: [VOTE] Apache Drill 0.4.0-incubating release

[Ted Dunning]

Also, I think that it is important that *all* dependency licenses be
documented in the source release.  Speaking as a consumer, I need to know
what dependencies will come in when I compile the code.  Marking the
dependencies as source inclusions or as compile time or as test
dependencies or as package dependencies is a fine thing to do, but my
strong feeling is that the license summary should be identical in the
source distribution as with the binary artifacts.




On Fri, Aug 8, 2014 at 8:56 AM, Jacques Nadeau  wrote:

> One additional thought.  As I'm thinking more about the NOTICE and LICENSE
> files I think it would be really helpful to have some reviews from you guys
> much earlier in the process than the next release vote.  While the docs are
> helpful and we'll do our best, I'm skeptical we'll get it exactly right on
> our next attempt.  Justin, would you be willing to review these changes
> once we get them up so that we can make sure we're not making other foolish
> mistakes?
>
> thanks,
> Jacques
>
>
> On Fri, Aug 8, 2014 at 8:18 AM, Jacques Nadeau  wrote:
>
> > Hey guys,
> >
> > Sorry I didn't see Henry and Justin's comments until just now.  Per
> > Justin's primary concerns about the License stuff: I think we've just
> made
> > mistakes in the notice and license files as to exactly how we reference
> > things.  All the category B licenses are mvn binary dependencies (per the
> > third party dependencies rules), not source inclusions.   To address
> > Justin's concerns, I've created the following JIRAs which we'll fix
> > straight away: DRILL-1274 and DRILL-1275 along with adding additional
> > requirements to DRILL-1271 in addition to Henry's previous notes on
> NOTICE
> > file.
> >
> > Given the following:
> >
> >- The mistakes are issues with documentation as opposed to invalid
> >source inclusions
> >- The vote was held open for 72 hours before being called
> >- Release artifacts are already on the mirrors
> >- This is a developer preview release with small distribution designed
> >primarily to expand the contributor community
> >- We plan on doing another release within a month where these can be
> >corrected.
> >
> > I'm going to go forward with this release.
> >
> > Thanks again to everyone for all the helpful feedback.  I believe we are
> > making good progress.
> >
> > Jacques
> >
> >
> >
> >
> >
> > On Thu, Aug 7, 2014 at 5:44 PM, Justin Mclean 
> > wrote:
> >
> >> Hi,
> >>
> >> > Ah, I saw disclaimer in the website [1] which I thought enough for
> >> incubator.
> >> > But checking the branding guide [2] seems like incubator need to
> >> > include DISCLAIMER file along with NOTICE and LICENSE files, so this
> >> > could be blocker?
> >>
> >> Given it has 3 +1 votes and a result been called it's really up to the
> >> release manager. IMO it is a blocker, but at the very least I like to
> see a
> >> JIRA for it and it fixed for the next release. The LICENSE issues are
> also
> >> serious - but hopefully just a misunderstanding to what should go into a
> >> LICENSE file.
> >>
> >> Thanks,
> >> Justin
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
> >
>

Re: [VOTE] Graduate Apache Storm to a TLP

[Ted Dunning]

+1 (binding)

Fly little podling, fly!


On Mon, Aug 18, 2014 at 2:15 PM, Mattmann, Chris A (3980) <
chris.a.mattm...@jpl.nasa.gov> wrote:

> +1 (binding). Good luck!
>
> ++
> Chris Mattmann, Ph.D.
> Chief Architect
> Instrument Software and Science Data Systems Section (398)
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 168-519, Mailstop: 168-527
> Email: chris.a.mattm...@nasa.gov
> WWW:  http://sunset.usc.edu/~mattmann/
> ++
> Adjunct Associate Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++
>
>
>
>
>
>
> -Original Message-
> From: "P. Taylor Goetz" 
> Reply-To: 
> Date: Monday, August 18, 2014 2:02 PM
> To: Incubator 
> Subject: [VOTE] Graduate Apache Storm to a TLP
>
> >Apache Storm has been incubating since September 2014. Since then we have
> >added 3 additional committers (with another 2 approved and pending
> >account creation), and performed two releases. The Storm community
> >recently voted to graduate[1] with 11 +1 votes. Of the 11 votes, 2 were
> >from IPMC members:
> >
> >- Arvind Prabhakar
> >- Suresh Srinivas
> >
> >I would now like to ask the IPMC to vote for the graduation of Apache
> >Storm to a top-level project.
> >
> >Please vote to indicate if Apache Storm is ready to graduate. The
> >proposed board resolution is included below.
> >
> >[ ] +1 Graduate Apache Storm as a TLP
> >[ ] +0 No opinion
> >[ ] -1 Do not graduate Apache Storm as a TLP becauseŠ
> >
> >This vote will be open for at least 72 hours.
> >
> >- Taylor
> >
> >[1]
> >
> http://mail-archives.apache.org/mod_mbox/incubator-storm-dev/201408.mbox/%
> >3c6ea90e5b-792f-4ec2-b5fc-086caf642...@apache.org%3e
> >
> >
> >
> >=== Board Resolution ===
> >
> >X. Establish the Apache Storm Project
> >
> >   WHEREAS, the Board of Directors deems it to be in the best
> >   interests of the Foundation and consistent with the
> >   Foundation's purpose to establish a Project Management
> >   Committee charged with the creation and maintenance of
> >   open-source software, for distribution at no charge to
> >   the public, related to distributed, fault-tolerant,
> >   and high-performance realtime computation.
> >
> >   NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> >   Committee (PMC), to be known as the "Apache Storm Project",
> >   be and hereby is established pursuant to Bylaws of the
> >   Foundation; and be it further
> >
> >   RESOLVED, that the Apache Storm Project be and hereby is
> >   responsible for the creation and maintenance of software
> >   related to distributed, fault-tolerant, and high-
> >   performance realtime computation; and be it further
> >
> >   RESOLVED, that the office of "Vice President, Apache Storm" be
> >   and hereby is created, the person holding such office to
> >   serve at the direction of the Board of Directors as the chair
> >   of the Apache Storm Project, and to have primary responsibility
> >   for management of the projects within the scope of
> >   responsibility of the Apache Storm Project; and be it further
> >
> >   RESOLVED, that the persons listed immediately below be and
> >   hereby are appointed to serve as the initial members of the
> >   Apache Storm Project:
> >
> > * Derek Dagit  (da...@apache.org)
> > * Devaraj Das  (d...@apache.org)
> > * Ted Dunning  (tdunn...@apache.org)
> > * Robert Evans (bo...@apache.org)
> > * Andy Feng(af...@apache.org)
> > * P. Taylor Goetz  (ptgo...@apache.org)
> > * Jason Jackson(jjack...@apache.org)
> > * Flip Kromer  (mrf...@apache.org)
> > * David Lao(d...@apache.org)
> > * Nathan Marz  (nathanm...@apache.org)
> > * Michael G. Noll  (mig...@apache.org)
> >* Arvind Prabhakar (arv...@apache.org)
> > * James Xu (xumingm...@apache.org)
> >
> >   NOW, THEREFORE, BE IT FURTHER RESOLVED, that P. Taylor Goetz
> >   be appointed to the office of Vice President, Apache Storm, to
> > 

Re: [VOTE] Graduate Apache Storm to a TLP

[Ted Dunning]

Ted missed seeing the dev@ vote, else he (I) would have voted +1.




On Mon, Aug 18, 2014 at 7:11 PM, P. Taylor Goetz  wrote:

> Yes. But Ted voted in this general@/IPMC thread. Arvind's vote was in the
> dev@storm/PPMC thread.
>
> -Taylor
>
> > On Aug 18, 2014, at 9:38 PM, Henry Saputra 
> wrote:
> >
> > I assume +1 from Ted counted as mentor vote?
> >
> >
> >> On Mon, Aug 18, 2014 at 6:24 PM, P. Taylor Goetz 
> wrote:
> >> Hi Justin,
> >>
> >> In the PPMC vote, we had one mentor +1 (Arvind Prabhakar), and one
> non-mentor IPMC member +1 (Suresh Srinivas).
> >>
> >> -Taylor
> >>
> >>> On Aug 18, 2014, at 9:16 PM, Justin Mclean 
> wrote:
> >>>
> >>> Hi,
> >>>
> >>> How many +1 votes were by your mentors?
> >>>
> >>> Justin
> >>>
> >>> -
> >>> 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
> >>
> >
> > -
> > 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: Tooling friendly incubator report

[Ted Dunning]

On Wed, Sep 3, 2014 at 1:05 PM, Marvin Humphrey 
wrote:

> So how about creating the web form but having it generate text which can be
> inserted into the wiki template?  That would allow us to tune the web
> interface without committing to the new format.
>

+1

A simple interface to copy/paste the entire podling report or by section
and also for mentors to sign off would be a bit of an improvement over the
current system.

I don't see much attraction to manually editing YAML or JSON.

Re: [VOTE] Apache Drill 0.5.0-incubating release

[Ted Dunning]

+1 (binding)

Others have checked signatures and conducted functional tests (and noted
tiny discrepancies on the web-site build instructions).  I have used this
software from the master branch quite recently.  As such, I focussed on
non-functional aspects of the distro.

This looks like a very clean and mature release.  I think the project
should graduate.


Source
===

Check dependency file exists
Check Disclaimer
Checked license statement and notice for time64
Checked that signing key appears in public key servers
Checked README, INSTALL
Ran rat,
recursively inspected all poms for out-of-bounds exceptions,
found moot exclusion of sandbox/


Binary
==

Check LICENSE file exists and lists dependencies (did not check
list exhaustively, only spot-checked)
CDDL licensed software is appropriately labelled, CDDL included in
LICENSE, verified source code pointer and inclusion only in
binary distro

EPL licensed software is appropriately labelled, EPL included in
LICENSE, verified source code pointer and inclusion only in binary
distro

WTFPL licensed software is noted.  WTFPL is clearly category A
even though not listed on our web-page at
http://www.apache.org/legal/3party.html.




On Sat, Sep 6, 2014 at 8:36 PM, Jacques Nadeau  wrote:

> It is my pleasure to present the Apache Drill 0.5.0-incubating release to
> the general incubator list for a vote.  This set of artifacts have passed
> our drill-dev vote and incorporate a number of improvements with over 100
> JIRAs closed in the last month.
>
> As part of this release, we looked to address the feedback in our previous
> release from the general list.  This included enhancing our license and
> notice files as well as clearly delineating binary dependencies that are
> distributed as part of our convenience binary.
>
> The vote thread can be found here:
>
> http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201409.mbox/%3CCAKa9qD=L9KLQbNe2BKXKn=H34r0=3boobbd_3uhzeojc9k8...@mail.gmail.com%3E
>
> The vote passed with:
> +5 binding
> +6 non-binding
>
> You can find the artifacts for the release at this location:
> http://people.apache.org/~jacques/apache-drill-0.5.0.rc2/
>
> I look forward to your feedback.
>
> Thanks,
> Jacques
>

Re: [VOTE] Apache Drill 0.5.0-incubating release

[Ted Dunning]

Is the new process documented somewhere?




On Mon, Sep 8, 2014 at 3:17 PM, sebb  wrote:

> On 7 September 2014 20:31, Jacques Nadeau  wrote:
> > As I understand the release guidelines, one is not allowed to put
> something
> > on dist.apache.org until after a release vote by the Incubator PMC
> approves
> > that release:
> >
> > "Only formally-approved releases may be distributed from the main
> > directories" [1]
> >
> > For this candidate, as with our last two releases, we followed this piece
> > of information:
> >
> > "It is traditional that release managers use their Apache home space to
> > make available release candidates. " [1]
>
> Historic tradition; that was before svnpubsub.
>
> Note that the DEV tree at
>
> https://dist.apache.org/repos/dist/dev/xyz
>
> is NOT published to www.apache.org/dist
>
> The svnpubsub process takes releases from the RELEASE tree at
>
> https://dist.apache.org/repos/dist/release/xyz
>
> Since they have the same parent, one can use svn move (or svnmucc) to
> transfer the files from dev to release area.
> This provides traceability (assuming the the release vote includes the
> SVN revision number)
>
> > To date, we only push to dist.apache.org once we have received approval
> > here.  Can you point me to the guidelines that lead you to believe that
> > this must be staged on dist.apache.org?
> >
> > Thanks,
> > Jacques
> >
> > [1]
> >
> http://incubator.apache.org/guides/releasemanagement.html#best-practice-incubator-release-vote
> >
> >
> >
> >
> >
> >
> >
> > On Sun, Sep 7, 2014 at 11:48 AM, John D. Ament 
> > wrote:
> >
> >> Sorry, I have to vote -1
> >>
> >> The release is not staged in the proper place (e.g.
> >> https://dist.apache.org/repos/dist/dev/incubator/ )
> >>
> >> If this gets moved, I can vote +1
> >>
> >> On Sun, Sep 7, 2014 at 11:29 AM, Jacques Nadeau 
> >> wrote:
> >>
> >> > Hi John,
> >> >
> >> > Thanks for the feedback.  I'd like to respond to each of your
> concerns:
> >> >
> >> > >>Your NOTICE file is missing MIT license.
> >> >
> >> > The notice file states:  "Please see LICENSE for additional copyright
> and
> >> > licensing information." The LICENSE file contains the MIT license.
> >> >
> >> > >>Your source file includes binaries in the sample-data directory.
> >> >
> >> > These are small sample data files that are used to do various unit
> tests.
> >> >  They have been approved on both of our previous releases because of
> >> their
> >> > small size (<24k combined) and the fact that they are not source code.
> >> >  These are raw data files that happen to be binary in nature but are
> for
> >> > all purposes the same as example json files we include for testing
> >> > purposes.
> >> >
> >> > >> Ideally, your directory name should match the release version
> >> (0.5.0.rc2
> >> > vs 0.5.0)
> >> >
> >> > The name of the release candidate directory is due to the nature of
> the
> >> > Apache voting process.  Each time we have a release candidate in the
> >> > community, we hold a vote.  We always maintain past release
> candidates so
> >> > that we can refer back to them.  All artifacts in the release
> candidate
> >> > hold the release/public names and will ultimately be hosted on the
> Apache
> >> > distribution servers at the appropriately named release directory.
> For
> >> > historical perspective on this, see the following that has been our
> >> > strategy thus far:
> >> >
> >> > our m1 release:
> >> > http://people.apache.org/~jacques/apache-drill-1.0.0-m1 (fail)
> >> > http://people.apache.org/~jacques/apache-drill-1.0.0-m1.rc2 (fail)
> >> > http://people.apache.org/~jacques/apache-drill-1.0.0-m1.rc3 (fail)
> >> > http://people.apache.org/~jacques/apache-drill-1.0.0-m1.rc4
> (approved)
> >> -->
> >> > and distributed as
> >> >
> >>
> https://archive.apache.org/dist/incubator/drill/drill-1.0.0-m1-incubating/
> >> >
> >> > our 0.4.0 release:
> >> > http://people.apache.org/~jacques/apache-drill-0.4.0.rc0 (fail)
> >> > http://people.apache.org/~jacques/apache-drill-0.4.0.rc1 (approved)
> -->
> >> > distributed as
> >> >
> https://archive.apache.org/dist/incubator/drill/drill-0.4.0-incubating/
> >> >
> >> > our 0.5.0 release:
> >> > http://people.apache.org/~jacques/apache-drill-0.5.0.rc0 (fail)
> >> > http://people.apache.org/~jacques/apache-drill-0.5.0.rc1 (fail)
> >> > http://people.apache.org/~jacques/apache-drill-0.5.0.rc2 (pending)
> >> >
> >> >
> >> > As you can see, the rc numbers are only used during the voting
> process.
> >> >  Once we get approval from the incubator, we drop the rc so that
> external
> >> > consumers aren't confused by failed released candidates.
> >> >
> >> > Hopefully this satisfies your concerns and you can vote +1 for our
> >> release.
> >> >
> >> > thanks again for your feedback,
> >> > Jacques
> >> >
> >> >
> >> > On Sun, Sep 7, 2014 at 5:09 AM, John D. Ament  >
> >> > wrote:
> >> >
> >> > > Hi,
> >> > >
> >> > > Your NOTICE file is missing MIT license.
> >> > > Your source file includes binaries in the samp

Re: [VOTE] Apache Drill 0.5.0-incubating release

[Ted Dunning]

Well, I was trying to gently ask if there was some way to break the impasse
between different versions of the documentation.

Obviously you saw one thing and Jacques saw another.  But you said what he
saw was out of date.  How could he tell that?  Have you rectified the
competing versions of documentation?



On Mon, Sep 8, 2014 at 4:27 PM, John D. Ament 
wrote:

> Ted,
>
> Do you mean more than here:
>
> [1]: http://www.apache.org/dev/publishing-maven-artifacts.html
> [2]: http://www.apache.org/dev/release.html#host-rc
>
> On Mon, Sep 8, 2014 at 7:12 PM, Ted Dunning  wrote:
>
> > Is the new process documented somewhere?
> >
> >
> >
> >
> > On Mon, Sep 8, 2014 at 3:17 PM, sebb  wrote:
> >
> > > On 7 September 2014 20:31, Jacques Nadeau  wrote:
> > > > As I understand the release guidelines, one is not allowed to put
> > > something
> > > > on dist.apache.org until after a release vote by the Incubator PMC
> > > approves
> > > > that release:
> > > >
> > > > "Only formally-approved releases may be distributed from the main
> > > > directories" [1]
> > > >
> > > > For this candidate, as with our last two releases, we followed this
> > piece
> > > > of information:
> > > >
> > > > "It is traditional that release managers use their Apache home space
> to
> > > > make available release candidates. " [1]
> > >
> > > Historic tradition; that was before svnpubsub.
> > >
> > > Note that the DEV tree at
> > >
> > > https://dist.apache.org/repos/dist/dev/xyz
> > >
> > > is NOT published to www.apache.org/dist
> > >
> > > The svnpubsub process takes releases from the RELEASE tree at
> > >
> > > https://dist.apache.org/repos/dist/release/xyz
> > >
> > > Since they have the same parent, one can use svn move (or svnmucc) to
> > > transfer the files from dev to release area.
> > > This provides traceability (assuming the the release vote includes the
> > > SVN revision number)
> > >
> > > > To date, we only push to dist.apache.org once we have received
> > approval
> > > > here.  Can you point me to the guidelines that lead you to believe
> that
> > > > this must be staged on dist.apache.org?
> > > >
> > > > Thanks,
> > > > Jacques
> > > >
> > > > [1]
> > > >
> > >
> >
> http://incubator.apache.org/guides/releasemanagement.html#best-practice-incubator-release-vote
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Sun, Sep 7, 2014 at 11:48 AM, John D. Ament <
> john.d.am...@gmail.com
> > >
> > > > wrote:
> > > >
> > > >> Sorry, I have to vote -1
> > > >>
> > > >> The release is not staged in the proper place (e.g.
> > > >> https://dist.apache.org/repos/dist/dev/incubator/ )
> > > >>
> > > >> If this gets moved, I can vote +1
> > > >>
> > > >> On Sun, Sep 7, 2014 at 11:29 AM, Jacques Nadeau  >
> > > >> wrote:
> > > >>
> > > >> > Hi John,
> > > >> >
> > > >> > Thanks for the feedback.  I'd like to respond to each of your
> > > concerns:
> > > >> >
> > > >> > >>Your NOTICE file is missing MIT license.
> > > >> >
> > > >> > The notice file states:  "Please see LICENSE for additional
> > copyright
> > > and
> > > >> > licensing information." The LICENSE file contains the MIT license.
> > > >> >
> > > >> > >>Your source file includes binaries in the sample-data directory.
> > > >> >
> > > >> > These are small sample data files that are used to do various unit
> > > tests.
> > > >> >  They have been approved on both of our previous releases because
> of
> > > >> their
> > > >> > small size (<24k combined) and the fact that they are not source
> > code.
> > > >> >  These are raw data files that happen to be binary in nature but
> are
> > > for
> > > >> > all purposes the same as example json files we include for testing
> > > >> > purposes.
> > > >> >
&g

Re: [VOTE] Apache Drill 0.5.0-incubating release

[Ted Dunning]

John,

Actually, on reading the links you provide, neither provides solid guidance
about the issue in question.  The second link comes closest where it says
that projects typically use one of three different methods.  How does this
document your strong preference for a single one of these alternatives?




On Mon, Sep 8, 2014 at 4:27 PM, John D. Ament 
wrote:

> Ted,
>
> Do you mean more than here:
>
> [1]: http://www.apache.org/dev/publishing-maven-artifacts.html
> [2]: http://www.apache.org/dev/release.html#host-rc
>
> On Mon, Sep 8, 2014 at 7:12 PM, Ted Dunning  wrote:
>
> > Is the new process documented somewhere?
> >
> >
> >
> >
> > On Mon, Sep 8, 2014 at 3:17 PM, sebb  wrote:
> >
> > > On 7 September 2014 20:31, Jacques Nadeau  wrote:
> > > > As I understand the release guidelines, one is not allowed to put
> > > something
> > > > on dist.apache.org until after a release vote by the Incubator PMC
> > > approves
> > > > that release:
> > > >
> > > > "Only formally-approved releases may be distributed from the main
> > > > directories" [1]
> > > >
> > > > For this candidate, as with our last two releases, we followed this
> > piece
> > > > of information:
> > > >
> > > > "It is traditional that release managers use their Apache home space
> to
> > > > make available release candidates. " [1]
> > >
> > > Historic tradition; that was before svnpubsub.
> > >
> > > Note that the DEV tree at
> > >
> > > https://dist.apache.org/repos/dist/dev/xyz
> > >
> > > is NOT published to www.apache.org/dist
> > >
> > > The svnpubsub process takes releases from the RELEASE tree at
> > >
> > > https://dist.apache.org/repos/dist/release/xyz
> > >
> > > Since they have the same parent, one can use svn move (or svnmucc) to
> > > transfer the files from dev to release area.
> > > This provides traceability (assuming the the release vote includes the
> > > SVN revision number)
> > >
> > > > To date, we only push to dist.apache.org once we have received
> > approval
> > > > here.  Can you point me to the guidelines that lead you to believe
> that
> > > > this must be staged on dist.apache.org?
> > > >
> > > > Thanks,
> > > > Jacques
> > > >
> > > > [1]
> > > >
> > >
> >
> http://incubator.apache.org/guides/releasemanagement.html#best-practice-incubator-release-vote
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Sun, Sep 7, 2014 at 11:48 AM, John D. Ament <
> john.d.am...@gmail.com
> > >
> > > > wrote:
> > > >
> > > >> Sorry, I have to vote -1
> > > >>
> > > >> The release is not staged in the proper place (e.g.
> > > >> https://dist.apache.org/repos/dist/dev/incubator/ )
> > > >>
> > > >> If this gets moved, I can vote +1
> > > >>
> > > >> On Sun, Sep 7, 2014 at 11:29 AM, Jacques Nadeau  >
> > > >> wrote:
> > > >>
> > > >> > Hi John,
> > > >> >
> > > >> > Thanks for the feedback.  I'd like to respond to each of your
> > > concerns:
> > > >> >
> > > >> > >>Your NOTICE file is missing MIT license.
> > > >> >
> > > >> > The notice file states:  "Please see LICENSE for additional
> > copyright
> > > and
> > > >> > licensing information." The LICENSE file contains the MIT license.
> > > >> >
> > > >> > >>Your source file includes binaries in the sample-data directory.
> > > >> >
> > > >> > These are small sample data files that are used to do various unit
> > > tests.
> > > >> >  They have been approved on both of our previous releases because
> of
> > > >> their
> > > >> > small size (<24k combined) and the fact that they are not source
> > code.
> > > >> >  These are raw data files that happen to be binary in nature but
> are
> > > for
> > > >> > all purposes the same as example json files we include for testing
> > > >> > purposes.
> > > >> >
&g

Re: September report

[Ted Dunning]

This is easier if you start from the template report that is on the wiki
page.

http://wiki.apache.org/incubator/September2014

Note that the deadline has passed already, so you will likely be asked to
file your report next month.

Some things that I don't see in this report are:

- the amount of traffic on your mailing lists for the last few months

- the number of commits on your project(s) for the last few months

- when your last new committer was added, same for PMC

- why your group has problems doing a simple and rare report on time

- what challenges your project is working on

- what is left to do before graduation




On Mon, Sep 8, 2014 at 9:48 PM, Ryan Ebanks  wrote:

> Here is a draft of a report.  Hopefully I did this correctly.  Please let
> me know what I need to correct and/or add.
>
> StreamsApache Streams is a lightweight processing engine for Activity
> Streams objects that can be export to multiple
> runtimes/frameworks.Streams has been incubating since 2012-11-20.Three
> most important issues to address in the move towards graduation:  1.
> Growing the active developer community  2. Creating documentation for
> new users and new contributors  3. Increasing overall code quality in
> the projectAny issues that the Incubator PMC (IPMC) or ASF Board
> wish/need to beaware of?N/AHow has the community developed since the
> last report?  Merged 15 pull requests in the month of August from 4
> different contributors. How has the project developed since the last
> report?  Added new data providers (Facebook & Instagram)
>
>   Bug fixes in the elasticsearch writer
>
>   Discussions on going about documentation and testing standards on
> the community list server.
>
> Date of last release:  2013-01-09
>
>
>
> On Mon, Sep 8, 2014 at 6:46 PM, Ate Douma  wrote:
>
> > On 08-09-14 06:57, Roman Shaposhnik wrote:
> >
> >> Hi!
> >>
> >> it looks like September report is almost done,
> >> except the following podlings:
> >>* Streams
> >>[ ](streams) Matt Franklin
> >>[ ](streams) Ate Douma
> >>[ ](streams) Craig McClanahan
> >>
> >
> >
> >> If there's any chance the above mentors can
> >> facilitate the report and later sign-off on
> >> it would be really appreciated.
> >>
> >>
> > Hi Roman,
> >
> > I'm sorry about the missing Streams report.
> >
> > The problem here is that the current committers, while pretty much active
> > on Streams itself, still have trouble getting it into their skull and
> > planning to draft up a report themselves, so that we (mentors) can sign
> it
> > off...
> > Previous reports so far had to be drafted up by the mentors to get it
> done
> > in time, despite repeated nudges.
> >
> > The last time we warned the committers we would do this no more: part of
> > learning the ropes and working towards graduation is that they also learn
> > to take up this responsibility themselves.
> > Regrettably, they again failed to pick this up and clearly I'm annoyed
> and
> > disappointed :(
> >
> > Hopefully though this blunder and the fact they should 'fix' this already
> > for the report next month will finally make them realize this is not
> > something they can keep overlooking.
> >
> > To be clear, IMO the Streams committers are actually making good progress
> > with the project itself, so from that perspective I do not think the IPMC
> > has much to be worried about. They just need some spanking to get their
> act
> > together with respect for the Foundation :)
> >
> > So hopefully this direct feedback will be enough 'spanking' ;) and we'll
> > see a proper report delivered and signed off the next month.
> >
> > Kind regards,
> > Ate
> >
> >
> >> Thanks,
> >> Roman.
> >>
> >> P.S. The biggest help with the summary is
> >> tracking releases -- so if somebody can help
> >> with at least that -- it'll be perfect!
> >>
> >> -
> >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> >> For additional commands, e-mail: general-h...@incubator.apache.org
> >>
> >>
> >
>

Re: New Committers not showing up on people.a.o

[Ted Dunning]

Last time I had to figure this out, this link was the key:

http://www.apache.org/dev/pmc.html#SVNaccess




On Thu, Sep 11, 2014 at 2:23 PM, P. Taylor Goetz  wrote:

> We (Storm) have added a few committers/PPMC members, but they aren’t
> listed under the project on people.apache.org.
>
> Poking through the code to generate that site, it looks like that
> information comes from LDAP.
>
> What is the process for updating that information (both now and
> post-graduation)?
>
> Thanks in advance.
>
> -Taylor
>

Re: [PROPOSAL] Grill as new Incubator project

[Ted Dunning]

There is a strong phonetic similarity to Apache Drill, a project in the
same general domain.

Is the Grill name already baked in (pun intended)?



On Fri, Sep 19, 2014 at 7:24 AM, Mattmann, Chris A (3980) <
chris.a.mattm...@jpl.nasa.gov> wrote:

> Thank you Sharad. So I could use this system for remote sensing
> data, like 3-dimension (time, space, and measurement) type of cubes?
> Does it support numerical data well?
>
> Sorry for so many questions just excited :)
>
> ++
> Chris Mattmann, Ph.D.
> Chief Architect
> Instrument Software and Science Data Systems Section (398)
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 168-519, Mailstop: 168-527
> Email: chris.a.mattm...@nasa.gov
> WWW:  http://sunset.usc.edu/~mattmann/
> ++
> Adjunct Associate Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++
>
>
>
>
>
>
> -Original Message-
> From: Sharad Agarwal 
> Reply-To: "sha...@apache.org" 
> Date: Friday, September 19, 2014 4:06 AM
> To: Chris Mattmann 
> Cc: "general@incubator.apache.org" 
> Subject: Re: [PROPOSAL] Grill as new Incubator project
>
> >Chris, Thanks for your comments.
> >
> >
> >The differences that I see are:
> >- SciDB exposes Array Data model and Array Query Language (AQL). Grill
> >data model is based on OLAP Fact and Dimensions. Grill exposes SQL like
> >language (a subset of Hive QL) that works on *logical* entities (facts,
> >dimensions)
> >
> >
> >- The goal of Grill is not to build a new query execution database, but
> >to unify them by having a central metadata catalog, and provide a Cube
> >abstraction layer on top of it.
> >
> >
> >
> >Thanks,
> >Sharad
> >
> >
> >On Fri, Sep 19, 2014 at 9:34 AM, Mattmann, Chris A (3980)
> > wrote:
> >
> >This sounds super cool!
> >
> >How does this relate to SciDB? is it trying to do a similar thing?
> >
> >Cheers,
> >Chris
> >
> >
> >++
> >Chris Mattmann, Ph.D.
> >Chief Architect
> >Instrument Software and Science Data Systems Section (398)
> >NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> >Office: 168-519, Mailstop: 168-527
> >Email: chris.a.mattm...@nasa.gov
> >WWW:  http://sunset.usc.edu/~mattmann/
> >++
> >Adjunct Associate Professor, Computer Science Department
> >University of Southern California, Los Angeles, CA 90089 USA
> >++
> >
> >
> >
> >
> >
> >
> >-Original Message-
> >From: Sharad Agarwal 
> >Reply-To: "general@incubator.apache.org" ,
> >"sha...@apache.org" 
> >Date: Thursday, September 18, 2014 8:54 PM
> >To: "general@incubator.apache.org" 
> >Subject: [PROPOSAL] Grill as new Incubator project
> >
> >>Grill Proposal
> >>==
> >>
> >># Abstract
> >>
> >>Grill is a platform that enables multi-dimensional queries in a unified
> >>way
> >>over datasets stored in multiple warehouses. Grill integrates Apache Hive
> >>with other data warehouses by tiering them together to form logical data
> >>cubes.
> >>
> >>
> >># Proposal
> >>
> >>Grill provides a unified Cube abstraction for data stored in different
> >>stores. Grill tiers multiple data warehouses for unified representation
> >>and
> >>efficient access. It provides SQL-like Cube query language to query and
> >>describe data sets organized in data cubes. It enables users to run
> >>queries
> >>against Facts and Dimensions that can span multiple physical tables
> >>stored
> >>in different stores.
> >>
> >>The primary use cases that Grill aims to solve:
> >>- Facilitate analytical queries by providing the OLAP like Cube
> >>abstraction
> >>- Data Discovery by providing single metadata layer for data stored in
> >>different stores
> >>- Unified access to data by integrating Hive with other traditional data
> >>warehouses
> >>
> >>
> >># Background
> >>
> >>Apache Hive is a data warehouse that facilitates querying and managing
> >>large datasets stored in distributed storage systems like HDFS. It
> >>provides
> >>SQL like language called HiveQL aka HQL.  Apache Hive is a widely used
> >>platform in various organizations for doing adhoc analytical queries.
> >>In a typical Data warehouse scenario, the data is multi-dimensional and
> >>organized into Facts and Dimensions to form Data Cubes. Grill provides
> >>this
> >>logical layer to enable querying and manage data as Cubes.
> >>The Grill project is actively being developed at InMobi to provide the
> >>higher level of analytical abstraction to query data stored in different
> >>storages including Hive and beyond seamlessly.
> >>
> >>
> >># Rationale
> >>
> >>The Grill project aims to ease the analytical querying capabilities and
> >>cut
> >>the data-silos by pr

Re: [PROPOSAL] Grill as new Incubator project

[Ted Dunning]

Both Lens and Blend are nice names.  Nice connotations as well.

I am slightly stunned by a quick search on the name Lens.  I only found one
software package with that name (and it was for lens calibration so far
from databases).  A name like that is usually massively over used.

This might be a really nice opportunity to get a nice one syllable name.




On Mon, Sep 22, 2014 at 2:59 AM, Sharad Agarwal  wrote:

> Based on the feedback, we are considering to rename the project.
>
> Please provide feedback on following names:
> Apache Lens
> Apache Blend
>
> Thanks,
> Sharad
>

Re: [PROPOSAL] Grill as new Incubator project

[Ted Dunning]

Awesome community-building attitude here!

I foresee a successful incubation.  :-)



On Tue, Sep 23, 2014 at 1:24 AM, Sharad Agarwal  wrote:

> Thanks Ted. We have renamed the proposal to Lens.
>
> The proposal is pasted here ->
> https://wiki.apache.org/incubator/LensProposal
>
> Thanks
> Sharad
>
> On Tue, Sep 23, 2014 at 12:04 AM, Ted Dunning 
> wrote:
>
> > Both Lens and Blend are nice names.  Nice connotations as well.
> >
> > I am slightly stunned by a quick search on the name Lens.  I only found
> one
> > software package with that name (and it was for lens calibration so far
> > from databases).  A name like that is usually massively over used.
> >
> > This might be a really nice opportunity to get a nice one syllable name.
> >
> >
> >
> >
> > On Mon, Sep 22, 2014 at 2:59 AM, Sharad Agarwal 
> wrote:
> >
> > > Based on the feedback, we are considering to rename the project.
> > >
> > > Please provide feedback on following names:
> > > Apache Lens
> > > Apache Blend
> > >
> > > Thanks,
> > > Sharad
> > >
> >
>

Re: [PROPOSAL] Grill as new Incubator project

[Ted Dunning]

Drill uses standard sorts of CI infrastructure.

Lens (was Grill) is something I don't know about and they are the ones who
might have something unusual.



On Fri, Sep 26, 2014 at 12:44 PM, David Nalley  wrote:

> > currently employed by SoftwareAG. Raghavendra Singh from InMobi has built
> > the QA automation for Grill.
> >
>
> What kind of QA environment does Drill/Lens have currently? How much
> do you expect to need going forward?
>
> --David
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Committer Voting and Vetos

[Ted Dunning]

On Mon, Sep 29, 2014 at 8:52 PM, William A. Rowe Jr. 
wrote:

> The HTTP Server PMC has succeeded in working through these issues without
> evicting a project member, and continuing to make progress.
>

There is a lot of credit due for this.

Of course, there are different stresses on each project.  Some projects
have large commercial interests at stake.  Others have incredibly little
directly at stake.  The problems in these different groups are often very
different.

My own limited experience is that people often play together better when
there is much at stake, except when there is a perception of a zero sum
game.  When little is at stake, just about anybody can afford to be an ass.

This observation has been attributed to a huge number of people [1].  I
like the idea that Samuel Johnson was the originator of the core idea.

http://quoteinvestigator.com/2013/08/18/acad-politics/

Re: Committer Voting and Vetos

[Ted Dunning]

On Tue, Sep 30, 2014 at 3:46 AM, Greg Stein  wrote:

> To the concrete question, the Subversion project never calls a strict
> [VOTE] for new committers or PMC members. We discuss first, and that sets
> the direction. People throw out +1 messages, but that is "sure, make it so"
> rather than a true vote. Whenever somebody says "wait a minute", then we
> do. We don't have formal rules around this stuff, since a general goal of
> consensus is so ingrained into the community.
>

The nice thing about the vote is that there is a [RESULT] message to link
to.  What does the Subversion project link to in the account request?

Re: [VOTE] Apache Drill 0.6.0-incubating release

[Ted Dunning]

The unit test was only on Java 1.8.  That problem will be resolved in the
next release which will be in roughly a month from now.  The current
primary target of Drill is 1.7.

The number of reviewers for the release is an indication of how the
community doesn't view Java 1.8 as a critical platform at this time.



On Tue, Oct 7, 2014 at 8:41 AM, jan i  wrote:

> Hi.
>
> I have had a look at your release and it looks good, I could not find any
> formal errors.
>
> But I took a closer look at the release vote thread, because a failing unit
> test is a serious bad quality signal for me.
>
> Whenever I test new software, I download it, build it, then run all  test
> cases to secure I got it build correctly, where I assume I have made
> something wrong if a test case fails.
>
> Apache is known for quality software and I think we all want to keep that
> image. I am sure the project does not take quality lightly, but the
> attitude "can be fixed later" especially with unit tests is to me not a
> good policy.
>
> If the software only runs with 1.7 and not higher, then why not make a
> simple startup version check, then there would be no problem (of course its
> even better to solve the problem). I just wonder how this error will affect
> people using the project.
>
> It seems (from the vote thread) you already have solved the problem, but
> dont want to wait for a respin, can you please at least explain why the
> project is under such a time constraint, that 72 hours is too long to wait
> to make good quality.
>
> I wanted to give the release a -1 but decided to give
>
> -0 binding.
>
> in the hope the PMC will go for quality and voluntary respin the release.
>
> rgds
> jan i
>
>
>
> On 7 October 2014 07:09, Steven Phillips  wrote:
>
> > In case there is any confusion, the first email sent out in this thread
> had
> > the wrong vote count. The second one has the correct count:
> >
> > +9 binding
> > +3 non-binding
> >
> > I should also mention there was one -0 (binding). This was due to unit
> test
> > failures when using java 1.8. Jiras were filed, and the fix will be
> > included in the next release, not this one.
> >
> > On Sun, Oct 5, 2014 at 11:14 AM, Steven Phillips  wrote:
> >
> > > I would like to present the Apache Drill 0.6.0-incubating release to
> > > the general incubator list for a vote.  This set of artifacts have
> passed
> > > our drill-dev vote and incorporate a number of improvements with over
> 30
> > > JIRAs closed in the last month.
> > >
> > > The vote thread can be found here:
> >
> http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201410.mbox/%3CCAA_-67fAJFB20wGX462wm7BYvoSy3PvydCPgY9uNSEj3HpQRmg%40mail.gmail.com%3E
> > >
> > > The vote passed with:
> > > +9 binding
> > > +3 non-binding
> > >
> > > You can find the artifacts for the release at this location:
> > http://people.apache.org/~smp/apache-drill-0.6.0.rc0/
> > >
> > > I look forward to your feedback.
> > >
> > > Thanks,
> > > Steven
> > >
> > >
> >
> >
> > --
> >  Steven Phillips
> >  Software Engineer
> >
> >  mapr.com
> >
>

Re: [VOTE] Apache Drill 0.6.0-incubating release

[Ted Dunning]

On Tue, Oct 7, 2014 at 8:41 AM, jan i  wrote:

> It seems (from the vote thread) you already have solved the problem, but
> dont want to wait for a respin, can you please at least explain why the
> project is under such a time constraint, that 72 hours is too long to wait
> to make good quality.
>

You have to make a cut somewhere.

There are always a number of very small, low priority bugs and platform
issues in any release.  Drill is now on a monthly release cycle so triaging
a minor bug as something that doesn't stop shipping has very little
down-side.

On the other hand, delaying by 3+ days is more than a 10% delay in the
monthly release.

Your characterization of this issue being a "quality" issue is also a bit
of an over-statement.  The problem was that several dependencies worked
differently on Java8 than Java7.  The fix involved changing the version of
these dependencies.  Changing dependency versions is not a small change and
requires a full QA cycle since it takes serious thought to decide what
impact the version change might have.  The best way for that to happen in a
reasonable way is to simply put this fix in the next release.

Re: [VOTE] Apache Drill 0.6.0-incubating release

[Ted Dunning]

On Tue, Oct 7, 2014 at 2:46 PM, jan i  wrote:

> > 4.) And lastly, as Julian mentioned on the thread that the set of fixes
> > might not be complete yet,
> > I think we need more time before we can merge these changes in to a
> release
> > with confidence to
> > support a new platform.
> >
>
> I agree with this, but it still does not explain why the software not
> simply deny runing with java1.7+. To me it seems a simple "if" during load
> could solve the problem, and is in general something a software should do
> with all dependencies especially when newer versions dont work (most of us
> expect newer versions to be backward compatible).
>

That is a plausible action.  That would not have changed the fact of the
failure under 1.8, it would merely have changed the error message.

Until this issue was encountered, however, it was the assumption that the
code would run on java8, but it was not considered important enough to
specifically test since, as Aditya mentioned, java8 has essentially no
production presence so far.  As such, testing for java8 and refusing to
start would simply guaranteeing failure as opposed to being open to success.

Re: [VOTE] Apache Drill 0.6.0-incubating release

[Ted Dunning]

On Tue, Oct 7, 2014 at 2:46 PM, jan i  wrote:

> My intentation was to raise a concern, NOT to block the release (I did on
> purpose give a 0 and not -1). I am sorry if you feel its an over-statement,
> but honestly for me failing unit tests and not checking a version
> dependency (in case of older versions) is cause for alarm.
>

The response that you are getting is a measure of how seriously the Drill
project takes community building and consensus.

Re: [VOTE] Apache Drill 0.6.0-incubating release

[Ted Dunning]

+1 (binding)

I have downloaded the code, compiled and run the tests.

I also checked all checksums, and verified the signatures.  I also verified
that the signing key was signed by people I trust (and indeed, by me as
well) and correctly propagated to the gpg key servers.

I also reviewed in both the source and binary that the various notices,
licenses and dependency lists appear to be correct.  The license files also
appear to be correct and include the correct attributions.  I have
previously checked that the list of dependencies and attributions was both
correct and complete and since these are generated automatically, I did not
specifically check them again.  Moreover, the dependencies have not changed
so this gives even higher confidence in this assessment.

It should be noted that Drill as a project has been able to produce several
high quality releases in a row with different release managers.  Moreover,
Drill has invested in documentation to help train release managers to help
grow the community.



On Tue, Oct 7, 2014 at 8:41 AM, jan i  wrote:

> Hi.
>
> I have had a look at your release and it looks good, I could not find any
> formal errors.
>
> But I took a closer look at the release vote thread, because a failing unit
> test is a serious bad quality signal for me.
>
> Whenever I test new software, I download it, build it, then run all  test
> cases to secure I got it build correctly, where I assume I have made
> something wrong if a test case fails.
>
> Apache is known for quality software and I think we all want to keep that
> image. I am sure the project does not take quality lightly, but the
> attitude "can be fixed later" especially with unit tests is to me not a
> good policy.
>
> If the software only runs with 1.7 and not higher, then why not make a
> simple startup version check, then there would be no problem (of course its
> even better to solve the problem). I just wonder how this error will affect
> people using the project.
>
> It seems (from the vote thread) you already have solved the problem, but
> dont want to wait for a respin, can you please at least explain why the
> project is under such a time constraint, that 72 hours is too long to wait
> to make good quality.
>
> I wanted to give the release a -1 but decided to give
>
> -0 binding.
>
> in the hope the PMC will go for quality and voluntary respin the release.
>
> rgds
> jan i
>
>
>
> On 7 October 2014 07:09, Steven Phillips  wrote:
>
> > In case there is any confusion, the first email sent out in this thread
> had
> > the wrong vote count. The second one has the correct count:
> >
> > +9 binding
> > +3 non-binding
> >
> > I should also mention there was one -0 (binding). This was due to unit
> test
> > failures when using java 1.8. Jiras were filed, and the fix will be
> > included in the next release, not this one.
> >
> > On Sun, Oct 5, 2014 at 11:14 AM, Steven Phillips  wrote:
> >
> > > I would like to present the Apache Drill 0.6.0-incubating release to
> > > the general incubator list for a vote.  This set of artifacts have
> passed
> > > our drill-dev vote and incorporate a number of improvements with over
> 30
> > > JIRAs closed in the last month.
> > >
> > > The vote thread can be found here:
> >
> http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201410.mbox/%3CCAA_-67fAJFB20wGX462wm7BYvoSy3PvydCPgY9uNSEj3HpQRmg%40mail.gmail.com%3E
> > >
> > > The vote passed with:
> > > +9 binding
> > > +3 non-binding
> > >
> > > You can find the artifacts for the release at this location:
> > http://people.apache.org/~smp/apache-drill-0.6.0.rc0/
> > >
> > > I look forward to your feedback.
> > >
> > > Thanks,
> > > Steven
> > >
> > >
> >
> >
> > --
> >  Steven Phillips
> >  Software Engineer
> >
> >  mapr.com
> >
>

Re: [VOTE] Apache Drill 0.6.0-incubating release

[Ted Dunning]

Thanks Lars.  Good perspective. 

Sent from my iPhone

> On Oct 8, 2014, at 21:45, lars hofhansl  wrote:
> 
> +1 (binding)
> 
> - Downloaded bin and -src tarballs.
> - Not knowing much about the internals of Drill (yet), I poked around in the 
> tarballs, looks all good.
> - Ran some of the examples.
> - All looks good. Packaging is clean.
> 
> Few comments:
> - I would probably prefer the documentation to be part of either the bin or 
> src tarball, seems that should be part of the distribution.
> - The documentation on 
> https://cwiki.apache.org/confluence/display/DRILL/Apache+Drill+in+10+Minutes#ApacheDrillin10Minutes-StartDrill
>  is a bit outdated
> (refers to release 0.4.0 at points)
> 
> As for the Java8/Unittest failure discussion. IMHO a release does not need to 
> be free of bugs (that's not actually possible anyway),
> it just means it is useful "snaphot" of the software. In any case this is an 
> important discussion to have.
> (As the HBase 0.94 release manager I introduced a strict monthly release 
> cadence and we found that far more useful then getting all
> the last fixes in - those just have to wait a month. Only for critical 
> correctness issues did I delay a release for a few days. 
> 
> Obviously that is just my opinion.)
> 
> Thanks.
> 
> -- Lars
> 
> 
> 
> 
> 
> From: Ted Dunning 
> To: "general@incubator.apache.org"  
> Sent: Wednesday, October 8, 2014 12:52 PM
> Subject: Re: [VOTE] Apache Drill 0.6.0-incubating release
> 
> 
> +1 (binding)
> 
> I have downloaded the code, compiled and run the tests.
> 
> I also checked all checksums, and verified the signatures.  I also verified
> that the signing key was signed by people I trust (and indeed, by me as
> well) and correctly propagated to the gpg key servers.
> 
> I also reviewed in both the source and binary that the various notices,
> licenses and dependency lists appear to be correct.  The license files also
> appear to be correct and include the correct attributions.  I have
> previously checked that the list of dependencies and attributions was both
> correct and complete and since these are generated automatically, I did not
> specifically check them again.  Moreover, the dependencies have not changed
> so this gives even higher confidence in this assessment.
> 
> It should be noted that Drill as a project has been able to produce several
> high quality releases in a row with different release managers.  Moreover,
> Drill has invested in documentation to help train release managers to help
> grow the community.
> 
> 
> 
> 
> 
> 
>> On Tue, Oct 7, 2014 at 8:41 AM, jan i  wrote:
>> 
>> Hi.
>> 
>> I have had a look at your release and it looks good, I could not find any
>> formal errors.
>> 
>> But I took a closer look at the release vote thread, because a failing unit
>> test is a serious bad quality signal for me.
>> 
>> Whenever I test new software, I download it, build it, then run all  test
>> cases to secure I got it build correctly, where I assume I have made
>> something wrong if a test case fails.
>> 
>> Apache is known for quality software and I think we all want to keep that
>> image. I am sure the project does not take quality lightly, but the
>> attitude "can be fixed later" especially with unit tests is to me not a
>> good policy.
>> 
>> If the software only runs with 1.7 and not higher, then why not make a
>> simple startup version check, then there would be no problem (of course its
>> even better to solve the problem). I just wonder how this error will affect
>> people using the project.
>> 
>> It seems (from the vote thread) you already have solved the problem, but
>> dont want to wait for a respin, can you please at least explain why the
>> project is under such a time constraint, that 72 hours is too long to wait
>> to make good quality.
>> 
>> I wanted to give the release a -1 but decided to give
>> 
>> -0 binding.
>> 
>> in the hope the PMC will go for quality and voluntary respin the release.
>> 
>> rgds
>> jan i
>> 
>> 
>> 
>>> On 7 October 2014 07:09, Steven Phillips  wrote:
>>> 
>>> In case there is any confusion, the first email sent out in this thread
>> had
>>> the wrong vote count. The second one has the correct count:
>>> 
>>> +9 binding
>>> +3 non-binding
>>> 
>>> I should also mention there was one -0 (binding). This was due to unit
>> test
>>> failures

Re: [VOTE] Apache Drill 0.6.0-incubating release

[Ted Dunning]

The standard practice has been drifting in incubator-land.

When I brought this up previously, I was told a few things,

1) the notices required by BSD like licenses apparently should appear in
the LICENSE file.

2) notices in the source distribution only need to include things that are
included in the source distro

3) notices in the binary distribution should include the things included in
the binary distro (clearly many more than in the source distro)

4) maven references from a pom do not invoke a requirement for notices in
the source distro.

So,

If you are talking about the source distribution, this isn't a problem.

If you are talking about notices that actually are in the LICENSE file
instead of the NOTICE file, this isn't a problem.

If you are saying that the notices aren't in the LICENSE file in the binary
distro, there is a huge problem (partly because I looked there and found
them).

My guess is that your next comment and mine as well is that it is really
hard to keep track of these requirements as they shift over time.




On Fri, Oct 10, 2014 at 6:24 AM, Grant Ingersoll 
wrote:

> Not sure, and maybe a bit pedantic, but is the NOTICE file a little thin
> (practically non-existent) given the number of 3rd party libs present?  I'm
> not an expert on what is required there, but when I compare it to projects
> I'm familiar with like Solr and Mahout, they are vastly different.
>
> I _believe_ the NOTICE file is where you are supposed to put NOTICES from
> licenses that require it. (someone else here can probably help)
>
> Beyond that, and I'm not sure if it is a blocker or not, things look good
> to the extent I tested (packaging, keys, basic run through)
>
> So, -1 if the NOTICE thing is a thing that needs to be dealt with now.
> +1 if it is not.
>
> In either case, that would be binding.
>
> -Grant
>
>
> On Oct 5, 2014, at 2:14 PM, Steven Phillips  wrote:
>
> > I would like to present the Apache Drill 0.6.0-incubating release to
> > the general incubator list for a vote.  This set of artifacts have passed
> > our drill-dev vote and incorporate a number of improvements with over 30
> > JIRAs closed in the last month.
> >
> > The vote thread can be found
> > here:
> http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201410.mbox/%3CCAA_-67fAJFB20wGX462wm7BYvoSy3PvydCPgY9uNSEj3HpQRmg%40mail.gmail.com%3E
> >
> > The vote passed with:
> > +9 binding
> > +3 non-binding
> >
> > You can find the artifacts for the release at this
> > location:http://people.apache.org/~smp/apache-drill-0.6.0.rc0/
> >
> > I look forward to your feedback.
> >
> > Thanks,
> > Steven
>
>
>

Re: [VOTE] Apache Drill 0.6.0-incubating release

[Ted Dunning]

Sean,

Are you talking about the src distribution after doing the build?

Before doing the build or after [mvn clean], there are no jars in the
distribution.

Videlicet:






*ted:apache-drill-0.6.0-incubating-src$ mvn -q
cleanted:apache-drill-0.6.0-incubating-src$ find . -name
'*.jar'ted:apache-drill-0.6.0-incubating-src$*


On Fri, Oct 10, 2014 at 7:30 AM, Sean Owen  wrote:

> I had a look, since I was just dealing with NOTICE for another
> project. The key is whether copies of the third-party libraries are
> distributed. In the case of Drill, yes there are loads of 3rd party
> jars distributed in jars/; they are not just Maven deps referenced in
> pom.xml.
>
> I am sure this will entail some entries in NOTICE just from looking at
> the deps, which aren't there. See for example
> http://www.apache.org/dev/licensing-howto.html
>
> Functionally it's trivial; from a license / legal perspective, it's
> one of the only things that matter, and ultimately it's vital to dot
> all those i's and cross those t's. It's tedious to construct the right
> NOTICE file since it will entail figuring out what third party deps
> are built in to things like hive-exec too.
>
> I have a few tips for whatever brave soul wants to take on that task.
> Some Maven plugins can do most of the legwork.
>
> On Fri, Oct 10, 2014 at 2:24 PM, Grant Ingersoll 
> wrote:
> > Not sure, and maybe a bit pedantic, but is the NOTICE file a little thin
> (practically non-existent) given the number of 3rd party libs present?  I'm
> not an expert on what is required there, but when I compare it to projects
> I'm familiar with like Solr and Mahout, they are vastly different.
> >
> > I _believe_ the NOTICE file is where you are supposed to put NOTICES
> from licenses that require it. (someone else here can probably help)
> >
> > Beyond that, and I'm not sure if it is a blocker or not, things look
> good to the extent I tested (packaging, keys, basic run through)
> >
> > So, -1 if the NOTICE thing is a thing that needs to be dealt with now.
> > +1 if it is not.
> >
> > In either case, that would be binding.
> >
> > -Grant
> >
> >
> > On Oct 5, 2014, at 2:14 PM, Steven Phillips  wrote:
> >
> >> I would like to present the Apache Drill 0.6.0-incubating release to
> >> the general incubator list for a vote.  This set of artifacts have
> passed
> >> our drill-dev vote and incorporate a number of improvements with over 30
> >> JIRAs closed in the last month.
> >>
> >> The vote thread can be found
> >> here:
> http://mail-archives.apache.org/mod_mbox/incubator-drill-dev/201410.mbox/%3CCAA_-67fAJFB20wGX462wm7BYvoSy3PvydCPgY9uNSEj3HpQRmg%40mail.gmail.com%3E
> >>
> >> The vote passed with:
> >> +9 binding
> >> +3 non-binding
> >>
> >> You can find the artifacts for the release at this
> >> location:http://people.apache.org/~smp/apache-drill-0.6.0.rc0/
> >>
> >> I look forward to your feedback.
> >>
> >> Thanks,
> >> Steven
> >
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache Drill 0.6.0-incubating release

[Ted Dunning]

Actually, the licensing howto says things like this:

In LICENSE, add a pointer <http://s.apache.org/Hqj> to the dependency's
license within the source tree and a short note summarizing its licensing:

This product bundles SuperWidget 1.2.3, which is available under a

"3-clause BSD" license.  For details, see deps/superwidget/.

Under normal circumstances, there is no need to modify NOTICE.

Over and over again, it is emphasized that NOTICE does not need to be
modified and that the reference should be in the LICENSE file.

This seems to contradict your assertion that these references need to be in
the NOTICE file.

Are you sure we are reading the same document?

On Fri, Oct 10, 2014 at 1:30 PM, Sean Owen  wrote:

> No I just went straight for the binary distribution:
>
>
> http://people.apache.org/~smp/apache-drill-0.6.0.rc0/apache-drill-0.6.0-incubating.tar.gz
>
> This contains the third-party jar files in jars/.
>
> I assume http://www.apache.org/dev/licensing-howto.html is still the
> law of the land so to speak and indicates that lots of these things
> need to be in NOTICE.
>
>
> On Oct 10, 2014 9:24 PM, "Ted Dunning"  wrote:
> >
> > Sean,
> >
> > Are you talking about the src distribution after doing the build?
> >
> > Before doing the build or after [mvn clean], there are no jars in the
> > distribution.
> >
> > Videlicet:
> >
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Apache Drill 0.6.0-incubating release

[Ted Dunning]

Drill has had previous releases stopped *precisely* because NOTICE had too
much stuff in it.  The items you mention are among these items.

I think the release is satisfactory as is.


On Sat, Oct 11, 2014 at 2:32 AM, Sean Owen  wrote:

> I am reading http://www.apache.org/dev/licensing-howto.html . Yes
> LICENSE also needs to contain more things as well. Yes, there are
> several situations where NOTICE does not need to change, but this is
> the key sentence:
>
> "Aside from Apache-licensed dependencies which supply NOTICE files of
> their own, it is uncommon for a dependency to require additions to
> NOTICE."
>
> Lots of the dependencies I see here are Apache-licensed dependencies
> with NOTICE files. The Apache License 2 clause 4 means any (relevant)
> parts of the NOTICE files must be included in a distribution, and the
> NOTICE file is the place for that*.
>
> Here's a correct (AFAIK) example from Spark:
>
> https://github.com/apache/spark/blob/master/NOTICE
> https://github.com/apache/spark/blob/master/LICENSE
>
> Some of the same dependencies are included in both.
>
> I don't see why this doesn't apply to Drill too? Unless the guidance
> above is out of date.
>
> * I am not clear whether distribution a .jar, which has its NOTICE
> file embedded, "counts". This would not be the case in an 'uber' jar
> the the project distributes, and there are some third-party uber jars
> here like hive-exec, but I don't see a Drill uber jar. Maybe that
> counts; maybe it's safer just to populate NOTICE appropriately. Or,
> avoid shipping copies of all these jars directly?
>
> On Sat, Oct 11, 2014 at 7:17 AM, Ted Dunning 
> wrote:
> > Actually, the licensing howto says things like this:
> >
> > In LICENSE, add a pointer <http://s.apache.org/Hqj> to the dependency's
> > license within the source tree and a short note summarizing its
> licensing:
> >
> > This product bundles SuperWidget 1.2.3, which is available under a
> >
> > "3-clause BSD" license.  For details, see deps/superwidget/.
> >
> > Under normal circumstances, there is no need to modify NOTICE.
> >
> > Over and over again, it is emphasized that NOTICE does not need to be
> > modified and that the reference should be in the LICENSE file.
> >
> > This seems to contradict your assertion that these references need to be
> in
> > the NOTICE file.
> >
> > Are you sure we are reading the same document?
> >
> > On Fri, Oct 10, 2014 at 1:30 PM, Sean Owen  wrote:
> >
> >> No I just went straight for the binary distribution:
> >>
> >>
> >>
> http://people.apache.org/~smp/apache-drill-0.6.0.rc0/apache-drill-0.6.0-incubating.tar.gz
> >>
> >> This contains the third-party jar files in jars/.
> >>
> >> I assume http://www.apache.org/dev/licensing-howto.html is still the
> >> law of the land so to speak and indicates that lots of these things
> >> need to be in NOTICE.
> >>
> >>
> >> On Oct 10, 2014 9:24 PM, "Ted Dunning"  wrote:
> >> >
> >> > Sean,
> >> >
> >> > Are you talking about the src distribution after doing the build?
> >> >
> >> > Before doing the build or after [mvn clean], there are no jars in the
> >> > distribution.
> >> >
> >> > Videlicet:
> >> >
> >>
> >> -
> >> 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: Bloated NOTICE files are evil

[Ted Dunning]

In any case, the NOTICE files included in every jar are preserved.  The
Drill binary release complies *exactly* with the language "include a
readable copy of the attribution notices contained within such NOTICE file".

There is no violation of OSS licenses going on here.



On Sat, Oct 11, 2014 at 6:51 AM, Sean Owen  wrote:

> On Sat, Oct 11, 2014 at 1:27 PM, Marvin Humphrey 
> wrote:
> > I admire the good-faith efforts that the Spark (and Solr) folks have put
> > in attempting to comply with their interpretation of ASF requirements,
> but I
> > don't think we should encourage podlings to emulate the current state of
> their
> > licensing documentation.
>
> Yes, but much more importantly, it is not *violating an OSS license*
> to distribute software that says 'you must include X in a NOTICE file
> if you distribute this' without including X in the NOTICE file?
>
> Yes it means greater downstream burden, yes it may have originated
> from a 'hack', but that doesn't seem to make the license not say what
> it says. Obviously I'd rather not have to do this either.
>
> It's certainly a best practice to not put things in NOTICE that aren't
> actually required. For example upstream NOTICE may refer to components
> that the downstream project does not distribute. I think it's also a
> good reason to think about whether a project actually needs to
> distribute third-party code versus merely depend on it via Maven.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: Bloated NOTICE files are evil

[Ted Dunning]

On Sat, Oct 11, 2014 at 6:51 AM, Sean Owen  wrote:

> Yes it means greater downstream burden, yes it may have originated
> from a 'hack', but that doesn't seem to make the license not say what
> it says. Obviously I'd rather not have to do this either.
>

It is a tortured and patently incorrect reading to assume that the license
requires TWO copies of such notices.

Re: Bloated NOTICE files are evil

[Ted Dunning]

On Sat, Oct 11, 2014 at 8:13 AM, Sean Owen  wrote:

> Here's another example. Drill distributes Netty 4.0.20, which is AL2
> licensed and contains a substantial NOTICE file with stuff like ...
>
>
> ---
> This product contains the extensions to Java Collections Framework which
> has
> been derived from the works by JSR-166 EG, Doug Lea, and Jason T. Greene:
>
>   * LICENSE:
> * license/LICENSE.jsr166y.txt (Public Domain)
>   * HOMEPAGE:
> * http://gee.cs.oswego.edu/cgi-bin/viewcvs.cgi/jsr166/
> *
> http://viewvc.jboss.org/cgi-bin/viewvc.cgi/jbosscache/experimental/jsr166
>

What you quote is an acknowledgment of public domain code.

How is that a problem?

Re: Bloated NOTICE files are evil

[Ted Dunning]

On Sat, Oct 11, 2014 at 8:13 AM, Sean Owen  wrote:

> Unfortunately, Netty does not include NOTICE.txt in any of its jars
> for you. This text does not appear therefore in the Drill binary
> distro. At least, I grepped up and down the whole distro and didn't
> see it, and it's not in the Netty jars.
>
> What's the theory that this meets the requirements of Netty's AL2 license?
>

The relevant part of the AL2 license says:

and If the Work includes a "NOTICE" text file as part of its distribution,
> then any Derivative Works that You distribute must include a readable copy
> of the attribution notices contained within such NOTICE file, excluding
> those notices that do not pertain to any part of the Derivative Works, in
> at least one of the following places: within a NOTICE text file distributed
> as part of the Derivative Works; within the Source form or documentation,
> if provided along with the Derivative Works; or, within a display generated
> by the Derivative Works, if and wherever such third-party notices normally
> appear.


Netty's artifacts ("its distribution") do not include a notice.  Thus,
Drill does not create one.  As far as I can tell, Netty is doing precisely
as Marvin suggests ... they have an attribution in the source and have made
a determination that they do not need a NOTICE file in the jar artifact.
The fact that they do not have such a NOTICE indicates that they do not
require us to propagate said non-existent NOTICE.

Were we to include their sources, I would expect that we would preserve
their NOTICE file since their source code includes such a thing.

To summarize:

ALv2 says that *if* a NOTICE exists in a distribution, then inclusion of
that distribution requires propagation of the content of that NOTICE.
Clearly, if such a NOTICE does not exist, there is no such burden.

Roy (in 2008, one of the original authors of the ASL) says propagating
NOTICE content willy nilly is bad and not a good thing, thus confirming the
inference that lack of a NOTICE in an included artifact implies no further
burden.

Netty does not include a NOTICE in their jars, apparently in compliance
with the license and Roy's interpretation.

Sean says that since Netty does not have such a NOTICE in their
distribution, we have to go further back up the family tree to find or
invent one and that not inventing the missing NOTICE somehow violates
Netty's ASL in spite of the fact that their license says that we don't have
to do that.

Sean further seems to imply that we have to go further back up the family
tree to find any defect in any handling of license software and take it on
ourselves to repair this defect by inventing new NOTICE content.

I say that this way lies madness.

Re: Bloated NOTICE files are evil

[Ted Dunning]

On Sat, Oct 11, 2014 at 11:08 AM, Sean Owen  wrote:

> On Sat, Oct 11, 2014 at 7:02 PM, Ted Dunning 
> wrote:
> > Netty's artifacts ("its distribution") do not include a notice.  Thus,
>
> They most certainly do. Please download the distribution of Netty 4.0.20:
>
> https://github.com/netty/netty/releases/tag/netty-4.0.20.Final
>
> and find the NOTICE.txt file.
>

You are confusing different distributions.  Netty provides a source
distribution which does include a NOTICE file.  Netty also provides binary
(jar) distributions.  These do not include a NOTICE file.

Just as the NOTICE file is different in the source and binary distributions
of Drill, so is there a difference in the source and binary distributions
of Netty.  The Drill project draws this distinction deliberately and I can
only presume the Netty project does this same.  If you think that the Netty
developers are constructing their different distributions incorrectly, you
should probably take that up with them.

Drill includes the binary distribution, not the source.  Drill faithfully
propagates all NOTICE files from that binary distribution (i.e. none).

I am not sure why you insist on confusing these two very separate things,
but you do seem to quite persistent in doing so.