Re: [VOTE] Accept Storm into the Incubator

[Hitesh Shah]

+1. 

-- Hitesh

On Sep 12, 2013, at 12:19 PM, Doug Cutting wrote:

> Discussion about the Storm proposal has subsided, issues raised now
> seemingly resolved.
> 
> I'd like to call a vote to accept Storm as a new Incubator podling.
> 
> The proposal is included below and is also at:
> 
>  https://wiki.apache.org/incubator/StormProposal
> 
> Let's keep the vote open for four working days, until 18 September.
> 
> [ ] +1 Accept Storm into the Incubator
> [ ] +0 Don't care.
> [ ] -1 Don't accept Storm because...
> 
> Doug
> 
> 
> = Storm Proposal =
> 
> == Abstract ==
> 
> Storm is a distributed, fault-tolerant, and high-performance realtime
> computation system that provides strong guarantees on the processing
> of data.
> 
> == Proposal ==
> 
> Storm is a distributed real-time computation system. Similar to how
> Hadoop provides a set of general primitives for doing batch
> processing, Storm provides a set of general primitives for doing
> real-time computation. Its use cases span stream processing,
> distributed RPC, continuous computation, and more. Storm has become a
> preferred technology for near-realtime big-data processing by many
> organizations worldwide (see a partial list at
> https://github.com/nathanmarz/storm/wiki/Powered-By). As an open
> source project, Storm’s developer community has grown rapidly to 46
> members.
> 
> == Background ==
> 
> The past decade has seen a revolution in data processing. MapReduce,
> Hadoop, and related technologies have made it possible to store and
> process data at scales previously unthinkable. Unfortunately, these
> data processing technologies are not realtime systems, nor are they
> meant to be. The lack of a "Hadoop of realtime" has become the biggest
> hole in the data processing ecosystem. Storm fills that hole.
> 
> Storm was initially developed and deployed at BackType in 2011. After
> 7 months of development BackType was acquired by Twitter in July 2011.
> Storm was open sourced in September 2011.
> 
> Storm has been under continuous development on its Github repository
> since being open-sourced. It has undergone four major releases (0.5,
> 0.6, 0.7, 0.8) and many minor ones.
> 
> 
> == Rationale ==
> 
> Storm is a general platform for low-latency big-data processing. It is
> complementary to the existing Apache projects, such as Hadoop. Many
> applications are actually exploring using both Hadoop and Storm for
> big-data processing. Bringing Storm into Apache is very beneficial to
> both Apache community and Storm community.
> 
> The rapid growth of Storm community is empowered by open source. We
> believe the Apache foundation is a great fit as the long-term home for
> Storm, as it provides an established process for community-driven
> development and decision making by consensus. This is exactly the
> model we want for future Storm development.
> 
> == Initial Goals ==
> 
>   * Move the existing codebase to Apache
>   * Integrate with the Apache development process
>   * Ensure all dependencies are compliant with Apache License version 2.0
>   * Incremental development and releases per Apache guidelines
> 
> == Current Status ==
> 
> Storm has undergone four major releases (0.5, 0.6, 0.7, 0.8) and many
> minor ones. Storm 0.9 is about to be released. Storm is being used in
> production by over 50 organizations. Storm codebase is currently
> hosted at github.com, which will seed the Apache git repository.
> 
> === Meritocracy ===
> 
> We plan to invest in supporting a meritocracy. We will discuss the
> requirements in an open forum. Several companies have already
> expressed interest in this project, and we intend to invite additional
> developers to participate. We will encourage and monitor community
> participation so that privileges can be extended to those that
> contribute.
> 
> === Community ===
> 
> The need for a low-latency big-data processing platform in the open
> source is tremendous. Storm is currently being used by at least 50
> organizations worldwide (see
> https://github.com/nathanmarz/storm/wiki/Powered-By), and is the most
> starred Java project on Github. By bringing Storm into Apache, we
> believe that the community will grow even bigger.
> 
> === Core Developers ===
> 
> Storm was started by Nathan Marz at BackType, and now has developers
> from Yahoo!, Microsoft, Alibaba, Infochimps, and many other companies.
> 
> === Alignment ===
> 
> In the big-data processing ecosystem, Storm is a very popular
> low-latency platform, while Hadoop is the primary platform for batch
> processing. We believe that it will help the further growth of
> big-data community by having Hadoop and Storm aligned within Apache
> foundation. The alignment is also beneficial to other Apache
> communities (such as Zookeeper, Thrift, Mesos). We could include
> additional sub-projects, Storm-on-YARN and Storm-on-Mesos, in the near
> future.
> 
> == Known Risks ==
> 
> === Orphaned Products ===
> 
> The risk of the Storm project being abandoned is minimal. 

[VOTE] Release Apache Tez-0.2.0-incubating RC0

[Hitesh Shah]

Hello folks,

I have created a tez-0.2.0-incubating release candidate (rc0). This is the 
first release for Tez. Therefore, please do not be gentle. 

GIT source tag: 
https://git-wip-us.apache.org/repos/asf/incubator-tez/repo?p=incubator-tez.git;a=log;h=refs/tags/release-0.2.0-rc0
Staging site: 
http://people.apache.org/~hitesh/tez-release-rc/tez-0.2.0-incubating-rc0/
Nexus Staging URL: 
https://repository.apache.org/content/repositories/orgapachetez-002/

PGP release keys: 
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA9510905F0B000F0
KEYS file also available at 
https://dist.apache.org/repos/dist/release/incubator/tez/KEYS

One can look into the issues fixed in this release at: 
https://issues.apache.org/jira/browse/TEZ/fixforversion/12324349

Vote will be open for 72 hours.

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

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

Re: [VOTE] Release Apache Tez-0.2.0-incubating RC0

[Hitesh Shah]

Thanks for the review, Sebb, 

Have already updated NOTICE.txt in the master branch for future releases and 
made a note of the other points in our how to release guide. 

Do you recommended starting a new VOTE thread for the re-wording with respect 
to the 72 hrs period or can I just continue with this one? I had assumed I 
would be keeping the vote open until enough IPMC votes were received. At this 
point, I believe we have only one IPMC vote ( from Oliver Lamy). 

thanks
-- Hitesh

On Nov 26, 2013, at 8:37 AM, sebb wrote:

> On 26 November 2013 00:33, Hitesh Shah  wrote:
>> Hello folks,
>> 
>> I have created a tez-0.2.0-incubating release candidate (rc0). This is the 
>> first release for Tez. Therefore, please do not be gentle.
>> 
>> GIT source tag: 
>> https://git-wip-us.apache.org/repos/asf/incubator-tez/repo?p=incubator-tez.git;a=log;h=refs/tags/release-0.2.0-rc0
> 
> Minor nit: the NOTICE.txt file wraps in the wrong place.
> 
>>>> 
> This product includes software developed at The Apache Software
> Foundation (http://www.apache.org/).
> <<<
> 
> should be
> 
>>>> 
> This product includes software developed at
> The Apache Software Foundation (http://www.apache.org/).
> <<<
> 
> Should be fixed for any future release (or if this one has to be redone)
> 
>> Staging site: 
>> http://people.apache.org/~hitesh/tez-release-rc/tez-0.2.0-incubating-rc0/
> 
> [Not mandatory, but] if you stage at the following URL:
> 
> https://dist.apache.org/repos/dist/dev/incubator/tez/
> 
> it's then easy to rename the files to the release directory strucure here:
> 
> https://dist.apache.org/repos/dist/release/incubator/tez/
> 
>> Nexus Staging URL: 
>> https://repository.apache.org/content/repositories/orgapachetez-002/
>> 
>> PGP release keys: 
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA9510905F0B000F0
>> KEYS file also available at 
>> https://dist.apache.org/repos/dist/release/incubator/tez/KEYS
>> 
>> One can look into the issues fixed in this release at: 
>> https://issues.apache.org/jira/browse/TEZ/fixforversion/12324349
>> 
>> Vote will be open for 72 hours.
> 
> Minor nit: that should be "for at least 72 hours"; the 72 hours is a
> *minimum* to ensure that people have time to review and vote.
> 
>> [ ] +1 approve
>> [ ] +0 no opinion
>> [ ] -1 disapprove (and reason why)
>> 
>> thanks
>> -- Hitesh
>> -
>> 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: [DISCOUSS] Release Apache Tez-0.2.0-incubating RC0

[Hitesh Shah]

> Hi all
> 
> Where is the RAT scan?
> 
> Greetings Raphael
> 
> Am 26.11.13 01:33, schrieb Hitesh Shah:
>> Hello folks,
>> 
>> I have created a tez-0.2.0-incubating release candidate (rc0). This is the 
>> first release for Tez. Therefore, please do not be gentle.
>> 
>> GIT source tag: 
>> https://git-wip-us.apache.org/repos/asf/incubator-tez/repo?p=incubator-tez.git;a=log;h=refs/tags/release-0.2.0-rc0
>> Staging site: 
>> http://people.apache.org/~hitesh/tez-release-rc/tez-0.2.0-incubating-rc0/
>> Nexus Staging URL: 
>> https://repository.apache.org/content/repositories/orgapachetez-002/
>> 
>> PGP release keys: 
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA9510905F0B000F0
>> KEYS file also available at 
>> https://dist.apache.org/repos/dist/release/incubator/tez/KEYS
>> 
>> One can look into the issues fixed in this release at: 
>> https://issues.apache.org/jira/browse/TEZ/fixforversion/12324349
>> 
>> Vote will be open for 72 hours.
>> 
>> [ ] +1 approve
>> [ ] +0 no opinion
>> [ ] -1 disapprove (and reason why)
>> 
>> thanks
>> -- Hitesh
>> -
>> 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

[RESULT][VOTE] Release Apache Tez-0.2.0-incubating RC0

[Hitesh Shah]

Hello all,

Closing the vote since 72 hours have passed.

With the required 3 IPMC votes and no -1s, this vote passes.

+1s (binding - IPMC )

Alan Gates
Olivier Lamy
Arun C Murthy

+1s (non-binding)

Hitesh Shah
Lianhui Wang
Mike Liddell
Cheolsoo Park
Siddharth Seth
Mark Wagner
Tsuyoshi Ozawa
Gunther Hagleitner

-1s (none )

Thanks everyone for voting. I will send out an announce email later once the 
bits are available on the apache mirrors. 

thanks
-- Hitesh

On Nov 25, 2013, at 4:33 PM, Hitesh Shah wrote:

> Hello folks,
> 
> I have created a tez-0.2.0-incubating release candidate (rc0). This is the 
> first release for Tez. Therefore, please do not be gentle. 
> 
> GIT source tag: 
> https://git-wip-us.apache.org/repos/asf/incubator-tez/repo?p=incubator-tez.git;a=log;h=refs/tags/release-0.2.0-rc0
> Staging site: 
> http://people.apache.org/~hitesh/tez-release-rc/tez-0.2.0-incubating-rc0/
> Nexus Staging URL: 
> https://repository.apache.org/content/repositories/orgapachetez-002/
> 
> PGP release keys: 
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA9510905F0B000F0
> KEYS file also available at 
> https://dist.apache.org/repos/dist/release/incubator/tez/KEYS
> 
> One can look into the issues fixed in this release at: 
> https://issues.apache.org/jira/browse/TEZ/fixforversion/12324349
> 
> Vote will be open for 72 hours.
> 
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
> 
> thanks
> -- Hitesh


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

[ANNOUNCE] Apache Tez 0.2.0-incubating Released

[Hitesh Shah]

The Apache Tez team is proud to announce the first release of Apache Tez - 
version 0.2.0-incubating.

Apache Tez is an application framework which allows for a complex 
directed-acyclic-graph of tasks for processing data and is built atop Apache 
Hadoop YARN.
More details on Apache Tez can be found at http://tez.incubator.apache.org/

The release bits are available at: 
http://www.apache.org/dyn/closer.cgi/incubator/tez/tez-0.2.0-incubating/

The released maven artifacts have also been made available on 
repository.apache.org.

We would like to thank all the contributors that made this release possible.

thanks
Hitesh Shah on behalf of The Apache Tez Team
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[VOTE] Release Apache Tez-0.3.0-incubating RC0

[Hitesh Shah]

Hello folks,

I have created a tez-0.3.0-incubating release candidate (rc0). This is the 
second release for Tez. 

GIT source tag: 
https://git-wip-us.apache.org/repos/asf/incubator-tez/repo?p=incubator-tez.git;a=log;h=refs/tags/release-0.3.0-incubating-rc0
Staging site: 
https://dist.apache.org/repos/dist/dev/incubator/tez/0.3.0-incubating-rc0/
Nexus Staging URL: 
https://repository.apache.org/content/repositories/orgapachetez-1002

PGP release keys: 
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA9510905F0B000F0
KEYS file also available at 
https://dist.apache.org/repos/dist/release/incubator/tez/KEYS

One can look into the issues fixed in this release at: 
https://issues.apache.org/jira/browse/TEZ/fixforversion/12325655 or look at the 
CHANGES.txt in the release tarball.

Vote will be open for at least 72 hours ( until the required number of IPMC 
votes are obtained ).

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

For folks not familiar with vetting a release, please refer to 
http://incubator.apache.org/guides/releasemanagement.html#check-list

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

Re: [VOTE] Release Apache Tez-0.3.0-incubating RC0

[Hitesh Shah]

Thanks for the review, Sebb. 

NOTICE file updated in trunk for the next release. I also made a change to our 
how-to-release documentation to ensure that the git hash and svn revisions are 
sent out in future votes.

thanks
-- Hitesh

On Feb 24, 2014, at 4:25 AM, sebb wrote:

> On 23 February 2014 19:31, Hitesh Shah  wrote:
>> Hello folks,
>> 
>> I have created a tez-0.3.0-incubating release candidate (rc0). This is the 
>> second release for Tez.
>> 
>> GIT source tag: 
>> https://git-wip-us.apache.org/repos/asf/incubator-tez/repo?p=incubator-tez.git;a=log;h=refs/tags/release-0.3.0-incubating-rc0
>> Staging site: 
>> https://dist.apache.org/repos/dist/dev/incubator/tez/0.3.0-incubating-rc0/
>> Nexus Staging URL: 
>> https://repository.apache.org/content/repositories/orgapachetez-1002
>> 
>> PGP release keys: 
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA9510905F0B000F0
>> KEYS file also available at 
>> https://dist.apache.org/repos/dist/release/incubator/tez/KEYS
> 
> Very good set of links.
> Provides everything needed for reviewers to check the release contents.
> Ideally the GIT hash should also be included, as tags are not immutable.
> And for the mail archives it would be useful to include the SVN
> revision for the dist/dev/ tag.
> 
> One minor point - the NOTICE file still says 2013; that should be
> updated for the next release (assuming substantive changes have been
> made in 2014)
> 
>> One can look into the issues fixed in this release at: 
>> https://issues.apache.org/jira/browse/TEZ/fixforversion/12325655 or look at 
>> the CHANGES.txt in the release tarball.
>> 
>> Vote will be open for at least 72 hours ( until the required number of IPMC 
>> votes are obtained ).
>> 
>> [ ] +1 approve
>> [ ] +0 no opinion
>> [ ] -1 disapprove (and reason why)
>> 
>> For folks not familiar with vetting a release, please refer to 
>> http://incubator.apache.org/guides/releasemanagement.html#check-list
>> 
>> thanks
>> -- Hitesh
>> -
>> 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

[CANCEL] [VOTE] Release Apache Tez-0.3.0-incubating RC0

[Hitesh Shah]

The vote is being cancelled due to the Pig team finding an issue when testing 
against the release candidate. 

thanks
-- Hitesh

On Feb 23, 2014, at 11:31 AM, Hitesh Shah wrote:

> Hello folks,
> 
> I have created a tez-0.3.0-incubating release candidate (rc0). This is the 
> second release for Tez. 
> 
> GIT source tag: 
> https://git-wip-us.apache.org/repos/asf/incubator-tez/repo?p=incubator-tez.git;a=log;h=refs/tags/release-0.3.0-incubating-rc0
> Staging site: 
> https://dist.apache.org/repos/dist/dev/incubator/tez/0.3.0-incubating-rc0/
> Nexus Staging URL: 
> https://repository.apache.org/content/repositories/orgapachetez-1002
> 
> PGP release keys: 
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA9510905F0B000F0
> KEYS file also available at 
> https://dist.apache.org/repos/dist/release/incubator/tez/KEYS
> 
> One can look into the issues fixed in this release at: 
> https://issues.apache.org/jira/browse/TEZ/fixforversion/12325655 or look at 
> the CHANGES.txt in the release tarball.
> 
> Vote will be open for at least 72 hours ( until the required number of IPMC 
> votes are obtained ).
> 
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
> 
> For folks not familiar with vetting a release, please refer to 
> http://incubator.apache.org/guides/releasemanagement.html#check-list
> 
> thanks
> -- Hitesh


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

[VOTE] Release Apache Tez-0.3.0-incubating RC1

[Hitesh Shah]

Hello folks,

I have created a tez-0.3.0-incubating release candidate (rc1). This is the 
second release for Tez.

The previous RC was cancelled due to a bug discovered when the RC was tested 
against downstream projects.

GIT source tag: 
https://git-wip-us.apache.org/repos/asf/incubator-tez/repo?p=incubator-tez.git;a=log;h=refs/tags/release-0.3.0-incubating-rc1
 ( commit hash 6987e18f6b3c5358e1eb125bc2d63be39f71e892 )
Staging site: 
https://dist.apache.org/repos/dist/dev/incubator/tez/0.3.0-incubating-rc1/ ( 
svn revision 4508 ) 
Nexus Staging URL: 
https://repository.apache.org/content/repositories/orgapachetez-1003

PGP release keys: 
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA9510905F0B000F0
KEYS file also available at 
https://dist.apache.org/repos/dist/release/incubator/tez/KEYS

One can look into the issues fixed in this release at: 
https://issues.apache.org/jira/browse/TEZ/fixforversion/12325655 or look at the 
CHANGES.txt in the release tarball.

Vote will be open for at least 72 hours ( until the required number of IPMC 
votes are obtained ).

[ ] +1 approve
[ ] +0 no opinion
[ ] -1 disapprove (and reason why)

For folks not familiar with vetting a release, please refer to 
http://incubator.apache.org/guides/releasemanagement.html#check-list

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

Re: [VOTE] Release Apache Tez-0.3.0-incubating RC1

[Hitesh Shah]

Thanks for the suggestion, Sebb. I went ahead and moved the original SHA into 
.sha file and re-generated the SHA1 into the .sha1 file. 

@Alan, @sebb, would either of you mind verifying the modified files?

I will follow-up separately with other folks who did their +1's to re-check the 
files.

thanks
-- Hitesh

On Feb 28, 2014, at 12:32 PM, sebb wrote:

> On 28 February 2014 19:48, Alan Gates  wrote:
>> +1
>> 
>> One note is that the signatures given say sha1, but you actually have use 
>> openssl sha to get the same values.  If you do sha1sum (which was my first 
>> assumption anyway) you get a different non-matching values.  You might want 
>> to change the filename to "tez-0.3.0-incubating.tar.gz.sha"
> 
> Or better, use SHA-1 rather than SHA (aka SHA-0) which is relatively
> weak and not well supported by tools.
> 
> I think it would be OK just to replace the sha1 file contents with the
> appropriate SHA-1 hash.
> No need to respin the release, as it that has not changed, but it
> would make sense to get a few people to check the updated hash works
> for them.
> 
> If you leave the sha1 file with SHA-0 contents, that is potentially
> going to cause problems for downloaders; they won't be expecting a
> SHA-0 hash in that file.
> 
>> Other than that, checked the signatures, looked at LICENSE, NOTICE, 
>> DISCLAIMER, built and ran the unit tests.  All looks good.
>> 
>> Alan.
>> 
>> On Feb 28, 2014, at 11:28 AM, Mahadev Konar  wrote:
>> 
>>> +1 (binding)
>>> 
>>> - verified signatures and ran some sample test jobs.
>>> 
>>> 
>>> 
>>> Mahadev Konar
>>> Hortonworks Inc.
>>> http://hortonworks.com/
>>> 
>>> 
>>> On Fri, Feb 28, 2014 at 8:05 AM, Jason Lowe  wrote:
>>>> +1 (non-binding)
>>>> 
>>>> - Verified signatures
>>>> - Built from source, installed on single-node cluster
>>>> - Ran  some sample Tez jobs
>>>> 
>>>> Jason
>>>> 
>>>> 
>>>> On 02/25/2014 06:28 PM, Hitesh Shah wrote:
>>>>> 
>>>>> Hello folks,
>>>>> 
>>>>> I have created a tez-0.3.0-incubating release candidate (rc1). This is the
>>>>> second release for Tez.
>>>>> 
>>>>> The previous RC was cancelled due to a bug discovered when the RC was
>>>>> tested against downstream projects.
>>>>> 
>>>>> GIT source tag:
>>>>> https://git-wip-us.apache.org/repos/asf/incubator-tez/repo?p=incubator-tez.git;a=log;h=refs/tags/release-0.3.0-incubating-rc1
>>>>> ( commit hash 6987e18f6b3c5358e1eb125bc2d63be39f71e892 )
>>>>> Staging site:
>>>>> https://dist.apache.org/repos/dist/dev/incubator/tez/0.3.0-incubating-rc1/
>>>>>  (
>>>>> svn revision 4508 )
>>>>> Nexus Staging URL:
>>>>> https://repository.apache.org/content/repositories/orgapachetez-1003
>>>>> 
>>>>> PGP release keys:
>>>>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA9510905F0B000F0
>>>>> KEYS file also available at
>>>>> https://dist.apache.org/repos/dist/release/incubator/tez/KEYS
>>>>> 
>>>>> One can look into the issues fixed in this release at:
>>>>> https://issues.apache.org/jira/browse/TEZ/fixforversion/12325655 or look 
>>>>> at
>>>>> the CHANGES.txt in the release tarball.
>>>>> 
>>>>> Vote will be open for at least 72 hours ( until the required number of
>>>>> IPMC votes are obtained ).
>>>>> 
>>>>> [ ] +1 approve
>>>>> [ ] +0 no opinion
>>>>> [ ] -1 disapprove (and reason why)
>>>>> 
>>>>> For folks not familiar with vetting a release, please refer to
>>>>> http://incubator.apache.org/guides/releasemanagement.html#check-list
>>>>> 
>>>>> thanks
>>>>> -- Hitesh
>>>> 
>>>> 
>>>> 
>>>> -
>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>>> 
>>> 
>>> --
>>> 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 conf

Re: [VOTE] Release Apache Tez-0.3.0-incubating RC1

[Hitesh Shah]

Thanks for verifying it, @sebb. 

Just left it in there for now in case anyone wanted to double check. I will 
skip moving it when I migrate the bits to the release area. 

thanks
-- Hitesh

On Feb 28, 2014, at 4:45 PM, sebb wrote:

> On 28 February 2014 21:44, Hitesh Shah  wrote:
>> Thanks for the suggestion, Sebb. I went ahead and moved the original SHA 
>> into .sha file and re-generated the SHA1 into the .sha1 file.
>> 
>> @Alan, @sebb, would either of you mind verifying the modified files?
> 
> .sha1 now looks OK.
> 
> Not sure its worth keeping the sha (SHA-0) file - I think that will
> just be confusing.
> 
>> I will follow-up separately with other folks who did their +1's to re-check 
>> the files.
>> 
>> thanks
>> -- Hitesh
>> 
>> On Feb 28, 2014, at 12:32 PM, sebb wrote:
>> 
>>> On 28 February 2014 19:48, Alan Gates  wrote:
>>>> +1
>>>> 
>>>> One note is that the signatures given say sha1, but you actually have use 
>>>> openssl sha to get the same values.  If you do sha1sum (which was my first 
>>>> assumption anyway) you get a different non-matching values.  You might 
>>>> want to change the filename to "tez-0.3.0-incubating.tar.gz.sha"
>>> 
>>> Or better, use SHA-1 rather than SHA (aka SHA-0) which is relatively
>>> weak and not well supported by tools.
>>> 
>>> I think it would be OK just to replace the sha1 file contents with the
>>> appropriate SHA-1 hash.
>>> No need to respin the release, as it that has not changed, but it
>>> would make sense to get a few people to check the updated hash works
>>> for them.
>>> 
>>> If you leave the sha1 file with SHA-0 contents, that is potentially
>>> going to cause problems for downloaders; they won't be expecting a
>>> SHA-0 hash in that file.
>>> 
>>>> Other than that, checked the signatures, looked at LICENSE, NOTICE, 
>>>> DISCLAIMER, built and ran the unit tests.  All looks good.
>>>> 
>>>> Alan.
>>>> 
>>>> On Feb 28, 2014, at 11:28 AM, Mahadev Konar  
>>>> wrote:
>>>> 
>>>>> +1 (binding)
>>>>> 
>>>>> - verified signatures and ran some sample test jobs.
>>>>> 
>>>>> 
>>>>> 
>>>>> Mahadev Konar
>>>>> Hortonworks Inc.
>>>>> http://hortonworks.com/
>>>>> 
>>>>> 
>>>>> On Fri, Feb 28, 2014 at 8:05 AM, Jason Lowe  wrote:
>>>>>> +1 (non-binding)
>>>>>> 
>>>>>> - Verified signatures
>>>>>> - Built from source, installed on single-node cluster
>>>>>> - Ran  some sample Tez jobs
>>>>>> 
>>>>>> Jason
>>>>>> 
>>>>>> 
>>>>>> On 02/25/2014 06:28 PM, Hitesh Shah wrote:
>>>>>>> 
>>>>>>> Hello folks,
>>>>>>> 
>>>>>>> I have created a tez-0.3.0-incubating release candidate (rc1). This is 
>>>>>>> the
>>>>>>> second release for Tez.
>>>>>>> 
>>>>>>> The previous RC was cancelled due to a bug discovered when the RC was
>>>>>>> tested against downstream projects.
>>>>>>> 
>>>>>>> GIT source tag:
>>>>>>> https://git-wip-us.apache.org/repos/asf/incubator-tez/repo?p=incubator-tez.git;a=log;h=refs/tags/release-0.3.0-incubating-rc1
>>>>>>> ( commit hash 6987e18f6b3c5358e1eb125bc2d63be39f71e892 )
>>>>>>> Staging site:
>>>>>>> https://dist.apache.org/repos/dist/dev/incubator/tez/0.3.0-incubating-rc1/
>>>>>>>  (
>>>>>>> svn revision 4508 )
>>>>>>> Nexus Staging URL:
>>>>>>> https://repository.apache.org/content/repositories/orgapachetez-1003
>>>>>>> 
>>>>>>> PGP release keys:
>>>>>>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA9510905F0B000F0
>>>>>>> KEYS file also available at
>>>>>>> https://dist.apache.org/repos/dist/release/incubator/tez/KEYS
>>>>>>> 
>>>>>>> One can look into the issues fixed in this release at:
>>>>>>> https://issues.apache.org/jira/browse/TEZ/fixforversion/12325655 or 
>>>>>>> look at
>>>

[RESULT][VOTE] Release Apache Tez-0.3.0-incubating RC1

[Hitesh Shah]

Hello all,

Closing the vote since 72 hours have passed.

With the required 3 IPMC votes and no -1s, this vote passes.

+1s (binding - IPMC )

Arun C Murthy
Alan Gates
Mahadev Konar

+1s (non-binding)

Hitesh Shah
Chen He
Daniel Dai
Tsuyoshi Ozawa
Rohini Palaniswamy
Jonathan Eagles
Siddharth Seth
Jason Lowe
Gunther Hagleitner

-1s (none )

Thanks everyone for voting. I will send out an announce email later once the 
bits are available on the apache mirrors. 

thanks
-- Hitesh


On Feb 25, 2014, at 4:28 PM, Hitesh Shah wrote:

> Hello folks,
> 
> I have created a tez-0.3.0-incubating release candidate (rc1). This is the 
> second release for Tez.
> 
> The previous RC was cancelled due to a bug discovered when the RC was tested 
> against downstream projects.
> 
> GIT source tag: 
> https://git-wip-us.apache.org/repos/asf/incubator-tez/repo?p=incubator-tez.git;a=log;h=refs/tags/release-0.3.0-incubating-rc1
>  ( commit hash 6987e18f6b3c5358e1eb125bc2d63be39f71e892 )
> Staging site: 
> https://dist.apache.org/repos/dist/dev/incubator/tez/0.3.0-incubating-rc1/ ( 
> svn revision 4508 ) 
> Nexus Staging URL: 
> https://repository.apache.org/content/repositories/orgapachetez-1003
> 
> PGP release keys: 
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA9510905F0B000F0
> KEYS file also available at 
> https://dist.apache.org/repos/dist/release/incubator/tez/KEYS
> 
> One can look into the issues fixed in this release at: 
> https://issues.apache.org/jira/browse/TEZ/fixforversion/12325655 or look at 
> the CHANGES.txt in the release tarball.
> 
> Vote will be open for at least 72 hours ( until the required number of IPMC 
> votes are obtained ).
> 
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
> 
> For folks not familiar with vetting a release, please refer to 
> http://incubator.apache.org/guides/releasemanagement.html#check-list
> 
> thanks
> -- Hitesh


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

[ANNOUNCE] Apache Tez 0.3.0-incubating Released

[Hitesh Shah]

The Apache Tez team is proud to announce the latest release of Apache Tez - 
version 0.3.0-incubating.

Apache Tez is an application framework which allows for a complex 
directed-acyclic-graph of tasks for processing data and is built atop Apache 
Hadoop YARN.
More details on Apache Tez can be found at http://tez.incubator.apache.org/

The release bits are available at: 
http://www.apache.org/dyn/closer.cgi/incubator/tez/tez-0.3.0-incubating/

The released maven artifacts have also been made available on 
repository.apache.org.

We would like to thank all the contributors that made this release possible.

thanks
Hitesh Shah on behalf of The Apache Tez Team
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Tez-0.4.0-incubating RC1

[Hitesh Shah]

+1 (non-binding)

Verified checksums, built from source and ran basic example jobs. 

— Hitesh

On Apr 1, 2014, at 2:42 PM, Siddharth Seth  wrote:

> I have created a tez-0.4.0-incubating release candidate (rc1).
> 
> This includes license and notice files missing from rc0 release artifacts
> (the javadoc artifact has these files under resources/META-INF instead of
> directly under META-INF)
> 
> GIT source tag:
> https://git-wip-us.apache.org/repos/asf/incubator-tez/repo?p=incubator-tez.git;a=log;h=refs/tags/release-0.4.0-incubating-rc1
> (git commit 145c730c8d1cea863185b2a3354b19f2ab21addd)
> 
> Staging site:
> https://dist.apache.org/repos/dist/dev/incubator/tez/0.4.0-incubating-rc1
> (svn revision 4929)
> 
> Nexus Staging URL:
> *https://repository.apache.org/content/repositories/orgapachetez-1005/
> *
> 
> PGP release keys:
> http://pgp.mit.edu/pks/lookup?op=get&search=0x477E02D33DD51430
> KEYS file available at
> https://dist.apache.org/repos/dist/release/incubator/tez/KEYS
> 
> List of issues fixed in the release:
> https://issues.apache.org/jira/browse/TEZ/fixforversion/12326283/
> Also available in CHANGES.txt within the release tarball.
> 
> Vote will be open for at least 72 hours ( until the required number of IPMC
> votes are obtained
> ).
> 
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove (and reason why)
> 
> For folks not familiar with vetting a release, please refer to
> http://incubator.apache.org/guides/releasemanagement.html#check-list
> 
> Thanks
> - Sid


-- 
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: [VOTE] Accept Stratosphere into the incubator

[Hitesh Shah]

+1 (non-binding)

— Hitesh 

On Apr 10, 2014, at 10:42 AM, Alan Gates  wrote:

> Based on the results of the discussion thread 
> (http://mail-archives.apache.org/mod_mbox/incubator-general/201403.mbox/%3CCE562EE9-968C-420E-A719-8C08CDAC99F8%40hortonworks.com%3E
>  in particular notice the discussion on name change in the disucssion ), I 
> would like to call a vote on accepting Stratosphere into the incubator.
> 
> [ ] +1 Accept Stratosphere into the Incubator
> [ ] +0 Indifferent to the acceptance of Stratosphere
> [ ] -1 Do not accept Stratosphere because …
> 
> The vote will be open until Monday April 14 18:00 UTC.
> 
> https://wiki.apache.org/incubator/StratosphereProposal
> 
> = Stratosphere =
> == Abstract ==
> Stratosphere is an open source system for parallel data analysis. 
> Stratosphere deeply integrates MapReduce and database technologies to provide 
> expressive and optimizable programming interfaces and at the same time 
> efficient and scalable execution.
> 
> == Proposal ==
> Stratosphere is an open source system for expressive, declarative, fast, and 
> efficient data analysis. Stratosphere combines the scalability and 
> programming flexibility of distributed MapReduce-like platforms with the 
> efficiency, out-of-core execution, and query optimization capabilities found 
> in parallel databases.
> 
> == Background ==
> There is currently a need for general-purpose cluster computing platforms 
> that are compatible with the Hadoop ecosystem, are more efficient, easier to 
> use, and can support more applications than Hadoop MapReduce, but are not 
> restricted to a specific data model and language (such as the relational 
> model and a variant of SQL). Stratosphere fulfils these needs.
> 
> Stratosphere exposes expressive APIs in Java and Scala (conceptually similar 
> to Spark, Cascading, Scalding) that allow arbitrary user-defined functions in 
> the same language and data model that the program is written in. Stratosphere 
> programs pass through a cost-based optimizer that finds the best execution 
> path for these programs depending on the data and cluster characteristics. 
> The design and implementation of Stratosphere is based on research that 
> generalizes query optimizers in relational databases. Stratosphere has a 
> distributed runtime that is architected upon the principles of parallel 
> databases, providing true pipelining (a basis for stream processing) and 
> efficient out-of-core algorithms for grouping, sorting, joining, and 
> aggregating data. Stratosphere provides first-class support for iterative 
> algorithms via a built-in iterate operator, covering Machine Learning and 
> graph analysis use cases. It achieves performance similar to Apache Giraph 
> without being a specialized graph processing system.
> 
> Stratosphere has undergone three major releases (v0.1, v0.2, v0.4) and some 
> minor ones.
> 
> == Rationale ==
> Stratosphere started out in 2008 as a research project by the Technical 
> University of Berlin, the Humboldt University of Berlin, and the Hasso 
> Plattner Institute, and has received subsequent funding from the German 
> Research Council, the European Institute of Innovation and Technology, the 
> European Commision, and industry.
> 
> The traction of Stratosphere has by far exceeded our initial expectations, 
> and we are therefore seeking an organizational long-term home for 
> Stratosphere beyond the University walls that will house and further 
> encourage contributors from companies and other organizations that are 
> interested in Stratosphere. We believe that the Apache Software Foundation is 
> the ideal home for Stratosphere. Stratosphere integrates with several 
> existing Apache projects, such as HDFS, YARN, HBase, and Avro. The team is 
> familiar with the Apache processes and fully subscribes to the Apache 
> mission. One of the proposing members is a long-time Apache contributor and 
> PMC member.
> 
> == Initial Goals ==
> * Move the existing codebase to Apache
> * Integrate with the Apache development process
> * Ensure all dependencies are compliant with Apache License version 2.0
> * Incremental development and releases per Apache guidelines
> 
> == Current Status ==
> === Meritocracy ===
> Stratosphere operated on meritocratic principles from the get go. The initial 
> project proposal submitted to the German Research Council in 2008 stated that 
> all code developed in the project will be released as open source under the 
> Apache 2 license. Currently, all the discussions pertaining to Stratosphere 
> development are public on 
> [[https://github.com/stratosphere/stratosphere|GitHub]]  and our 
> [[https://groups.google.com/forum/#!forum/stratosphere-dev|mailing list]]. 
> The current incubation proposal includes the major code contributors to 
> Stratosphere. Several additional people have worked on the Stratosphere 
> codebase for research prototypes and industry use cases and would be 
> interested in becoming committers.

Re: [VOTE] Accept Parquet into the incubator

[Hitesh Shah]

+1 (non-binding)

— Hitesh

On May 18, 2014, at 2:15 PM, Chris Aniszczyk  wrote:

> Based on the results of the discussion thread:
> http://mail-archives.apache.org/mod_mbox/incubator-general/201405.mbox/%3CCAJg1wMRGhLu4P7LeVQB%2B5K0C-fr-pw2448uj%3D6-3zHag4F1EbA%40mail.gmail.com%3E
> 
> I would like to call a vote on accepting Parquet into the incubator.
> https://wiki.apache.org/incubator/ParquetProposal
> 
> [ ] +1 Accept Parquet into the Incubator
> [ ] +0 Indifferent to the acceptance of Parquet
> [ ] -1 Do not accept Parquet because ...
> 
> The vote will be open until Thursday May 22nd 18:00 UTC.
> 
> = Parquet Proposal =
> 
> == Abstract ==
> Parquet is a columnar storage format for Hadoop.
> 
> == Proposal ==
> 
> We created Parquet to make the advantages of compressed, efficient columnar
> data representation available to any project in the Hadoop ecosystem,
> regardless of the choice of data processing framework, data model, or
> programming language.
> 
> == Background ==
> 
> Parquet is built from the ground up with complex nested data structures in
> mind, and uses the repetition/definition level approach to encoding such
> data structures, as popularized by Google Dremel (
> https://blog.twitter.com/2013/dremel-made-simple-with-parquet). We believe
> this approach is superior to simple flattening of nested name spaces.
> 
> Parquet is built to support very efficient compression and encoding
> schemes. Parquet allows compression schemes to be specified on a per-column
> level, and is future-proofed to allow adding more encodings as they are
> invented and implemented. We separate the concepts of encoding and
> compression, allowing parquet consumers to implement operators that work
> directly on encoded data without paying decompression and decoding penalty
> when possible.
> 
> == Rationale ==
> 
> Parquet is built to be used by anyone. We believe that an efficient,
> well-implemented columnar storage substrate should be useful to all
> frameworks without the cost of extensive and difficult to set up
> dependencies.
> 
> Furthermore, the rapid growth of Parquet community is empowered by open
> source. We believe the Apache foundation is a great fit as the long-term
> home for Parquet, as it provides an established process for
> community-driven development and decision making by consensus. This is
> exactly the model we want for future Parquet development.
> 
> == Initial Goals ==
> 
> * Move the existing codebase to Apache
> * Integrate with the Apache development process
> * Ensure all dependencies are compliant with Apache License version 2.0
> * Incremental development and releases per Apache guidelines
> 
> == Current Status ==
> 
> Parquet has undergone 2 major releases:
> https://github.com/Parquet/parquet-format/releases of the core format and
> 22 releases: https://github.com/Parquet/parquet-mr/releases of the
> supporting set of Java libraries.
> 
> The Parquet source is currently hosted at GitHub, which will seed the
> Apache git repository.
> 
> === Meritocracy ===
> 
> We plan to invest in supporting a meritocracy. We will discuss the
> requirements in an open forum. Several companies have already expressed
> interest in this project, and we intend to invite additional developers to
> participate. We will encourage and monitor community participation so that
> privileges can be extended to those that contribute.
> 
> === Community ===
> 
> There is a large need for an advanced columnar storage format for Hadoop.
> Parquet is being used in production by many organizations (see
> https://github.com/Parquet/parquet-mr/blob/master/PoweredBy.md)
> 
> * Cloudera: https://twitter.com/HenryR/statuses/324222874011451392
> * Criteo: https://twitter.com/julsimon/statuses/312114074911666177
> * Salesforce: https://twitter.com/TwitterOSS/statuses/392734610116726784
> * Stripe: https://twitter.com/avibryant/statuses/391339949250715648
> * Twitter: https://twitter.com/J_/statuses/315844725611581441
> 
> By bringing Parquet into Apache, we believe that the community will grow
> even bigger.
> 
> === Core Developers ===
> 
> Parquet was initially developed as a collaboration between Twitter,
> Cloudera and Criteo.
> 
> See
> https://blog.twitter.com/2013/announcing-parquet-10-columnar-storage-for-hadoop
> 
> === Alignment ===
> 
> We believe that having Parquet at Apache will help further the growth of
> the big-data community, as it will encourage cooperation within the greater
> ecosystem of projects spawned by Apache Hadoop. The alignment is also
> beneficial to other Apache communities (such as Hadoop, Hive, Avro).
> 
> == Known Risks ==
> 
> === Orphaned Products ===
> 
> The risk of the Parquet project being abandoned is minimal. There are many
> organizations using Parquet in production, including Twitter, Cloudera,
> Stripe, and Salesforce (
> http://blog.cloudera.com/blog/2013/10/parquet-at-salesforce-com/).
> 
> === Inexperience with Open Source ===
> 
> Parquet has existed as a healthy

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

[Hitesh Shah]

Hi folks, 

To be very clear, the project's source of truth has always been its status 
file: 
https://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/tez.xml

For the tez website, http://tez.incubator.apache.org/team-list.html, the onus 
was for the committers to test out their commit privileges, update the teamlist 
in the source tree and publish the updated website. I understand it has created 
a lot of confusion for folks outside of the project. I will go ahead and update 
the internal list to match the source of truth.

Even though I am well aware that some of the initial committers on the 
incubator proposal have not been active ( my take on active is as simple as 
sending a single mail to any mailing list ) on the project since inception, my 
understanding had been that all committers and mentors from an incubator 
podling become PMC for the top level project when it graduates. Is my 
understanding incorrect? In any case, to directly address the diversity 
question, I believe the PMC would have members from companies such as 
Hortonworks, Yahoo, LinkedIn, Twitter to name a few.

As for our community, we have had multiple talks and meetups both on Tez alone 
as well as ones with the folks from Hive and Pig. 
  - http://www.meetup.com/Apache-Tez-User-Group. The only meetup we have had 
till date had a detailed talk on Tez in addition to presentations from folks 
from Hive and Pig on how they were using or planning to use Tez.
  - There was a whole evening devoted to Tez and applications on Tez as part of 
the Bay Area Hadoop User Group - http://www.meetup.com/hadoop/events/116895522/
  - Talks - there have been quite a few talks on it over the past year. For 
example, one can look at the recently completed Hadoop Summit in San Jose and 
search for Tez related talks of which only one talk was just about Tez and the 
others about applications built on top of it.

We have been working with the Hive and Pig folks mostly via JIRA to address 
their requirements as they built out their platforms to work on Tez. One can 
look at https://issues.apache.org/jira/browse/HIVE-4660 and 
https://issues.apache.org/jira/browse/PIG-3446 to see the considerable amount 
of work both these communities have put in to get their respective applications 
to work on top of Tez. Most of the interaction has been on JIRA and not really 
on the dev mailing lists. Most design discussions also tend to happen there. 
Subscribing to issues@ might give one a better perspective on community 
interaction.

To be frank, the Tez community for the past year has been working towards 
helping make Apache Hive and Apache Pig faster. As the platform evolves and 
grows, other applications such as Flink are considering it too. Hopefully, at 
some point down the line, we would like to work with the MapReduce community to 
have them consider using Tez. 

thanks
— Hitesh

On Jun 23, 2014, at 12:50 AM, Ted Dunning  wrote:

> 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

[VOTE] Graduate Apache Tez from Apache Incubator to TLP

[Hitesh Shah]

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

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

[Hitesh Shah]

Hi Justin 

Thanks for providing your feedback. 

A couple of points that I wanted to check with you:
   - we generate the website from our master branch and not a release. Is that 
an issue - if yes, I can go back and re-generate it from a previous release? 
  - the 0.5 SNAPSHOT shows up on the website as a result of the above. If 
only displaying the non-released version is an issue, I will look at options to 
try and not show it.
   - With respect to the members/committers on the team-list page, we use the 
maven-project-info-reports-plugin which auto-generates the text ( same as this 
page :
  
http://maven.apache.org/plugins/maven-project-info-reports-plugin/team-list.html
 ). Will look to see if they have any customization hooks to change the wording.
   - Will remove other releases from the website. They have been removed from 
dist release area but not from the website.  
  
For all committer ICLAs, I believe as per 
http://people.apache.org/committers-by-project.html#tez, all folks should have 
filed ICLAs given that none of their names show up in italics 
( most of them were committers in other apache projects ). Also, Tassapol is 
missing from the list for some reason but he shows up in the incubator project 
list and has filed an ICLA.

thanks
— Hitesh

On Jun 30, 2014, at 11:45 PM, Justin Mclean  wrote:

> Hi,
> 
> Looking good re activity, community and ability to make releases.
> 
> Just took a quick look at the Tez web site. IMO there's a few things that 
> need to be fixed.
> - Missing clear incubation disclaimer - although it's a bit late as once your 
> graduate it's not needed :-) [1]
> - Remove older incubating releases link - only need to have a link to the 
> latest.
> - Note version 0.5 SNAPSHOT in header. This is a release that hasn't been 
> voted on so should not be shown on the web site. see [2].
> - Change "members" to "committers" on this page [3] - may be some confusion 
> re the term "members" and "ASF members"
> - Have all committers ICLAs been checked? [4]
> 
> Thanks,
> Justin
> 
> 1. http://incubator.apache.org/guides/sites.html
> 2. http://www.apache.org/dev/release.html#what
> 3. http://tez.incubator.apache.org/team-list.html
> 4. http://incubator.apache.org/projects/tez.html
> -
> 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] Graduate Apache Tez from Apache Incubator to TLP

[Hitesh Shah]

Sorry for the late reply folks.

@Sebb, thanks for catching the issue.
@Chris, will work with a few folks offline to come up with a consistent and 
clear wording. 

Question for the IPMC folks - does this need a cancel and vote restart with the 
modified resolution? 

thanks
— Hitesh


On Jul 1, 2014, at 6:50 AM, Mattmann, Chris A (3980) 
 wrote:

> Looks like a good catch Sebb. Both could probably be more specific
> and look similar (maybe a cut/paste from Mesos which is a similar type
> of application?)
> 
> Hitesh et al can you try and come up with a better sentence in the
> graduation resolution to describe Tez and then make sure it's consistent
> in both places noted below?
> 
> Thanks,
> 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: sebb 
> Reply-To: "d...@tez.incubator.apache.org" 
> Date: Tuesday, July 1, 2014 5:13 AM
> To: "general@incubator.apache.org" 
> Cc: "d...@tez.incubator.apache.org" 
> Subject: Re: [VOTE] Graduate Apache Tez from Apache Incubator to TLP
> 
>> On 1 July 2014 05:16, Hitesh Shah  wrote:
>>> 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/%3
>>> ccfc4fef8.16337a%25chris.a.mattm...@jpl.nasa.gov%3E
>>> [2] 
>>> http://mail-archives.apache.org/mod_mbox/incubator-tez-dev/201406.mbox/%3
>>> ccaoapips7pjs_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.
>> 
>> Above is one summary of the PMC mission
>> 
>>> 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
>> 
>> And above is another which is rather different.
>> 
>> Which (if any?) is correct?
>> 
>>> 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, 

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

[Hitesh Shah]

Thanks Justin. 

I updated the project status.xml for the ICLAs requirement. Created jiras for 
the version and team list issues in the website. Will look into addressing them 
soon. 

thanks
— Hitesh

On Jul 1, 2014, at 9:35 PM, Justin Mclean  wrote:

> Hi,
> 
> +1 (binding)
> 
>>  - we generate the website from our master branch and not a release. Is that 
>> an issue
> No issue I can see there. Having to vote every time you wanted to release the 
> web site would be be rather cumbersome.
> 
>> - the 0.5 SNAPSHOT shows up on the website as a result of the above.
> Would be be best IMO if this can be removed.
> 
>>  - With respect to the members/committers on the team-list page
> Up to you to consider and perhaps or perhaps not do something about it.
> 
>> For all committer ICLAs, I believe as per 
>> http://people.apache.org/committers-by-project.html#tez, all folks should 
>> have filed ICLAs 
> Thanks for checking. You might want to update the status page (under 
> establish a list of active committers) with that information. [1]
> 
> Thanks,
> Justin
> 
> 1. http://incubator.apache.org/projects/tez.html


-
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

[Hitesh Shah]

Hi foks

I have re-worded the resolution draft to be consistent ( included below ). 

thanks
— Hitesh

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 highly performant and scalable distributed
data processing 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 highly performant and scalable distributed
data processing on clusters; 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.
--
 


On Jul 1, 2014, at 5:13 AM, sebb  wrote:

> On 1 July 2014 05:16, Hitesh Shah  wrote:
>> 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.
> 
> Above is one summary of the PMC mission
> 
>> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>&g

[RESULT][VOTE] Graduate Apache Tez from Apache Incubator to TLP

[Hitesh Shah]

The vote to graduate Apache Tez to a top-level project has passed with 15 
binding +1s, another +1 from Abiola A Balogun ( possibly a spam bot ) and no 
-1s.

Arun C Murthy * 
Bertrand Delacretaz * 
Chris Mattmann * 
Henry Saputra * 
Alan Gates * 
Ted Dunning *
Chris Douglas *
Alan Cabrera * 
Devaraj Das * 
Justin Mclean * 
Sergio Fernandez *
Abiola A Balogun
Roman Shaposhnik *
Jake Farrell *  
Jakob Homan * 
Steve Loughran * 

Thanks to everyone for voting. I will now proceed with the steps detailed in 
http://incubator.apache.org/guides/graduation.html#top-level-board-proposal. 

thanks
— Hitesh

On Jun 30, 2014, at 9:16 PM, Hitesh Shah  wrote:

> 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


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

Re: [VOTE] Accept REEF into the Apache Incubator

[Hitesh Shah]

+1 ( non-binding )

— Hitesh 

On Aug 8, 2014, at 10:40 PM, Byung-Gon Chun  wrote:

> Hi,
> 
> Thanks for participating in the proposal discussion on REEF. The discussion
> has calmed. I would like to call a vote for acceptance of REEF into the
> Apache Incubator.
> 
> The proposal is attached below, and it is also available at
> https://wiki.apache.org/incubator/ReefProposal
> 
> Let's keep this vote open for three business days, closing the voting on
> August 11, 11:59PM (PDT).
> 
> [] +1 Accept REEF into the Incubator
> [] 0 Don't care
> [] -1 Don't accept REEF because...
> 
> Thanks!
> -Gon
> 
> -- 
> Byung-Gon Chun
> 
> 
> # REEFProposal - Incubator
> 
> 
> # Abstract
> 
> REEF (Retainable Evaluator Execution Framework) is a scale-out
> computing fabric that eases the development of Big Data applications
> on top of resource managers such as Apache YARN and Mesos.
> 
> 
> # Proposal
> 
> REEF is a Big Data system that makes it easy to implement scalable,
> fault-tolerant runtime environments for a range of data processing
> models (e.g., graph processing and machine learning) on top of
> resource managers such as Apache YARN and Mesos. REEF provides
> capabilities to run multiple heterogeneous frameworks and workflows of
> those efficiently.
> 
> Additionally, REEF contains two libraries that are of independent
> value: Wake is an event-based-programming framework inspired by Rx and
> SEDA.  Tang is a dependency injection framework inspired by Google
> Guice, but designed specifically for configuring distributed systems.
> 
> 
> # Background
> 
> The resource management layer such as Apache YARN and Mesos has
> emerged as a critical layer in the new scale-out data processing
> stack; resource managers assume the responsibility of multiplexing a
> cluster of shared-nothing machines across heterogeneous
> applications. They operate behind an interface for leasing containers
> - a slice of a machine’s resources - to computations in an elastic
> fashion. However, building data processing frameworks directly on this
> layer comes at a high cost: each framework must tackle the same
> challenges (e.g., fault-tolerance, task scheduling and coordination)
> and reimplement common mechanisms (e.g., caching, bulk transfers).
> 
> REEF provides a reusable control-plane for scheduling and coordinating
> task-level work on cluster resource managers. The REEF design enables
> sophisticated optimizations, such as container re-use and data
> caching, and facilitates workflows that span multiple
> frameworks. Examples include pipelining data between different
> operators in a relational system, retaining state across iterations in
> iterative or recursive data flow, and passing the result of a
> MapReduce job to a Machine Learning computation.
> 
> 
> # Rationale
> 
> Since REEF is a library that makes it easy to write distributed
> applications on top of Apache YARN or Mesos, the Apache Software Foundation
> is the perfect home for hosting REEF.
> 
> 
> # Current Status
> 
> REEF has been developed mostly by Microsoft, UCLA and the Seoul
> National University.  The REEF codebase is open-sourced under Apache
> License 2.0 and is currently hosted in a public repository at
> github.com.
> 
> 
> # Meritocracy
> 
> We plan to build a strong open community by following the Apache
> meritocracy principles. We will work with those who contribute
> significantly to the project and invite them to be its committers.
> 
> 
> # Community
> 
> REEF is currently being used internally at Microsoft.  Also, SK
> Telecom builds their data analytics infrastructure on top of REEF in
> collaboration with Seoul National University.  We hope to extend our
> contributor base by becoming an Apache incubator project. REEF will
> attract developers who are interested in creating common building
> blocks for simplifying the development of large-scale big data
> applications.
> 
> 
> # Core Developers
> 
> Core developers are engineers from Microsoft, Purestorage, UCB, UCLA,
> UW and Seoul National University.
> 
> 
> # Alignment
> 
> REEF depends on many Apache projects and dependencies. REEF is built
> on resource managers such as Apache YARN and Apache Mesos. REEF also
> uses HDFS as a distributed storage layer.
> 
> 
> # Known Risks
> ## Orphaned Products
> 
> The risk of REEF being orphaned is small because Microsoft products
> are built on REEF. The core REEF developers continue to work on REEF
> at Microsoft, UCLA, and Seoul National University. The REEF project is
> gaining interest from other institutions to be used as their
> infrastructure.
> 
> ## Inexperience with Open Source
> 
> Several core developers have experience with open source development.
> REEF committers will be guided by the mentors with strong Apache open
> source project backgrounds.
> 
> ## Homogeneous Developers
> 
> The initial committers include developers from several institutions
> including Microsoft, Purestorage, UCB, UCLA, and Seoul National
> University.
> 
> 

Re: Uploading a release

[Hitesh Shah]

Publishing the contents at [1] can be done by following the steps detailed out 
at 
http://incubator.apache.org/guides/releasemanagement.html#release-distribution. 

For [2], it should just be a matter of hitting the “release” button on nexus. 

thanks
— Hitesh


On Sep 4, 2014, at 1:01 PM, Julian Hyde  wrote:

> The release vote Optiq 0.9.0 passed over a week ago. I have the bits ready 
> and staged [1] [2]. Now I have to publish the release.
> 
> I’ve read 
> http://incubator.apache.org/guides/releasemanagement.html#understanding-upload.
>  I now “understand upload” in an abstract sense but am none the wiser.
> 
> What should I actually do to publish the release? I suspect that 3 or 4 svn 
> commands are sufficient but I can’t guess what they might be.
> 
> (My experience being an Apache podling so far… one grueling fight after 
> another against the infrastructure. This is just the latest chapter.)
> 
> Julian
> 
> [1] http://people.apache.org/~jhyde/apache-optiq-0.9.0-incubating-rc1/ 
> [2] https://repository.apache.org/content/repositories/orgapacheoptiq-1000
> 


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

Re: Uploading a release

[Hitesh Shah]

Sorry - hit enter a bit too early. 

It should just be a matter of checking out 
https://dist.apache.org/repos/dist/release/incubator. Add an optiq dir into 
that and adding the release artifacts to a version-specific dir.. 

Once uploaded, they should be available via 
http://www.apache.org/dyn/closer.cgi/incubator/optiq

— Hitesh 



On Sep 4, 2014, at 1:31 PM, Hitesh Shah  wrote:

> Publishing the contents at [1] can be done by following the steps detailed 
> out at 
> http://incubator.apache.org/guides/releasemanagement.html#release-distribution.
>  
> 
> For [2], it should just be a matter of hitting the “release” button on nexus. 
> 
> thanks
> — Hitesh
> 
> 
> On Sep 4, 2014, at 1:01 PM, Julian Hyde  wrote:
> 
>> The release vote Optiq 0.9.0 passed over a week ago. I have the bits ready 
>> and staged [1] [2]. Now I have to publish the release.
>> 
>> I’ve read 
>> http://incubator.apache.org/guides/releasemanagement.html#understanding-upload.
>>  I now “understand upload” in an abstract sense but am none the wiser.
>> 
>> What should I actually do to publish the release? I suspect that 3 or 4 svn 
>> commands are sufficient but I can’t guess what they might be.
>> 
>> (My experience being an Apache podling so far… one grueling fight after 
>> another against the infrastructure. This is just the latest chapter.)
>> 
>> Julian
>> 
>> [1] http://people.apache.org/~jhyde/apache-optiq-0.9.0-incubating-rc1/ 
>> [2] https://repository.apache.org/content/repositories/orgapacheoptiq-1000
>> 
> 


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

Re: [VOTE] Apache Ambari (incubating) 1.2.0 Release Candidate RC0.

[Hitesh Shah]

Hi Tommaso, 

There are setup steps mentioned at 
https://cwiki.apache.org/confluence/display/AMBARI/Ambari+Development for 
getting Ambari to build. 
The web layer requires node.js and brunch. 

thanks
-- Hitesh

On Jan 28, 2013, at 11:05 PM, Tommaso Teofili wrote:

> If I download the SVN tag and run 'mvn install'
> 
> I get the following:
> 
> [INFO] Reactor Summary:
> [INFO]
> [INFO] Ambari Main ... SUCCESS [9.258s]
> [INFO] Apache Ambari Project POM . SUCCESS [0.045s]
> [INFO] Ambari Web  FAILURE [1.744s]
> [INFO] Ambari Server . SKIPPED
> [INFO] Ambari Agent .. SKIPPED
> [INFO]
> 
> [INFO] BUILD FAILURE
> [INFO]
> 
> [INFO] Total time: 56.720s
> [INFO] Finished at: Mon Jan 28 15:06:56 CET 2013
> [INFO] Final Memory: 8M/81M
> [INFO]
> 
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-antrun-plugin:1.7:run (compile) on project
> ambari-web: An Ant BuildException has occured: Execute failed:
> java.io.IOException: Cannot run program "npm" (in directory
> "/Users/user/Desktop/amb/ambari-web"): error=2, No such file or directory
> [ERROR] around Ant part ... executable="npm" failonerror="false">... @ 4:90 in
> /Users/user/Desktop/amb/ambari-web/target/antrun/build-ambari-web-compile.xml
> [ERROR] -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions,
> please read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/MojoExecutionException
> [ERROR]
> [ERROR] After correcting the problems, you can resume the build with the
> command
> [ERROR]   mvn  -rf :ambari-web
> 
> am I missing anything?
> 
> Apart from that it looks good.
> 
> Tommaso
> 
> 
> 2013/1/28 Mahadev Konar 
> 
>> Hi everyone,
>> 
>> This is a call for a vote on Apache Ambari 1.2.0 incubating. A vote
>> was held on developer mailing list and it
>> passed with 8 +1's with 6 of them binding.
>> 
>> mahadev (IPMC, PPMC)
>> ddas (IPMC, PPMC)
>> acmurthy (IPMC)
>> jitendra (PPMC)
>> hitesh (PPMC)
>> yusaku (PPMC)
>> 
>> 
>> http://mail-archives.apache.org/mod_mbox/incubator-ambari-dev/201301.mbox/%3CCALF7aMRrJxiMORuzMuYxnAuncias9Gnvd1awqaPO-Zuuo1cDqQ%40mail.gmail.com%3E
>> 
>> 
>> The staging Staging site is:
>> http://people.apache.org/~mahadev/ambari-1.2.0-incubating-rc0/
>> 
>> with user docs at:
>> 
>> http://incubator.apache.org/ambari/1.2.0/installing-hadoop-using-ambari/content/index.html
>> and dev docs at:
>> https://cwiki.apache.org/confluence/display/AMBARI/Ambari+Development
>> 
>> SVN source tag:
>> https://svn.apache.org/repos/asf/incubator/ambari/tags/release-1.2.0-rc0
>> 
>> PGP release keys (signed using 8EE2F25C)
>> http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=0x0DFF492D8EE2F25C
>> 
>> One can look into the issues fixed in this release at
>> 
>> https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%20%221.2.0%22%20AND%20project%20%3D%20AMBARI
>> 
>> Vote will be open for 72 hours.
>> [ ] +1 approve
>> [ ] +0 no opinion
>> [ ] -1 disapprove (and reason why)
>> 
>> thanks
>> mahadev
>> 
>> -
>> 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 Apache Knox Hadoop Gateway Project into the Incubator

[Hitesh Shah]

+1 ( non-binding )

-- Hitesh

On Feb 14, 2013, at 5:26 PM, Devaraj Das wrote:

> Hi Folks,
> 
> Thanks for participating in the discussion. I'd like to call a VOTE
> for acceptance of Apache Knox Hadoop Gateway Project into the
> Incubator. The vote will close on Feb 21 at 6:00 p.m.
> 
> [ ]  +1 Accept Apache Open Climate Workbench into the Incubator
> [ ]  +0 Don't care.
> [ ]  -1 Don't accept Apache Open Climate Workbench into the Incubator 
> because...
> 
> Full proposal is pasted at the bottom of this email, and the
> corresponding wiki is http://wiki.apache.org/incubator/knox. Only
> VOTEs from Incubator PMC members are binding.
> 
> Here's my +1 (binding).
> 
> Thanks,
> Devaraj.
> 
> p.s. In the last day, Tom White has been added as a mentor, and
> Venkatesh Seetharam has been added in the list of initial committers.
> 
> 
> Knox Gateway Proposal
> 
> Abstract
> 
> Knox Gateway is a system that provides a single point of secure access
> for Apache Hadoop clusters.
> 
> Proposal
> 
> The Knox Gateway (“Gateway” or “Knox”) is a system that provides a
> single point of authentication and access for Apache Hadoop services
> in a cluster. The goal is to simplify Hadoop security for both users
> (i.e. who access the cluster data and execute jobs) and operators
> (i.e. who control access and manage the cluster). The Gateway runs as
> a server (or cluster of servers) that serve one or more Hadoop
> clusters.
> 
> Provide perimeter security to make Hadoop security setup easier
> Support authentication and token verification security scenarios
> Deliver users a single cluster end-point that aggregates capabilities
> for data and jobs
> Enable integration with enterprise and cloud identity management environments
> 
> Background
> 
> An Apache Hadoop cluster is presented to consumers as a loose
> collection of independent services. This makes it difficult for users
> to interact with Hadoop since each service maintains it’s own method
> of access and security. As well, for operators, configuration and
> administration of a secure Hadoop cluster is a complex and many Hadoop
> clusters are insecure as a result.
> 
> The goal of the project is to provide coverage for all existing Hadoop
> ecosystem projects. In addition, the project will be extensible to
> allow for new and/or proprietary Hadoop components without requiring
> changes to the gateway source code. The gateway is expected to run in
> a DMZ environment where it will provide controlled access to these
> Hadoop services. In this way Hadoop clusters can be protected by a
> firewall and only limited access provided through the firewall for the
> gateway. The authentication components of the gateway will be modular
> and extensible such that it can be integrated with existing security
> infrastructure.
> 
> Rationale
> 
> Organizations that are struggling with Hadoop cluster security result
> in a) running Hadoop without security or b) slowing adoption of
> Hadoop. The Gateway aims to provide perimeter security that integrates
> more easily into existing organizations’ security infrastructure.
> Doing so will simplify security for these organizations and benefit
> all Hadoop stakeholders (i.e. users and operators). Additionally,
> making a dedicated perimeter security project part of the Apache
> Hadoop ecosystem will prevent fragmentation in this area and further
> increase the value of Hadoop as a data platform.
> 
> Current Status
> 
> Prototype available, developed by the list of initial committers.
> 
> Meritocracy
> 
> We desire to build a diverse developer community around Gateway
> following the Apache Way. We want to make the project open source and
> will encourage contributors from multiple organizations following the
> Apache meritocracy model.
> 
> Community
> 
> We hope to extend the user and developer base in the future and build
> a solid open source community around Gateway. Apache Hadoop has a
> large ecosystem of open source projects, each with a strong community
> of contributors. All project communities in this ecosystem have an
> opportunity to participate in the advancement of the Gateway project
> because ultimately, Gateway will enable the security capabilities of
> their project to be more enterprise friendly.
> 
> Core Developers
> 
> Gateway is currently being developed by several engineers from
> Hortonworks - Kevin Minder, Larry McCay, John Speidel, Tom Beerbower
> and Sumit Mohanty. All the engineers have deep expertise in
> middleware, security & identity systems and are quite familiar with
> the Hadoop ecosystem.
> 
> Alignment
> 
> The ASF is a natural host for Gateway given that it is already the
> home of Hadoop, Hive, Pig, HBase, Oozie and other emerging big data
> software projects. Gateway is designed to solve the security
> challenges familiar to the Hadoop ecosystem family of projects.
> 
> Known Risks
> 
> Orphaned products & Reliance on Salaried Developers
> 
> The core developers plan to work full time 

Re: [VOTE] Accept Apache Knox Hadoop Gateway Project into the Incubator

[Hitesh Shah]

+1 ( non-binding )

-- Hitesh 

On Feb 15, 2013, at 11:22 AM, Devaraj Das wrote:

> Hi Folks,
> 
> Thanks for participating in the discussion. I'd like to call a VOTE
> for acceptance of Apache Knox Hadoop Gateway Project into the
> Incubator. The vote will close on Feb 22 at 6:00 p.m.
> 
> [ ]  +1 Accept Apache Knox Hadoop Gateway Project into the Incubator
> [ ]  +0 Don't care.
> [ ]  -1 Don't accept Apache Knox Hadoop Gateway Project into the
> Incubator because...
> 
> Full proposal is pasted at the bottom of this email, and the
> corresponding wiki is http://wiki.apache.org/incubator/knox. Only
> VOTEs from Incubator PMC members are binding.
> 
> Here's my +1 (binding).
> 
> Thanks,
> Devaraj.
> 
> -
> 
> Knox Gateway Proposal
> 
> Abstract
> 
> Knox Gateway is a system that provides a single point of secure access
> for Apache Hadoop clusters.
> 
> Proposal
> 
> The Knox Gateway (“Gateway” or “Knox”) is a system that provides a
> single point of authentication and access for Apache Hadoop services
> in a cluster. The goal is to simplify Hadoop security for both users
> (i.e. who access the cluster data and execute jobs) and operators
> (i.e. who control access and manage the cluster). The Gateway runs as
> a server (or cluster of servers) that serve one or more Hadoop
> clusters.
> 
> Provide perimeter security to make Hadoop security setup easier
> Support authentication and token verification security scenarios
> Deliver users a single cluster end-point that aggregates capabilities
> for data and jobs
> Enable integration with enterprise and cloud identity management environments
> 
> Background
> 
> An Apache Hadoop cluster is presented to consumers as a loose
> collection of independent services. This makes it difficult for users
> to interact with Hadoop since each service maintains it’s own method
> of access and security. As well, for operators, configuration and
> administration of a secure Hadoop cluster is a complex and many Hadoop
> clusters are insecure as a result.
> 
> The goal of the project is to provide coverage for all existing Hadoop
> ecosystem projects. In addition, the project will be extensible to
> allow for new and/or proprietary Hadoop components without requiring
> changes to the gateway source code. The gateway is expected to run in
> a DMZ environment where it will provide controlled access to these
> Hadoop services. In this way Hadoop clusters can be protected by a
> firewall and only limited access provided through the firewall for the
> gateway. The authentication components of the gateway will be modular
> and extensible such that it can be integrated with existing security
> infrastructure.
> 
> Rationale
> 
> Organizations that are struggling with Hadoop cluster security result
> in a) running Hadoop without security or b) slowing adoption of
> Hadoop. The Gateway aims to provide perimeter security that integrates
> more easily into existing organizations’ security infrastructure.
> Doing so will simplify security for these organizations and benefit
> all Hadoop stakeholders (i.e. users and operators). Additionally,
> making a dedicated perimeter security project part of the Apache
> Hadoop ecosystem will prevent fragmentation in this area and further
> increase the value of Hadoop as a data platform.
> 
> Current Status
> 
> Prototype available, developed by the list of initial committers.
> 
> Meritocracy
> 
> We desire to build a diverse developer community around Gateway
> following the Apache Way. We want to make the project open source and
> will encourage contributors from multiple organizations following the
> Apache meritocracy model.
> 
> Community
> 
> We hope to extend the user and developer base in the future and build
> a solid open source community around Gateway. Apache Hadoop has a
> large ecosystem of open source projects, each with a strong community
> of contributors. All project communities in this ecosystem have an
> opportunity to participate in the advancement of the Gateway project
> because ultimately, Gateway will enable the security capabilities of
> their project to be more enterprise friendly.
> 
> Core Developers
> 
> Gateway is currently being developed by several engineers from
> Hortonworks - Kevin Minder, Larry McCay, John Speidel, Tom Beerbower
> and Sumit Mohanty. All the engineers have deep expertise in
> middleware, security & identity systems and are quite familiar with
> the Hadoop ecosystem.
> 
> Alignment
> 
> The ASF is a natural host for Gateway given that it is already the
> home of Hadoop, Hive, Pig, HBase, Oozie and other emerging big data
> software projects. Gateway is designed to solve the security
> challenges familiar to the Hadoop ecosystem family of projects.
> 
> Known Risks
> 
> Orphaned products & Reliance on Salaried Developers
> 
> The core developers plan to work full time on the project. We believe
> that this project will be of general interest to many Hadoop users and
> will attract a d

Re: [VOTE] Accept Tez into Incubator

[Hitesh Shah]

+1 ( non-binding ) 

-- Hitesh

On Feb 19, 2013, at 8:26 PM, Arun C Murthy wrote:

> Hi Folks,
> 
> Thanks for participating in the discussion. I'd like to call a VOTE for 
> acceptance of Apache Tez into the Incubator. I'll let the vote run till into 
> this weekend (Sun 2/24 6pm PST).
> 
> [ ]  +1 Accept Apache Tez into the Incubator
> [ ]  +0 Don't care.
> [ ]  -1 Don't accept Apache Tez into the Incubator because...
> 
> Full proposal is pasted at the bottom of this email, and the corresponding 
> wiki is http://wiki.apache.org/incubator/TezProposal. 
> 
> Only VOTEs from Incubator PMC members are binding, but all are welcome to 
> express their thoughts.
> 
> Here's my +1 (binding).
> 
> thanks,
> Arun
> 
> PS: From the initial discussion, the only changes are that I've added one new 
> mentor and 2 new committers. All the new additions come from the non-major 
> employer while we continue to strive to further diversify during the 
> incubation. Thanks.
> 
> 
> 
> = Tez =
> 
> == Abstract ==
> Tez is an effort to develop a generic application framework which can be used
> to process arbitrarily complex data-processing tasks and also a re-usable set
> of data-processing primitives which can be used by other projects.
> 
> == Proposal ==
> Tez is a proposal to develop a generic application which can be used to
> process complex data-processing task DAGs and runs natively on Apache Hadoop 
> YARN. YARN is a generic resource-management system on which currently 
> applications like MapReduce already exist. MapReduce is a specific, and
> constrained, DAG - which is not optimal for several frameworks like Apache 
> Hive
> and Apache Pig. Furthermore, we propose to develop a re-usable set of
> libraries of data-processing primitives such as sorting, merging,
> data-shuffling, intermediate data management etc. which are necessary for Tez 
> which we envision can be used directly by other projects. 
> 
> == Background ==
> Apache Hadoop MapReduce has emerged as the assembly-language on which other
> frameworks like Apache Pig and Apache Hive have been built. However, it has
> been well accepted that MapReduce produces very constrained task DAGs for each
> job which results in Apache Pig and Apache Hive requiring multiple MapReduce
> jobs for several queries. By providing a more expressive DAG of tasks for a
> job, Tez attempts to provide significantly enhanced data-processing
> capabilities for projects like Apache Pig, Apache Hive, Cascading etc.
> 
> == Rationale ==
> There is an important gap that Tez fulfills in the Apache Hadoop ecosystem of
> allowing for more expressive task DAGs for data-processing applications such
> as Apache Pig, Apache Hive, Cascading etc.
> 
> With emergence of Apache Hadoop YARN, there is a strong need for a
> common DAG application which can then be shared by Apache Pig, Apache Hive,
> Cascading etc.
> 
> == Initial Goals ==
> The initial goals for this project are to specify the detailed requirements
> and architecture, and then develop the initial implementation including the
> DAG ApplicationMaster to run natively inside Apache Hadoop YARN. 
> 
> == Current Status ==
> Significant work has been completed to identify the initial requirements and
> define the overall system architecture. There is a patch available in the
> internal Hortonworks git repository which can act as the initial seed. 
> 
> === Meritocracy ===
> We plan to invest in supporting a meritocracy. We will discuss the 
> requirements 
> in an open forum. Several companies have already expressed interest in this 
> project, and we intend to invite additional developers to participate. 
> We will encourage and monitor community participation so that privileges can 
> be 
> extended to those that contribute. 
> 
> === Community ===
> The need for a generic DAG application for data processing in the open source 
> is 
> tremendous, so there is a potential for a very large community. We believe
> that Tez's extensible architecture will further encourage community 
> participation. 
> Also, related Apache projects (eg, Pig, Hive) have very large and active 
> communities, and we expect that over time Tez will also attract a large 
> community.
> 
> === Core Developers ===
> The developers on the initial committers list include people very experienced
> in the Apache Hadoop ecosystem:
> 
> * Alan Gates 
> * Arun C Murthy 
> * Ashutosh Chauhan 
> * Bikas Saha 
> * Chris Douglas 
> * Daryn Sharp 
> * Devaraj Das 
> * Gopal Vijayaraghavan 
> * Gunther Hagleitner 
> * Hitesh Shah 
> * Jason Lowe 
> * Jean Xu 
> * Jitendra Pandey 
> * Julien Le

Re: [DISCUSS] stabilizing Hadoop releases wrt. downstream

[Hitesh Shah]

Does this need to go to general@hadoop and not general@incubator? 

-- Hitesh 

On Feb 26, 2013, at 5:31 PM, Roman Shaposhnik wrote:

> Hi!
> 
> for the past couple of releases of Hadoop 2.X code line the issue
> of integration between Hadoop and its downstream projects has
> become quite a thorny issue. The poster child here is Oozie, where
> every release of Hadoop 2.X seems to be breaking the compatibility
> in various unpredictable ways. At times other components (such
> as HBase for example) also seem to be affected.
> 
> Now, to be extremely clear -- I'm NOT talking about the *latest* version
> of Oozie working with the *latest* version of Hadoop, instead
> my observations come from running previous *stable*  releases
> of Bigtop on top of Hadoop 2.X RCs.
> 
> As many of you know Apache Bigtop aims at providing a single
> platform for integration of Hadoop and Hadoop ecosystem projects.
> As such we're uniquely positioned to track compatibility between
> different Hadoop releases with regards to the downstream components
> (things like Oozie, Pig, Hive, Mahout, etc.). Every single single RC
> we've been pretty diligent at trying to provide integration-level feedback
> on the quality of the upcoming release,  but it seems that our efforts
> don't quite suffice in Hadoop 2.X stabilizing.
> 
> Of course, one could argue that while Hadoop 2.X code line was
> designated 'alpha' expecting much in the way of perfect integration
> and compatibility was NOT what the Hadoop community was
> focusing on. I can appreciate that view, but what I'm interested in
> is the future of Hadoop 2.X not its past. Hence, here's my question
> to all of you as a Hadoop community at large:
> 
> Do you guys think that the project have reached a point where integration
> and compatibility issues should be prioritized really high on the list
> of things that make or break each future release?
> 
> The good news, is that Bigtop's charter is in big part *exactly* about
> providing you with this kind of feedback. We can easily tell you when
> Hadoop behavior, with regard to downstream components, changes
> between a previous stable release and the new RC (or even branch/trunk).
> What we can NOT do is submit patches for all the issues. We are simply
> too small a project and we need your help with that.
> 
> I truly believe that we owe it to the downstream projects, and in the
> second half of this email I will try to convince you of that.
> 
> We all know that integration projects are impossible to pull off
> unless there's a general consensus between all of the projects involved
> that they indeed need to work with each other. You can NOT force
> that notion, but you can always try to influence. This relationship
> goes both ways.
> 
> Consider a question in front of the downstream communities
> of  whether or not to adopt Hadoop 2.X as the basis. To answer
> that question each downstream project has to be reasonably
> sure that their concerns will NOT fall on deaf ears and that
> Hadoop developers are, essentially, 'ready' for them to pick
> up Hadoop 2.X. I would argue that so far the Hadoop community
> had gone out of its way to signal that 2.X codeline is NOT
> ready for the downstream.
> 
> I would argue that moving forward this is a really unfortunate
> situation that may end up undermining the long term success
> of Hadoop 2.X if we don't start addressing the problem. Think
> about it -- 90% of unit tests that run downstream on Apache
> infrastructure are still exercising Hadoop 1.X underneath.
> In fact, if you were to forcefully make, lets say, HBase's
> unit tests run on top of Hadoop 2.X quite a few of them
> are going to fail. Hadoop community is, in effect, cutting
> itself off from the biggest source of feedback -- its downstream
> users. This in turn:
> 
>  * leaves Hadoop project in a perpetual state of broken
>windows syndrome.
> 
>  * leaves Apache Hadoop 2.X releases in a state considerably
>inferior to the releases *including* Apache Hadoop done by the
>vendors. The users have no choice but to alight themselves
>with vendor offerings if they wish to utilize latest Hadoop functionality.
>The artifact that is know as Apache Hadoop 2.X stopped being
>a viable choice thus fracturing the user community and reducing
>the benefits of a commonly deployed codebase.
> 
>   * leaves downstream projects of Hadoop  in a jaded state where
> they legitimately get very discouraged and frustrated and eventually
> give up thinking that -- well, we work with one release of Hadoop
> (the stable one Hadoop 1.X) and we shall wait for the Hadoop
> community to get their act together.
> 
> In my view (shared by quite a few members of the Apache Bigtop) we
> can definitely do better than this if we all agree that the proposed
> first 'beta' release of Hadoop 2.0.4 is the right time for it to happen.
> 
> It is about time Hadoop 2.X community wins back all those end users
> and downstream proje

[CANCEL][VOTE] Apache Ambari (incubating) 1.2.1 Release Candidate RC0.

[Hitesh Shah]

Closing out this vote for the votes monitor to catch. 1.2.1 RC1 was voted on 
and released quite some time back. 

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

Re: [VOTE] Apache Spark for the Incubator

[Hitesh Shah]

+1 (non-binding)

-- Hitesh

On Jun 7, 2013, at 10:34 PM, Mattmann, Chris A (398J) wrote:

> Hi Folks,
> 
> OK discussion has died down, time to VOTE to accept Spark into the
> Apache Incubator. I'll let the VOTE run for at least a week.
> 
> So far I've heard +1s from the following folks, so no need for them
> to VOTE again unless they want to change their VOTE:
> 
> +1
> 
> Chris Mattmann*
> Konstantin Boudnik
> Henry Saputra*
> Reynold Xin
> Pei Chen
> Roman Shaposhnik*
> Suresh Marru*
> 
> * -indicates IPMC
> 
> [ ] +1 Accept Spark into the Apache Incubator.
> [ ] +0 Don't care.
> [ ] -1 Don't accept Spark into the Apache Incubator because..
> 
> Proposal text is below.
> 
> === Abstract ===
> Spark is an open source system for large-scale data analysis on clusters.
> 
> === Proposal ===
> Spark is an open source system for fast and flexible large-scale data
> analysis. Spark provides a general purpose runtime that supports
> low-latency execution in several forms. These include interactive
> exploration of very large datasets, near real-time stream processing, and
> ad-hoc SQL analytics (through higher layer extensions). Spark interfaces
> with HDFS, HBase, Cassandra and several other storage storage layers, and
> exposes APIs in Scala, Java and Python.
> Background
> Spark started as U.C. Berkeley research project, designed to efficiently
> run machine learning algorithms on large datasets. Over time, it has
> evolved into a general computing engine as outlined above. Spark¹s
> developer community has also grown to include additional institutions,
> such as universities, research labs, and corporations. Funding has been
> provided by various institutions including the U.S. National Science
> Foundation, DARPA, and a number of industry sponsors. See:
> https://amplab.cs.berkeley.edu/sponsors/ for full details.
> 
> === Rationale ===
> As the number of contributors to Spark has grown, we have sought for a
> long-term home for the project, and we believe the Apache foundation would
> be a great fit. Spark is a natural fit for the Apache foundation: Spark
> already interoperates with several existing Apache projects (HDFS, HBase,
> Hive, Cassandra, Avro and Flume to name a few). The Spark team is familiar
> with the Apache process and and subscribes to the Apache mission - the
> team includes multiple Apache committers already. Finally, joining Apache
> will help coordinate the development effort of the growing number of
> organizations which contribute to Spark.
> 
> == Initial Goals ==
> The initial goals will most likely be to move the existing codebase to
> Apache and integrate with the Apache development process. Furthermore, we
> plan for incremental development, and releases along with the Apache
> guidelines.
> 
> === Current Status ===
> == Meritocracy ==
> The Spark project already operates on meritocratic principles. Today,
> Spark has several developers and has accepted multiple major patches from
> outside of U.C. Berkeley. While this process has remained mostly informal
> (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 Spark project would
> include several of these participants as committers from the onset. 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 Spark. That community includes dozens
> of contributors from several institutions, a meetup group with several
> hundred members, and an active mailing list composed of hundreds of users.
> Core Developers
> The core developers of our project are listed in our contributors and
> initial PPMC below. Though many exist at UC Berkeley, there is a
> representative cross sampling of other organizations including Quantifind,
> Microsoft, Yahoo!, ClearStory Data, Bizo, Intel, Tagged and Webtrends.
> 
> 
> === Alignment ===
> Our proposed effort aligns with several ongoing BIGDATA and U.S. National
> priority funding interests including the NSF and its Expeditions program,
> and the DARPA XDATA project. Our industry partners and collaborators are
> well aligned with our code base.
> 
> There are also a number of related Apache projects and dependencies, that
> will be mentioned in the Relationships with Other Apache products section.
> 
> == Known Risks ==
> 
> === Orphaned Products ===
> Given the current level of investment in Spark - the risk of the project
> being abandoned is minimal. There are several constituents who are highly
> incentivized to continue development. The U.C. Berkeley AMPLab relies on
> Spark as a platform for a large number of long-term research projects.
> Several companies have build verticalized products which are tightly
> dependent on Spark. Other companies have devote

Re: [VOTE] Accept Samza into the Incubator

[Hitesh Shah]

+1. 

-- Hitesh

On Jul 26, 2013, at 12:52 PM, Jakob Homan wrote:

> Incubator-
> 
> Following the discussion earlier this week, I'm calling a vote to accept
> Samza as a new Incubator project.
> 
> The proposal draft is available at:
> https://wiki.apache.org/incubator/SamzaProposal,
> and is also included below. It is identical as what was proposed in the
> discussion except for removing the user list, per Marvin's suggestion.
> 
> Vote is open for at least 96h and closes at the earliest on 30 July 13:00
> PDT.  I'm letting the vote run an extra day as we're bookending the weekend
> and I want to give everybody a reasonable workweek margin.
> 
> [ ] +1 accept Samza in the Incubator
> [ ] +/-0
> [ ] -1 because...
> 
> Here's my binding +1
> 
> -Jakob
> 
> 
> 
> Abstract
> 
> Samza is a stream processing system for running continuous computation on
> infinite streams of data.
> 
> Proposal
> 
> Samza provides a system for processing stream data from publish-subscribe
> systems such as Apache Kafka. The developer writes a stream processing
> task, and executes it as a Samza job. Samza then routes messages between
> stream processing tasks and the publish-subscribe systems that the messages
> are addressed to.
> 
> Background
> 
> Samza was developed at LinkedIn to enable easier processing of streaming
> data on top of Apache Kafka. Current use cases include content processing
> pipelines, aggregating operational log data, data ingestion into
> distributed database infrastructure, and measuring user activity across
> different aggregation types.
> 
> Samza is focused on providing an easy to use framework to process streams.
> It uses Apache YARN to provide a mechanism for deploying stream processing
> tasks in a distributed cluster. Samza also takes advantage of YARN to make
> decisions about stream processor locality, co-partition of streams, and
> provide security. Apache Kafka is also leveraged to provide a mechanism to
> pass messages from one stream processor to the next. Apache Kafka is also
> used to help manage a stream processor's state, so that it can be recovered
> in the event of a failure.
> 
> Samza is written in Scala. It was developed internally at LinkedIn to meet
> our particular use cases, but will be useful to many organizations facing a
> similar need to reliably process large amounts of streaming data.
> Therefore, we would like to share it the ASF and begin developing a
> community of developers and users within Apache.
> 
> Rationale
> 
> Many organizations can benefit from a reliable stream processing system
> such as Samza. While our use case of processing events from a large website
> like LinkedIn has driven the design of Samza, its uses are varied and we
> expect many new use cases to emerge. Samza provides a generic API to
> process messages from streaming infrastructure and will appeal to many
> users.
> 
> Current Status
> 
> Meritocracy
> 
> Our intent with this incubator proposal is to start building a diverse
> developer community around Samza following the Apache meritocracy model.
> Since Samza was initially developed in late 2011, we have had fast adoption
> and contributions by multiple teams at LinkedIn. We plan to continue
> support for new contributors and work with those who contribute
> significantly to the project to make them committers.
> 
> Community
> 
> Samza is currently being used internally at LinkedIn. We hope to extend our
> contributor base significantly and invite all those who are interested in
> building large-scale distributed systems to participate.
> 
> Core Developers
> 
> Samza is currently being developed by four engineers at LinkedIn: Jay
> Kreps, Jakob Homan, Sriram Subramanian, and Chris Riccomini. Jakob is an
> ASF Member, Incubator PMC member and PMC member on Apache Hadoop, Kafka and
> Giraph. Jay is a member of the Apache Kafka PMC and contributor to various
> Apache projects. Chris has been an active contributor for several projects
> including Apache Kafka and Apache YARN. Sriram has contributed to Samza, as
> well as Apache Kafka.
> 
> Alignment
> 
> The ASF is the natural choice to host the Samza project as its goal of
> encouraging community-driven open-source projects fits with our vision for
> Samza. Additionally, many other projects with which we are familiar with
> and expect Samza to integrate with, such as Apache ZooKeeper, YARN, HDFS
> and log4j are hosted by the ASF and we will benefit and provide benefit by
> close proximity to them.
> 
> Known Risks
> 
> Orphaned Products
> 
> The core developers plan to work full time on the project. There is very
> little risk of Samza being abandoned as it is part of LinkedIn's internal
> infrastructure.
> 
> Inexperience with Open Source
> 
> All of the core developers have experience with open source development.
> Jay and Chris has been involved with several open source projects re

Permissions to edit Incubator wiki

[Hitesh Shah]

Hi 

Could someone grant me permissions to edit the incubator wiki? Username is 
HiteshShah. 

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

Re: [DISCUSS] Apex Incubation Proposal

[Hitesh Shah]

If there isn’t a char limit on project names in JIRA, wouldn’t it just be 
better to use “APEX-CORE” and “APEX-MALHAR” to match the actual project names, 
repos, etc?

thanks
— Hitesh

On Aug 11, 2015, at 1:25 PM, Amol Kekre  wrote:

> Chris,
> Thanks for articulating what I was going to respond with after talking to
> folks here. We indeed see versions for Malhar and Apex differing. We expect
> Malhar versions to change much more rapidly than Apex.
> 
> Ted,
> We discussed the impact of single jira on versioning.  For example we
> expect Malhar X.0.0 to happen much earlier than Apex X.0.0. There was
> discomfort in naming versions with prefix. The consensus was to have
> version numbers convey stuff. If folks don't have strong opinion on two
> jiras, we would prefer to use two jiras. We have taken up Bertrand's scope
> naming and changed the names of jira projects as follows
> 
> APX-CORE
> APX-MLHR
> 
> I have changed the wiki to reflect the above as jira project names.
> 
> Thks,
> Amol
> 
> 
> On Tue, Aug 11, 2015 at 10:03 AM, Chris Nauroth 
> wrote:
> 
>> One thing to consider is that release version numbers are tied to specific
>> JIRA projects.  If the intention is for Apex and Malhar version numbers to
>> be independent, then using a single JIRA project could introduce some risk
>> of confusion if an Apex version number accidentally gets applied to a
>> Malhar issue.  It might necessitate prefixing the version numbers with
>> "apex-" and "malhar-" to differentiate.
>> 
>> Based on that, I have a slight preference for separate JIRA projects.
>> However, I don't object to using a single unified JIRA project if others
>> feel strongly about it.
>> 
>> --Chris Nauroth
>> 
>> 
>> 
>> 
>> On 8/11/15, 8:23 AM, "Amol Kekre"  wrote:
>> 
>>> Ted,
>>> I agree that repo is more critical than jira instance. I am taking up your
>>> suggesstion with folks and should get back soon.
>>> 
>>> Thks
>>> Amol
>>> 
>>> On Tue, Aug 11, 2015 at 3:48 AM, Ted Dunning 
>>> wrote:
>>> 
 
 I personally see far less reason for separate JIRA instances than git
 repos. Having all jiras under APEX seems a good choice.
 
 Sent from my iPhone
 
> On Aug 11, 2015, at 2:32, Bertrand Delacretaz >> 
 wrote:
> 
> As for JIRA, I would apply the same rule, so APX-CORE and APX-MHAR
 maybe.
 
 -
 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: [VOTE] Accept Apex into the Apache Incubator

[Hitesh Shah]

None
> 
> Test only dependencies:
>* activemq-broker
>* activemq-kahadb-store
>* greenmail
>* hadoop-yarn-server-tests
>* hsqldb
>* janino
>* junit
>* MockFtpServer
>* mockito-all
>* testng
>  
> Cryptography N/A
> 
> == Required Resources ==
> === Mailing lists ===
>* priv...@apex.incubator.apache.org (moderated subscriptions)
>* comm...@apex.incubator.apache.org
>* d...@apex.incubator.apache.org
> 
> === Git Repository ===
>* https://git-wip-us.apache.org/repos/asf/incubator-apex-core.git
>* https://git-wip-us.apache.org/repos/asf/incubator-apex-malhar.git
> 
> === Issue Tracking ===
>* JIRA Project Apex (APEX_CORE) // If '_' is not allowed, use APEXCORE
>* JIRA Project Malhar (APEX_MALHAR) // If '_' is not allowed use APEXMALHAR
> 
> === Other Resources ===
>* Means of setting up regular builds for apex-core on builds.apache.org
>* Means of setting up regular builds for apex-malhar on builds.apache.org
> 
> === Rationale for Malhar and Apex having separate git and jira ===
> We managed Malhar and Apex as two repos and two jiras on purpose. Both code 
> bases are released under Apache 2.0 and are proposed for incubation. In terms 
> of our vision to enable innovation around a native YARN data-in-motion that 
> unifies stream processing as well as batch processing Malhar and Apex go hand 
> in hand. Apex has base API that consists of java api (functional), and 
> attributes (operability). Malhar is a manifestation of this api, but from 
> user perspective, Malhar is itself an API to leverage business logic. Over 
> past three years we have found that the cadence of release and api changes in 
> Malhar is much rapid than Apex and it was operationally much easier to 
> separate them into their own repos. Two repos will reflect clear separation 
> of engine (Apex) and operators/business logic (Malhar). It will allow or 
> independent release cycles (operator change independent of engine due to 
> stable API). We however do not believe in two levels of committers. We 
> believe there should be one community that works across both and innovates 
> with ideas that Malhar and Apex combined provide the value proposition. We 
> are proposing that Apache incubation process help us to foster development of 
> one community (mailing list, committers), and a yet be ok with two repos. We 
> are proposing that this be taken up during incubation. Community will learn 
> if this works. The decision on whether to split them into two projects be 
> taken after the learning curve during incubation.
> 
> == Initial Committers ==
>* Roma Ahuja (rahuja at directv dot com)
>* Isha Arkatkar (isha at datatorrent dot com)
>* Raja Ali (raji at silverspringnet dot com) 
>* Sunaina Chaudhary ( SChaudhary at directv dot com)
>* Bhupesh Chawda (bhupesh at datatorrent dot com)
>* Chaitanya Chelobu (chaitanya at datatorrent dot com)
>* Bright Chen (bright at datatorrent dot com)
>* Pradeep Dalvi (pradeep dot dalvi at datatorrent dot com)
>* Sandeep Deshmukh (sandeep at datatorrent dot com)
>* Yogi Devendra (yogi at datatorrent dot com)
>* Cem Ezberci (hasan dot ezberci at ge dot com)
>* Timothy Farkas (tim at datatorrent dot com)
>* Ilya Ganelin (ilya dot ganelin at capitalone dot com)
>* Vitthal Gogate (vitthal_gogate at yahoo dot com)
>* Parag Goradia (parag dot goradia at ge dot com)
>* Tushar Gosavi (tushar at datatorrent dot com)
>* Priyanka Gugale (priyanka at datatorrent dot com)
>* Gaurav Gupta (gaurav at datatorrent dot com)
>* Sandesh Hegde (sandesh at datatorrent dot com)
>* Siyuan Hua ( siyuan at datatorrent dot com)
>* Ajith Joseph (ajoseph at silverspring dot com)
>* Amol Kekre ( amol at datatorrent dot com)
>* Chinmay Kolhatkar ( chinmay at datatorrent dot com)
>* Pramod Immaneni ( pramod at datatorrent dot com)
>* Anuj Lal ( anuj dot lal at ge dot com)
>* Dongsu Lee (dlee3 at directv dot com)
>* Vitaly Li (blossom dot valley at gmail dot com)
>* Dean Lockgaard (dean  at datatorrent dot com)
>* Rohan Mehta (rohan_mehta at apple dot com)
>* Adi Mishra (apmishra at directv dot com, adi dot mishra at gmail dot com)
>* Chetan Narsude (chetan  at datatorrent dot com)
>* Darin Nee (dnee at silverspring dot com)
>* Alexander Parfenov (sasha at datatorrent dot com)
>* Andrew Perlitch (andy at datatorrent dot com)
>* Shubham Phatak (shubham at datatorrent dot com)
>* Ashwin Putta (ashwin at datatorrent dot com)
>* Rikin Shah (shah_rikin at yahoo dot com)
>* Luis Ramos (l dot ramos at ge dot com)
>* Munag

Re: [VOTE] Accept HAWQ into the Apache Incubator

[Hitesh Shah]

+1

— Hitesh

On Aug 31, 2015, at 11:47 AM, Roman Shaposhnik  wrote:

> Following the discussion earlier:
>   http://s.apache.org/Gaf
> 
> I would like to call a VOTE for accepting HAWQ
> as a new incubator project.
> 
> The proposal is available at:
>https://wiki.apache.org/incubator/HAWQProposal
> and is also included at the bottom of this email.
> 
> Vote is open until at least Thu, 3 September 2015, 23:59:00 PST
> 
> [ ] +1 accept HAWQ into the Apache Incubator
> [ ] ±0
> [ ] -1 because...
> 
> Thanks,
> Roman.
> 
> == Abstract ==
> 
> HAWQ is an advanced enterprise SQL on Hadoop analytic engine built
> around a robust and high-performance massively-parallel processing
> (MPP) SQL framework evolved from Pivotal Greenplum DatabaseⓇ.
> 
> HAWQ runs natively on Apache HadoopⓇ clusters by tightly integrating
> with HDFS and YARN. HAWQ supports multiple Hadoop file formats such as
> Apache Parquet, native HDFS, and Apache Avro. HAWQ is configured and
> managed as a Hadoop service in Apache Ambari. HAWQ is 100% ANSI SQL
> compliant (supporting ANSI SQL-92, SQL-99, and SQL-2003, plus OLAP
> extensions) and supports open database connectivity (ODBC) and Java
> database connectivity (JDBC), as well. Most business intelligence,
> data analysis and data visualization tools work with HAWQ out of the
> box without the need for specialized drivers.
> 
> A unique aspect of HAWQ is its integration of statistical and machine
> learning capabilities that can be natively invoked from SQL or (in the
> context of PL/Python, PL/Java or PL/R) in massively parallel modes and
> applied to large data sets across a Hadoop cluster. These capabilities
> are provided through MADlib – an existing open source, parallel
> machine-learning library. Given the close ties between the two
> development communities, the MADlib community has expressed interest
> in joining HAWQ on its journey into the ASF Incubator and will be
> submitting a separate, concurrent proposal.
> 
> HAWQ will provide more robust and higher performing options for Hadoop
> environments that demand best-in-class data analytics for business
> critical purposes. HAWQ is implemented in C and C++.
> 
> HAWQ has a few runtime dependencies licensed under the Cat X list:
>  * gperf (GPL Version 3)
>  * libgsasl (LGPL Version 2.1)
>  * libuuid-2.26 (LGPL Version 2)
> However, given the runtime (dynamic linking) nature of these
> dependencies it doesn't represent a problem for HAWQ to be considered
> an ASF project.
> 
> == Proposal ==
> The goal of this proposal is to bring the core of Pivotal Software,
> Inc.’s (Pivotal) Pivotal HAWQⓇ codebase into the Apache Software
> Foundation (ASF) in order to build a vibrant, diverse and
> self-governed open source community around the technology. Pivotal has
> agreed to transfer the brand name "HAWQ" to Apache Software Foundation
> and will stop using HAWQ to refer to this software if the project gets
> accepted into the ASF Incubator under the name of "Apache HAWQ
> (incubating)". Pivotal will continue to market and sell an analytic
> engine product that includes Apache HAWQ (incubating). While HAWQ is
> our primary choice for a name of the project, in anticipation of any
> potential issues with PODLINGNAMESEARCH we have come up with two
> alternative names: (1) Hornet; or (2) Grove.
> 
> Pivotal is submitting this proposal to donate the HAWQ source code and
> associated artifacts (documentation, web site content, wiki, etc.) to
> the Apache Software Foundation Incubator under the Apache License,
> Version 2.0 and is asking Incubator PMC to establish an open source
> community.
> 
> == Background ==
> While the ecosystem of open source SQL-on-Hadoop solutions is fairly
> developed by now, HAWQ has several unique features that will set it
> apart from existing ASF and non-ASF projects. HAWQ made its debut in
> 2013 as a closed source product leveraging a decade's worth of product
> development effort invested in Greenplum DatabaseⓇ. Since then HAWQ
> has rapidly gained a solid customer base and became available on
> non-Pivotal distributions of Hadoop.
> In 2015 HAWQ still leverages the rock solid foundation of Greenplum
> Database, while at the same time embracing elasticity and resource
> management native to Hadoop applications. This allows HAWQ to provide
> superior SQL on Hadoop performance, scalability and coverage while
> also providing massively-parallel machine learning capabilities and
> support for native Hadoop file formats. In addition, HAWQ's advanced
> features include support for complex joins, rich and compliant SQL
> dialect and industry-differentiating data federation capabilities.
> Dynamic pipelining and pluggable query optimizer architecture enable
> HAWQ to perform queries on Hadoop with the speed and scalability
> required for enterprise data warehouse (EDW) workloads. HAWQ provides
> strong support for low-latency analytic SQL queries, coupled with
> massively parallel machine learning capabilities. This 

Re: [VOTE] Accept Horn into the ASF incubator

[Hitesh Shah]

+1

— Hitesh

On Aug 31, 2015, at 4:13 PM, Edward J. Yoon  wrote:

> Hi folks,
> 
> I would like to call a vote to accept Horn, as a new Apache Incubator
> project. The full proposal is available at the end of this mail and as
> a https://wiki.apache.org/incubator/HornProposal (the changes from
> initial discussion draft are addition of 2 committers from cldi-kaist
> team and Rich as a mentor).
> 
> The VOTE is open for at least the next 72 hours:
> 
> [ ] +1 Accept Horn into the Apache Incubator
> [ ] 0
> [ ] -1 Do not accept Horn into the Apache Incubator bc ..
> 
> I'd like to get the voting started w/ my own +1
> 
> Thanks!
> 
> == Abstract ==
> 
> Horn [hɔ:n] (korean meaning of Horn is a "Spirit") is a neuron-centric
> programming APIs and execution framework for large-scale deep
> learning, built on top of Apache Hama.
> 
> == Proposal ==
> 
> It is a goal of the Horn to provide a neuron-centric programming APIs
> which allows user to easily define the characteristic of artificial
> neural network model and its structure, and its execution framework
> that leverages the heterogeneous resources on Hama and Hadoop YARN
> cluster.
> 
> == Background ==
> 
> The initial ANN code was developed at Apache Hama project by a
> committer, Yexi Jiang (Facebook) in 2013. The motivation behind this
> work is to build a framework that provides more intuitive programming
> APIs like Google's MapReduce or Pregel and supports applications
> needing large model with huge memory consumptions in distributed way.
> 
> == Rationale ==
> 
> While many of deep learning open source softwares such as Caffe,
> DeepDist, DL4j, and NeuralGiraph are still data or model parallel
> only, we aim to support both data and model parallelism and also
> fault-tolerant system design. The basic idea of data and model
> parallelism is use of the remote parameter server to parallelize model
> creation and distribute training across machines, and the BSP
> framework of Apache Hama for performing asynchronous mini-batches.
> Within single BSP job, each task group works asynchronously using
> region barrier synchronization instead of global barrier
> synchronization, and trains large-scale neural network model using
> assigned data sets in BSP paradigm. Thus, we achieve data and model
> parallelism. This architecture is inspired by Google's !DistBelief
> (Jeff Dean et al, 2012).
> 
> == Initial Goals ==
> 
> Some current goals include:
> 
> * builds new community
> * provides more intuitive programming APIs
> * needs both data and model parallelism support
> * must run natively on both Hama and Hadoop2
> * needs also GPUs and InfiniBand support (FPGAs if possible)
> 
> == Current Status ==
> 
> === Meritocracy ===
> 
> The core developers understand what it means to have a process based
> on meritocracy. We will provide continuous efforts to build an
> environment that supports this, encouraging community members to
> contribute.
> 
> === Community ===
> 
> A small community has formed within the Apache Hama project community,
> universities, and companies such as deep learning startup, instant
> messenger service company, and mobile manufacturing company. And many
> people are interested in the large-scale deep learning platform
> itself. By bringing Horn into Apache, we believe that the community
> will grow even bigger.
> 
> === Core Developers ===
> 
> Edward J. Yoon, Thomas Jungblut, Jungin Lee, and Minho Kim
> 
> == Known Risks ==
> 
> === Orphaned Products ===
> 
> Apache Hama is already a core open source component at Samsung
> Electronics, and Horn also will be used by Samsung Electronics and
> Cldi Inc., and so there is no direct risk for this project to be
> orphaned.
> 
> === Inexperience with Open Source ===
> 
> Some are very new and the others have experience using and/or working
> on Apache open source projects.
> 
> === Homogeneous Developers ===
> 
> The initial committers are from different organizations such as,
> Microsoft, Samsung Electronics, Seoul National University, Technical
> University of Munich, KAIST, LINE plus, and Cldi Inc.
> 
> === Reliance on Salaried Developers ===
> 
> Few will be worked as a full-time open source developer. Other
> developers will also start working on the project in their spare time.
> 
> === Relationships with Other Apache Products ===
> 
> * Horn is based on Apache Hama
> * Apache Zookeeper is used for distributed locking service
> * Natively run on Apache Hadoop and Mesos
> * Horn can be somewhat overlapped with Singa podling (If possible,
> we'd also like to use Singa or Caffe to do the heavy lifting part).
> 
> === An Excessive Fascination with the Apache Brand ===
> 
> Horn itself will hopefully have benefits from Apache, in terms of
> attracting a community and establishing a solid group of developers,
> but also the relation with Apache Hadoop, Zookeeper, and Hama. These
> are the main reasons for us to send this proposal.
> 
> == Documentation ==
> 
> Initial plan about Horn can b

Re: [VOTE] Graduate Calcite from the Apache Incubator

[Hitesh Shah]

+1

— Hitesh 

On Sep 14, 2015, at 6:56 PM, Julian Hyde  wrote:

> This is a vote for Calcite to become a top-level project.
> 
> Since joining the Incubator in May, 2014, the Calcite
> community has:
> * Produced eight IPMC-approved releases under two release
>  managers;
> * Added five new committers and one new PPMC member;
> * Collaborated successfully with several other Apache
> projects (Drill, Hive, Kylin, Phoenix, Samza);
> * Grown into an active community (typical monthly activity
>  is 100 emails, 30 commits and 20 issues fixed);
> * Conducted a successful community vote to graduate with
>  20 +1 votes, of which 2 were from our mentors, 12 were
>  from committers, and 6 were from IPMC members.
> 
> Further information: the discussion on the dev list [1],
> vote thread [2] and result [3]. Also relevant are the
> incubation status page [4] and a thread on this list
> requesting review of whether Calcite met the criteria to
> graduate [5].
> 
> Below is our proposed resolution for the Board.
> 
> Please vote:
> 
> [ ] +1 Graduate Apache Calcite as a top-level project
> [ ] +0
> [ ] -1 Do not graduate Apache Calcite because…
> 
> Here is my vote:
> +1 (binding)
> 
> Voting will last 72 hours, ending at 19:00 Pacific on
> September 17th.
> 
> Julian Hyde, on behalf of Calcite PPMC
> 
> [1] http://s.apache.org/ZPC
> [2] http://s.apache.org/rvB
> [3] http://s.apache.org/sv
> [4] http://incubator.apache.org/projects/calcite.html
> [5] http://s.apache.org/itP
> 
> - - - 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 parsing and planning queries on data in a
> wide variety of formats.
> 
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> Committee (PMC), to be known as the "Apache Calcite
> Project", be and hereby is established pursuant to Bylaws of
> the Foundation; and be it further
> 
> RESOLVED, that the Apache Calcite Project be and hereby is
> responsible for the creation and maintenance of software
> related to parsing and planning queries on data in a wide
> variety of formats; and be it further
> 
> RESOLVED, that the office of "Vice President, Apache
> Calcite" 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 Calcite Project, and to have
> primary responsibility for management of the projects within
> the scope of responsibility of the Apache Calcite 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 Calcite Project:
> 
> * Alan Gates 
> * Aman Sinha 
> * Ashutosh Chauhan 
> * James R. Taylor 
> * Jacques Nadeau 
> * Jesús Camacho Rodríguez 
> * Jinfeng Ni 
> * John Pullokkaran 
> * Julian Hyde 
> * Nick Dimiduk 
> * Steven Noels 
> * Ted Dunning 
> * Vladimir Sitnikov 
> 
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Julian Hyde be
> appointed to the office of Vice President, Apache Calcite,
> 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 Calcite Project be and hereby is
> tasked with the migration and rationalization of the Apache
> Incubator Calcite podling; and be it further
> 
> RESOLVED, that all responsibilities pertaining to the Apache
> Incubator Calcite podling encumbered upon the Apache
> Incubator Project are hereafter discharged.
> 
> - - - end - - -
> 
> 
> -
> 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 Eagle into Apache Incubation

[Hitesh Shah]

+1 (binding)

— Hitesh

On Oct 23, 2015, at 7:11 AM, Manoharan, Arun  wrote:

> Hello Everyone,
> 
> Thanks for all the feedback on the Eagle Proposal.
> 
> I would like to call for a [VOTE] on Eagle joining the ASF as an incubation 
> project.
> 
> The vote is open for 72 hours:
> 
> [ ] +1 accept Eagle in the Incubator
> [ ] ±0
> [ ] -1 (please give reason)
> 
> Eagle is a Monitoring solution for Hadoop to instantly identify access to 
> sensitive data, recognize attacks, malicious activities and take actions in 
> real time. Eagle supports a wide variety of policies on HDFS data and Hive. 
> Eagle also provides machine learning models for detecting anomalous user 
> behavior in Hadoop.
> 
> The proposal is available on the wiki here:
> https://wiki.apache.org/incubator/EagleProposal
> 
> The text of the proposal is also available at the end of this email.
> 
> Thanks for your time and help.
> 
> Thanks,
> Arun
> 
> 
> 
> Eagle
> 
> Abstract
> Eagle is an Open Source Monitoring solution for Hadoop to instantly identify 
> access to sensitive data, recognize attacks, malicious activities in hadoop 
> and take actions.
> 
> Proposal
> Eagle audits access to HDFS files, Hive and HBase tables in real time, 
> enforces policies defined on sensitive data access and alerts or blocks 
> user’s access to that sensitive data in real time. Eagle also creates user 
> profiles based on the typical access behaviour for HDFS and Hive and sends 
> alerts when anomalous behaviour is detected. Eagle can also import sensitive 
> data information classified by external classification engines to help define 
> its policies.
> 
> Overview of Eagle
> Eagle has 3 main parts.
> 1.Data collection and storage - Eagle collects data from various hadoop logs 
> in real time using Kafka/Yarn API and uses HDFS and HBase for storage.
> 2.Data processing and policy engine - Eagle allows users to create policies 
> based on various metadata properties on HDFS, Hive and HBase data.
> 3.Eagle services - Eagle services include policy manager, query service and 
> the visualization component. Eagle provides intuitive user interface to 
> administer Eagle and an alert dashboard to respond to real time alerts.
> 
> Data Collection and Storage:
> Eagle provides programming API for extending Eagle to integrate any data 
> source into Eagle policy evaluation framework. For example, Eagle hdfs audit 
> monitoring collects data from Kafka which is populated from namenode log4j 
> appender or from logstash agent. Eagle hive monitoring collects hive query 
> logs from running job through YARN API, which is designed to be scalable and 
> fault-tolerant. Eagle uses HBase as storage for storing metadata and metrics 
> data, and also supports relational database through configuration change.
> 
> Data Processing and Policy Engine:
> Processing Engine: Eagle provides stream processing API which is an 
> abstraction of Apache Storm. It can also be extended to other streaming 
> engines. This abstraction allows developers to assemble data transformation, 
> filtering, external data join etc. without physically bound to a specific 
> streaming platform. Eagle streaming API allows developers to easily integrate 
> business logic with Eagle policy engine and internally Eagle framework 
> compiles business logic execution DAG into program primitives of underlying 
> stream infrastructure e.g. Apache Storm. For example, Eagle HDFS monitoring 
> transforms audit log from Namenode to object and joins sensitivity metadata, 
> security zone metadata which are generated from external programs or 
> configured by user. Eagle hive monitoring filters running jobs to get hive 
> query string and parses query string into object and then joins sensitivity 
> metadata.
> Alerting Framework: Eagle Alert Framework includes stream metadata API, 
> scalable policy engine framework, extensible policy engine framework. Stream 
> metadata API allows developers to declare event schema including what 
> attributes constitute an event, what is the type for each attribute, and how 
> to dynamically resolve attribute value in runtime when user configures 
> policy. Scalable policy engine framework allows policies to be executed on 
> different physical nodes in parallel. It is also used to define your own 
> policy partitioner class. Policy engine framework together with streaming 
> partitioning capability provided by all streaming platforms will make sure 
> policies and events can be evaluated in a fully distributed way. Extensible 
> policy engine framework allows developer to plugin a new policy engine with a 
> few lines of codes. WSO2 Siddhi CEP engine is the policy engine which Eagle 
> supports as first-class citizen.
> Machine Learning module: Eagle provides capabilities to define user activity 
> patterns or user profiles for Hadoop users based on the user behaviour in the 
> platform. These user profiles are modeled using Machine Learning algorithms 
> and used for detection

Re: [DISCUSS] SystemML Incubator Proposal

[Hitesh Shah]

Hi Luciano, 

If you need any additional mentors, let me know. I would be interested in 
helping out. 

thanks
— Hitesh 


On Oct 23, 2015, at 4:34 PM, Luciano Resende  wrote:

> We would like to start a discussion on accepting SystemML as an Apache
> Incubator project.
> 
> The proposal is available at :
> https://wiki.apache.org/incubator/SystemM
> 
> And it's contents is also copied below.
> 
> Thanks in Advance for you time reviewing and providing feedback.
> 
> ==
> 
> = SystemML =
> 
> == Abstract ==
> 
> SystemML provides declarative large-scale machine learning (ML) that aims
> at flexible specification of ML algorithms and automatic generation of
> hybrid runtime plans ranging from single node, in-memory computations, to
> distributed computations on Apache Hadoop and  Apache Spark. ML algorithms
> are expressed in an R-like syntax, that includes linear algebra primitives,
> statistical functions, and ML-specific constructs. This high-level language
> significantly increases the productivity of data scientists as it provides
> (1) full flexibility in expressing custom analytics, and (2) data
> independence from the underlying input formats and physical data
> representations. Automatic optimization according to data characteristics
> such as distribution on the disk file system, and sparsity as well as
> processing characteristics in the distributed environment like number of
> nodes, CPU, memory per node, ensures both efficiency and scalability.
> 
> == Proposal ==
> 
> The goal of SystemML is to create a commercial friendly, scalable and
> extensible machine learning framework for data scientists to create or
> extend machine learning algorithms using a declarative syntax. The machine
> learning framework enables data scientists to develop algorithms locally
> without the need of a distributed cluster, and scale up and scale out the
> execution of these algorithms to distributed Hadoop or Spark clusters.
> 
> == Background ==
> 
> SystemML started as a research project in the IBM Almaden Research Center
> around 2010 aiming to enable data scientists to develop machine learning
> algorithms independent of data and cluster characteristics.
> 
> == Rationale ==
> 
> SystemML enables the specification of machine learning algorithms using a
> declarative machine learning (DML) language. DML includes linear algebra
> primitives, statistical functions, and additional constructs. This
> high-level language significantly increases the productivity of data
> scientists as it provides (1) full flexibility in expressing custom
> analytics and (2) data independence from the underlying input formats and
> physical data representations.
> 
> SystemML computations can be executed in a variety of different modes. It
> supports single node in-memory computations and large-scale distributed
> cluster computations. This allows the user to quickly prototype new
> algorithms in local environments but automatically scale to large data
> sizes as well without changing the algorithm implementation.
> 
> Algorithms specified in DML are dynamically compiled and optimized based on
> data and cluster characteristics using rule-based and cost-based
> optimization techniques. The optimizer automatically generates hybrid
> runtime execution plans ranging from in-memory single-node execution to
> distributed computations on Spark or Hadoop. This ensures both efficiency
> and scalability. Automatic optimization reduces or eliminates the need to
> hand-tune distributed runtime execution plans and system configurations.
> 
> == Initial Goals ==
> 
> The initial goals to move SystemML to the Apache Incubator is to broaden
> the community foster the contributions from data scientists to develop new
> machine learning algorithms and enhance the existing ones. Ultimately, this
> may lead to the creation of an industry standard in specifying machine
> learning algorithms.
> 
> == Current Status ==
> 
> The initial code has been developed at the IBM Almaden Research Center in
> California and has recently been made available in GitHub under the Apache
> Software License 2.0. The project currently supports a single node (in
> memory computation) as well as distributed computations utilizing Hadoop or
> Spark clusters.
> 
> === Meritocracy ===
> 
> We plan to invest in supporting a meritocracy. We will discuss the
> requirements in an open forum. Several companies have already expressed
> interest in this project, and we intend to invite additional developers to
> participate. We will encourage and monitor community participation so that
> privileges can be extended to those that contribute operating to the
> standard of meritocracy that Apache emphasizes.
> 
> === Community ===
> 
> The need for a generic scalable and declarative machine learning approach
> in the open source is tremendous, so there is a potential for a very large
> community. We believe that SystemML’s extensible architecture, declarative
> syntax, cost base

Re: [VOTE] Apache Apex Core Release 3.2.0-incubating (RC2)

[Hitesh Shah]

+1 (binding)

thanks
— Hitesh


On Oct 27, 2015, at 1:39 PM, Thomas Weise  wrote:

> Hi,
> 
> Please vote on the following Apache Apex Core 3.2.0-incubating release
> candidate. This is the first release after incubation. This is a source
> release.
> 
> The Apache Apex PPMC has voted to release this candidate.
> 
> The community vote passed with 6 binding votes from the PPMC (including 3
> votes from IPMC members). There were another 9 committer votes in favor of
> the release.
> 
> PPMC vote call:
> 
> http://mail-archives.apache.org/mod_mbox/incubator-apex-dev/201510.mbox/%3CCAKJfLDM5wnzmz8CcVbv6d2QM%2BAsaJ6pQ3EyG%2B8XRbSwYkfPX_g%40mail.gmail.com%3E
> 
> PPMC vote result:
> 
> http://mail-archives.apache.org/mod_mbox/incubator-apex-dev/201510.mbox/%3CCAKJfLDOY-SpcJfdFiJosoyZ2JidursecietvhT5AgUeX-%3Dw-Tw%40mail.gmail.com%3E
> 
> 
> List of all issues fixed: http://s.apache.org/SRM
> 
> Staging directory:
> https://dist.apache.org/repos/dist/dev/incubator/apex/v3.2.0-incubating-RC2/
> Source zip:
> https://dist.apache.org/repos/dist/dev/incubator/apex/v3.2.0-incubating-RC2/apex-3.2.0-incubating-source-release.zip
> Source tar.gz:
> https://dist.apache.org/repos/dist/dev/incubator/apex/v3.2.0-incubating-RC2/apex-3.2.0-incubating-source-release.tar.gz
> Maven staging repository:
> https://repository.apache.org/content/repositories/orgapacheapex-1001/
> 
> Git source:
> https://git-wip-us.apache.org/repos/asf?p=incubator-apex-core.git;a=commit;h=refs/tags/v3.2.0-incubating-RC2
>  (commit: d61ca617fd44bf9d74800838341f92018f2c7d10)
> 
> PGP key:
> *http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=t...@apache.org
> *
> KEYS file:
> https://dist.apache.org/repos/dist/release/incubator/apex/KEYS
> 
> More information at:
> http://apex.incubator.apache.org
> 
> 
> Please try the release and vote; vote will close after 72 hours.
> 
> [ ] +1 approve
> [ ] -1 disapprove (and reason why)
> 
> http://www.apache.org/foundation/voting.html
> 
> Please add (binding) if your vote is binding.
> 
> Thanks,
> Thomas


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

Re: [VOTE] Graduate REEF

[Hitesh Shah]

+1 (binding)

— Hitesh 

On Nov 9, 2015, at 1:14 PM, Markus Weimer  wrote:

> This is the vote to decide if Apache REEF should graduate from
> the Incubator. Please see the proposed resolution below.
> 
> This proposal was discussed [0] and voted upon [1] by the REEF community
> and has been discussed [2] on this list.
> 
> This vote is open for at least 72 hours.
> 
> [ ] +1 Graduate Apache REEF from the Incubator.
> [ ] +0 Don't care.
> [ ] -1 Don't graduate Apache REEF from the Incubator because ...
> 
> Thanks,
> 
> Markus
> 
> [0]: http://s.apache.org/reefgraduationdiscussion
> [1]: http://s.apache.org/reefgraduationppmsvoteresult
> [2]: http://s.apache.org/reefgraduationdiscussionongeneral
> 
> 
> X. Establish the Apache REEF 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 application development on top of
>resource managers.
> 
>NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>Committee (PMC), to be known as the "Apache REEF Project",
>be and hereby is established pursuant to Bylaws of the
>Foundation; and be it further
> 
>RESOLVED, that the Apache REEF Project be and hereby is
>responsible for the creation and maintenance of a software
>framework for application development on top of resource
>managers; and be it further
> 
>RESOLVED, that the office of "Vice President, Apache REEF"
>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 REEF Project, and to have primary
>responsibility for management of the projects within the scope
>of responsibility of the Apache REEF 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 REEF Project Management Committee:
> 
>* Markus Weimer 
>* Byung-Gon Chun 
>* Yunseong Lee 
>* Brian Cho 
>* Beysim Sezgin 
>* Yingda Chen 
>* Julia Wang 
>* Andrew Chung 
>* Youngseok Yang 
>* Gyewon Lee 
>* Taegeon Um 
>* Joo Seong Jeong 
>* Geon-Woo Kim 
>* Mariia Mykhailova 
>* Shravan M Narayanamurthy 
>* Dongjoon Hyun 
>* Sergiy Matusevych 
>* Tyson Condie 
>* Chris Mattman 
>* Chris Douglas 
>* Boris Shulman 
> 
>NOW, THEREFORE, BE IT FURTHER RESOLVED, that Markus Weimer be
>appointed to the office of Vice President, Apache REEF, 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 initial Apache REEF Project be and hereby
>is tasked with the creation of a set of bylaws intended to
>encourage open development and increased participation in the
>Apache REEF Project; and be it further
> 
>RESOLVED, that the initial Apache REEF Project be and hereby
>is tasked with the migration and rationalization of the Apache
>Incubator REEF podling; and be it further
> 
>RESOLVED, that all responsibility pertaining to the Apache
>Incubator REEF podling encumbered upon the Apache Incubator
>PMC are hereafter discharged.
> 
> -
> 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] Spark-Kernel Incubator Proposal

[Hitesh Shah]

Hi David, 

I would be happy to help out as a mentor.

thanks
— Hitesh

On Nov 12, 2015, at 4:17 PM, da...@fallside.com wrote:

> Hello, we would like to start a discussion on accepting the Spark-Kernel,
> a mechanism for applications to interactively and remotely access Apache
> Spark, into the Apache Incubator.
> 
> The proposal is available online at
> https://wiki.apache.org/incubator/SparkKernelProposal, and it is appended
> to this email.
> 
> We are looking for additional mentors to help with this project, and we
> would much appreciate your guidance and advice.
> 
> Thank-you in advance,
> David Fallside
> 
> 
> 
> = Spark-Kernel Proposal =
> 
> == Abstract ==
> Spark-Kernel provides applications with a mechanism to interactively and
> remotely access Apache Spark.
> 
> == Proposal ==
> The Spark-Kernel enables interactive applications to access Apache Spark
> clusters. More specifically:
> * Applications can send code-snippets and libraries for execution by Spark
> * Applications can be deployed separately from Spark clusters and
> communicate with the Spark-Kernel using the provided Spark-Kernel client
> * Execution results and streaming data can be sent back to calling
> applications
> * Applications no longer have to be network connected to the workers on a
> Spark cluster because the Spark-Kernel acts as each application’s proxy
> * Work has started on enabling Spark-Kernel to support languages in
> addition to Scala, namely Python (with PySpark), R (with SparkR), and SQL
> (with SparkSQL)
> 
> == Background & Rationale ==
> Apache Spark provides applications with a fast and general purpose
> distributed computing engine that supports static and streaming data,
> tabular and graph representations of data, and an extensive library of
> machine learning libraries. Consequently, a wide variety of applications
> will be written for Spark and there will be interactive applications that
> require relatively frequent function evaluations, and batch-oriented
> applications that require one-shot or only occasional evaluation.
> 
> Apache Spark provides two mechanisms for applications to connect with
> Spark. The primary mechanism launches applications on Spark clusters using
> spark-submit
> (http://spark.apache.org/docs/latest/submitting-applications.html); this
> requires developers to bundle their application code plus any dependencies
> into JAR files, and then submit them to Spark. A second mechanism is an
> ODBC/JDBC API
> (http://spark.apache.org/docs/latest/sql-programming-guide.html#distributed-sql-engine)
> which enables applications to issue SQL queries against SparkSQL.
> 
> Our experience when developing interactive applications, such as analytic
> applications and Jupyter Notebooks, to run against Spark was that the
> spark-submit mechanism was overly cumbersome and slow (requiring JAR
> creation and forking processes to run spark-submit), and the SQL interface
> was too limiting and did not offer easy access to components other than
> SparkSQL, such as streaming. The most promising mechanism provided by
> Apache Spark was the command-line shell
> (http://spark.apache.org/docs/latest/programming-guide.html#using-the-shell)
> which enabled us to execute code snippets and dynamically control the
> tasks submitted to  a Spark cluster. Spark does not provide the
> command-line shell as a consumable service but it provided us with the
> starting point from which we developed the Spark-Kernel.
> 
> == Current Status ==
> Spark-Kernel was first developed by a small team working on an
> internal-IBM Spark-related project in July 2014. In recognition of its
> likely general utility to Spark users and developers, in November 2014 the
> Spark-Kernel project was moved to GitHub and made available under the
> Apache License V2.
> 
> == Meritocracy ==
> The current developers are familiar with the meritocratic open source
> development process at Apache. As the project has gathered interest at
> GitHub the developers have actively started a process to invite additional
> developers into the project, and we have at least one new developer who is
> ready to contribute code to the project.
> 
> == Community ==
> We started building a community around the Spark-Kernel project when we
> moved it to GitHub about one year ago. Since then we have grown to about
> 70 people, and there are regular requests and suggestions from the
> community. We believe that providing Apache Spark application developers
> with a general-purpose and interactive API holds a lot of community
> potential, especially considering possible tie-in’s with the Jupyter and
> data science community.
> 
> == Core Developers ==
> The core developers of the project are currently all from IBM, from the
> IBM Emerging Technology team and from IBM’s recently formed Spark
> Technology Center.
> 
> == Alignment ==
> Apache, as the home of Apache Spark, is the most natural home for the
> Spark-Kernel project because it was designed to work with Apa

Re: [VOTE] Apache Apex Malhar Release 3.2.0-incubating (RC2)

[Hitesh Shah]

+1 (binding). Carried over vote from dev list.

thanks
— Hitesh

On Nov 13, 2015, at 9:30 PM, Thomas Weise  wrote:

> Hi,
> 
> Please vote on the following Apache Apex Malhar 3.2.0-incubating release
> candidate. This is the first release of the Malhar library in ASF and it is
> based on Apex core 3.2.0-incubating. This is a source release.
> 
> The Apache Apex PPMC has voted to release this candidate.
> 
> The community vote passed with 14 binding votes from the PPMC (including 3
> votes from IPMC members).
> 
> PPMC vote call:
> 
> http://mail-archives.apache.org/mod_mbox/incubator-apex-dev/201511.mbox/%3CCAKJfLDMWgzncdN7-nxXksE3F2p3xLfCu%2B_nNL-q6p-H_kwASdA%40mail.gmail.com%3E
> 
> PPMC vote result:
> 
> http://mail-archives.apache.org/mod_mbox/incubator-apex-dev/201511.mbox/%3CCAKJfLDPnu2vJZyt%3D9JNmt3nG_nHYk%2B3AseE__SN%3DKXmJ5AskeQ%40mail.gmail.com%3E
> 
> List of all issues fixed: http://s.apache.org/2fZ
> 
> Staging directory:
> https://dist.apache.org/repos/dist/dev/incubator/apex/malhar/v3.2.0-incubating-RC2
> Source zip:
> https://dist.apache.org/repos/dist/dev/incubator/apex/malhar/v3.2.0-incubating-RC2/malhar-3.2.0-incubating-source-release.zip
> Source tar.gz:
> https://dist.apache.org/repos/dist/dev/incubator/apex/malhar/v3.2.0-incubating-RC2/malhar-3.2.0-incubating-source-release.tar.gz
> Maven staging repository:
> https://repository.apache.org/content/repositories/orgapacheapex-1003/
> 
> Git source:
> https://git-wip-us.apache.org/repos/asf?p=incubator-apex-malhar.git;a=commit;h=refs/tags/v3.2.0-incubating-RC2
> (commit:
> ff0b0d080ebd8d00cee47321df90dad9357bbead)
> 
> PGP key:
> http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=t...@apache.org
> KEYS file:
> https://dist.apache.org/repos/dist/release/incubator/apex/KEYS
> 
> More information at:
> http://apex.incubator.apache.org
> 
> Please try the release and vote; vote will close after 72 hours.
> 
> [ ] +1 approve
> [ ] -1 disapprove (and reason why)
> 
> http://www.apache.org/foundation/voting.html
> 
> Please add (binding) if your vote is binding.
> 
> Thanks,
> Thomas


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

Re: [VOTE] Accept Impala into the Apache Incubator

[Hitesh Shah]

+1 (binding)

— Hitesh

On Nov 24, 2015, at 1:03 PM, Henry Robinson  wrote:

> Hi -
> 
> The [DISCUSS] thread has been quiet for a few days, so I think there's been
> sufficient opportunity for discussion around our proposal to bring Impala
> to the ASF Incubator.
> 
> I'd like to call a VOTE on that proposal, which is on the wiki at
> https://wiki.apache.org/incubator/ImpalaProposal, and which I've pasted
> below.
> 
> During the discussion period, the proposal has been amended to add Brock
> Noland as a new mentor, to add one missed committer from the list and to
> correct some issues with the dependency list.
> 
> Please cast your votes as follows:
> 
> [] +1, accept Impala into the Incubator
> [] +/-0, non-counted vote to express a disposition
> [] -1, do not accept Impala into the Incubator (please give your reason(s))
> 
> As with the concurrent Kudu vote, I propose leaving the vote open for a
> full seven days (to close at Tuesday, December 1st at noon PST), due to the
> upcoming US holiday.
> 
> Thanks,
> Henry
> 
> 
> 
> = Abstract =
> Impala is a high-performance C++ and Java SQL query engine for data stored
> in Apache Hadoop-based clusters.
> 
> = Proposal =
> 
> We propose to contribute the Impala codebase and associated artifacts (e.g.
> documentation, web-site content etc.) to the Apache Software Foundation
> with the intent of forming a productive, meritocratic and open community
> around Impala’s continued development, according to the ‘Apache Way’.
> 
> Cloudera owns several trademarks regarding Impala, and proposes to transfer
> ownership of those trademarks in full to the ASF.
> 
> = Background =
> Engineers at Cloudera developed Impala and released it as an
> Apache-licensed open-source project in Fall 2012. Impala was written as a
> brand-new, modern C++ SQL engine targeted from the start for data stored in
> Apache Hadoop clusters.
> 
> Impala’s most important benefit to users is high-performance, making it
> extremely appropriate for common enterprise analytic and business
> intelligence workloads. This is achieved by a number of software
> techniques, including: native support for data stored in HDFS and related
> filesystems, just-in-time compilation and optimization of individual query
> plans, high-performance C++ codebase and massively-parallel distributed
> architecture. In benchmarks, Impala is routinely amongst the very highest
> performing SQL query engines.
> 
> = Rationale =
> 
> Despite the exciting innovation in the so-called ‘big-data’ space, SQL
> remains by far the most common interface for interacting with data in both
> traditional warehouses and modern ‘big-data’ clusters. There is clearly a
> need, as evidenced by the eager adoption of Impala and other SQL engines in
> enterprise contexts, for a query engine that offers the familiar SQL
> interface, but that has been specifically designed to operate in massive,
> distributed clusters rather than in traditional, fixed-hardware,
> warehouse-specific deployments. Impala is one such query engine.
> 
> We believe that the ASF is the right venue to foster an open-source
> community around Impala’s development. We expect that Impala will benefit
> from more productive collaboration with related Apache projects, and under
> the auspices of the ASF will attract talented contributors who will push
> Impala’s development forward at pace.
> 
> We believe that the timing is right for Impala’s development to move
> wholesale to the ASF: Impala is well-established, has been Apache-licensed
> open-source for more than three years, and the core project is relatively
> stable. We are excited to see where an ASF-based community can take Impala
> from this strong starting point.
> 
> = Initial Goals =
> Our initial goals are as follows:
> 
> * Establish ASF-compatible engineering practices and workflows
> * Refactor and publish existing internal build scripts and test
> infrastructure, in order to make them usable by any community member.
> * Transfer source code, documentation and associated artifacts to the ASF.
> * Grow the user and developer communities
> 
> = Current Status =
> 
> Impala is developed as an Apache-licensed open-source project. The source
> code is available at http://github.com/cloudera/Impala, and developer
> documentation is at https://github.com/cloudera/Impala/wiki. The majority
> of commits to the project have come from Cloudera-employed developers, but
> we have accepted some contributions from individuals from other
> organizations.
> 
> All code reviews are done via a public instance of the Gerrit review tool
> at http://gerrit.cloudera.org:8080/, and discussed on a public mailing
> list. All patches must be reviewed before they are accepted into the
> codebase, via a voting mechanism that is similar to that used on Apache
> projects such as Hadoop and HBase.
> 
> Before a patch is committed, it must pass a suite of pre-commit tests.
> These tests are currently run on Cloudera’s internal infrastr

Re: [VOTE] Accept Kudu into the Apache Incubator

[Hitesh Shah]

+1 (binding)

— Hitesh

On Nov 24, 2015, at 11:32 AM, Todd Lipcon  wrote:

> Hi all,
> 
> Discussion on the [DISCUSS] thread seems to have wound down, so I'd like to
> call a VOTE on acceptance of Kudu into the ASF Incubator. The proposal is
> pasted below and also available on the wiki at:
> https://wiki.apache.org/incubator/KuduProposal
> 
> The proposal is unchanged since the original version, except for the
> addition of Carl Steinbach as a Mentor.
> 
> Please cast your votes:
> 
> [] +1, accept Kudu into the Incubator
> [] +/-0, positive/negative non-counted expression of feelings
> [] -1, do not accept Kudu into the incubator (please state reasoning)
> 
> Given the US holiday this week, I imagine many folks are traveling or
> otherwise offline. So, let's run the vote for a full week rather than the
> traditional 72 hours. Unless the IPMC objects to the extended voting
> period, the vote will close on Tues, Dec 1st at noon PST.
> 
> Thanks
> -Todd
> -
> 
> = Kudu Proposal =
> 
> == Abstract ==
> 
> Kudu is a distributed columnar storage engine built for the Apache Hadoop
> ecosystem.
> 
> == Proposal ==
> 
> Kudu is an open source storage engine for structured data which supports
> low-latency random access together with efficient analytical access
> patterns. Kudu distributes data using horizontal partitioning and
> replicates each partition using Raft consensus, providing low
> mean-time-to-recovery and low tail latencies. Kudu is designed within the
> context of the Apache Hadoop ecosystem and supports many integrations with
> other data analytics projects both inside and outside of the Apache
> Software Foundation.
> 
> 
> 
> We propose to incubate Kudu as a project of the Apache Software Foundation.
> 
> == Background ==
> 
> In recent years, explosive growth in the amount of data being generated and
> captured by enterprises has resulted in the rapid adoption of open source
> technology which is able to store massive data sets at scale and at low
> cost. In particular, the Apache Hadoop ecosystem has become a focal point
> for such “big data” workloads, because many traditional open source
> database systems have lagged in offering a scalable alternative.
> 
> 
> 
> Structured storage in the Hadoop ecosystem has typically been achieved in
> two ways: for static data sets, data is typically stored on Apache HDFS
> using binary data formats such as Apache Avro or Apache Parquet. However,
> neither HDFS nor these formats has any provision for updating individual
> records, or for efficient random access. Mutable data sets are typically
> stored in semi-structured stores such as Apache HBase or Apache Cassandra.
> These systems allow for low-latency record-level reads and writes, but lag
> far behind the static file formats in terms of sequential read throughput
> for applications such as SQL-based analytics or machine learning.
> 
> 
> 
> Kudu is a new storage system designed and implemented from the ground up to
> fill this gap between high-throughput sequential-access storage systems
> such as HDFS and low-latency random-access systems such as HBase or
> Cassandra. While these existing systems continue to hold advantages in some
> situations, Kudu offers a “happy medium” alternative that can dramatically
> simplify the architecture of many common workloads. In particular, Kudu
> offers a simple API for row-level inserts, updates, and deletes, while
> providing table scans at throughputs similar to Parquet, a commonly-used
> columnar format for static data.
> 
> 
> 
> More information on Kudu can be found at the existing open source project
> website: http://getkudu.io and in particular in the Kudu white-paper PDF:
> http://getkudu.io/kudu.pdf from which the above was excerpted.
> 
> == Rationale ==
> 
> As described above, Kudu fills an important gap in the open source storage
> ecosystem. After our initial open source project release in September 2015,
> we have seen a great amount of interest across a diverse set of users and
> companies. We believe that, as a storage system, it is critical to build an
> equally diverse set of contributors in the development community. Our
> experiences as committers and PMC members on other Apache projects have
> taught us the value of diverse communities in ensuring both longevity and
> high quality for such foundational systems.
> 
> == Initial Goals ==
> 
> * Move the existing codebase, website, documentation, and mailing lists to
> Apache-hosted infrastructure
> * Work with the infrastructure team to implement and approve our code
> review, build, and testing workflows in the context of the ASF
> * Incremental development and releases per Apache guidelines
> 
> == Current Status ==
> 
>  Releases 
> 
> Kudu has undergone one public release, tagged here
> https://github.com/cloudera/kudu/tree/kudu0.5.0-release
> 
> This initial release was not performed in the typical ASF fashion -- no
> source tarball was released, but rather only convenience b

Re: [VOTE] Accept Torii into Apache Incubator

[Hitesh Shah]

rk Technology
> Center.
> 
> == Alignment ==
> Apache, as the home of Apache Spark, is the most natural home for the Torii
> project because it was designed to work with Apache Spark and to provide
> capabilities for interactive applications and data science tools not
> provided by Spark itself.
> 
> The Torii also has an affinity with Jupyter (jupyter.org) because it uses
> the Jupyter protocol for communications, and so Jupyter Notebooks can
> directly use the Torii as a kernel for communicating with Apache Spark.
> However, we believe that the Torii provides a general-purpose mechanism
> enabling a wider variety of applications than just Notebooks to access
> Spark, and so the Torii’s greatest affinity is with Apache and Apache
> Spark.
> 
> == Known Risks ==
> 
> === Orphaned products ===
> We believe the Torii project has a low-risk of abandonment due to interest
> in its continuing existence from several parties. More specifically, the
> Torii provides a capability that is not provided by Apache Spark today but
> it enables a wider range of applications to leverage Spark. For example,
> IBM uses (and is considering) the Torii in several offerings including its
> IBM Analytics for Apache Spark product in the Bluemix Cloud. There are also
> a couple of other commercial users who are using or considering its use in
> their offerings. Furthermore, Jupyter Notebooks are used by data scientists
> and Spark is gaining popularity as an analytic engine for them. Jupyter
> Notebooks are very easily enabled with the Torii and so there is another
> constituency for it.
> 
> === Inexperience with Open Source ===
> The Torii project has been running as an open-source project (albeit with
> only IBM committers) for the past several months. The project has an active
> issue tracker and due to the interest indicated by the nature and volume of
> requests and comments, the team has publicly stated it is beginning to
> build a process so they can accept third-party contributions to the project.
> 
> === Relationships with Other Apache Products ===
> The Torii has a clear affinity with the Apache Spark project because it is
> designed to  provide capabilities for interactive applications and data
> science tools not provided by Spark itself. The Torii can be a back-end for
> the Zeppelin project currently incubating at Apache. There is interest from
> the Torii community to develop this capability and an experimental branch
> has been started.
> 
> === Homogeneous Developers ===
> The current group of developers working on Torii are all from IBM although
> the group is in the process of expanding its membership to include members
> of the GitHub community who are not from IBM and who have been active in
> the Torii community in GutHub.
> 
> === Reliance on Salaried Developers ===
> The initial committers are full-time employees at IBM although not all work
> on the project full-time.
> 
> === Excessive Fascination with the Apache Brand ===
> We believe the Torii benefits Apache Spark application developers, and we
> are interested in an Apache Torii project to benefit these developers by
> engaging a larger community, facilitating closer ties with the existing
> Spark project, and yes, gaining more visibility for the Torii as a solution.
> 
> === Documentation ===
> Comprehensive documentation including “Getting Started”, API specifications
> and a Roadmap are available from the GitHub project, see
> https://github.com/ibm-et/Torii/wiki.
> 
> === Initial Source ===
> The source code resides at https://github.com/ibm-et/Torii.
> 
> === External Dependencies ===
> The Torii depends upon a number of Apache projects:
> * Spark
> * Hadoop
> * Ivy
> * Commons
> 
> The Torii also depends upon a number of other open source projects:
> * ZeroMQ (LGPL with Static Linking Exception,
> http://zeromq.org/area:licensing)
> * Akka (MIT)
> * JOpt Simple (MIT)
> * Spring Framework Core (Apache v2)
> * Play (Apache v2)
> * SLF4J (MIT)
> * Scala
> * Scalatest (Apache v2)
> * Scalactic (Apache v2)
> * Mockito (MIT)
> 
> == Required Resources ==
> 
> === Mailing lists ===
> 
> * priv...@torii.incubator.apache.org (with moderated subscriptions)
> * comm...@torii.incubator.apache.org
> * d...@torii.incubator.apache.org
> 
> === Git Repository ===
> 
> * https://git-wip-us.apache.org/repos/asf/incubator-torii.git
> 
> === Issue Tracking ===
> 
> * A JIRA issue tracker: https://issues.apache.org/jira/browse/TORII
> 
> == Initial Committers ==
> 
> * Leugim Bustelo (lbustelo AT us DOT ibm DOT com)
> * Jakob Odersky (odersky AT us DOT ibm DOT com)
> * Luciano Resende (lresende AT apache DOT org)
> * Robert Senk

Re: [VOTE] Release Apache Apex Core 3.3.0-incubating (RC2)

[Hitesh Shah]

+1 (binding) - carried over from dev vote.

— Hitesh 

On Feb 4, 2016, at 12:36 AM, Thomas Weise  wrote:

> Hi,
> 
> Please vote on the following Apache Apex Core 3.3.0-incubating release
> candidate.
> 
> The Apache Apex PPMC has voted to release this candidate.
> 
> The community vote passed with 5 binding votes from the PPMC (including 3
> votes from IPMC members). There were another 11 committer votes in favor of
> the release.
> 
> PPMC vote call:
> http://mail-archives.apache.org/mod_mbox/incubator-apex-dev/201602.mbox/%3CCAKJfLDPjMAZc8-NjjyMgtJGDpHkhVpxv8PYnryfiF4zZZufVmA%40mail.gmail.com%3E
> 
> PPMC vote result:
> http://mail-archives.apache.org/mod_mbox/incubator-apex-dev/201602.mbox/%3CCAKJfLDN4CUVn9cgVhAhqeojP4hDUhwjnWRgXD226VOOBPphmUg%40mail.gmail.com%3E
> 
> This is a source release with binary artifacts published to Maven.
> 
> List of all issues fixed: http://s.apache.org/wUB
> 
> Staging directory:
> https://dist.apache.org/repos/dist/dev/incubator/apex/v3.3.0-incubating-RC2
> Source zip:
> https://dist.apache.org/repos/dist/dev/incubator/apex/v3.3.0-incubating-RC2/apex-3.3.0-incubating-source-release.zip
> Source tar.gz:
> https://dist.apache.org/repos/dist/dev/incubator/apex/v3.3.0-incubating-RC2/apex-3.3.0-incubating-source-release.tar.gz
> Maven staging repository:
> https://repository.apache.org/content/repositories/orgapacheapex-1006/
> 
> Git source:
> https://git-wip-us.apache.org/repos/asf?p=incubator-apex-core.git;a=commit;h=refs/tags/v3.3.0-incubating-RC2
> (commit: 5f216a1bd27a94785c9ccada78101f892be95cbe)
> 
> PGP key:
> http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=t...@apache.org
> KEYS file:
> https://dist.apache.org/repos/dist/release/incubator/apex/KEYS
> 
> More information at:
> http://apex.incubator.apache.org
> 
> Please try the release and vote; vote will be open for at least 72 hours.
> 
> Thanks,
> Thomas


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

Re: [VOTE] Apache Apex Malhar Release 3.3.1-incubating (RC1)

[Hitesh Shah]

+1 - carried over from dev list (binding)

thanks
— Hitesh


On Feb 28, 2016, at 9:53 AM, Bhupesh Chawda  wrote:

> Hi,
> 
> Please vote on the following Apache Apex Malhar 3.3.1-incubating release
> candidate.
> 
> The Apache Apex PPMC has voted to release this candidate.
> 
> The community vote passed with 4 binding votes. There were another 3
> committer votes in favor of the release.
> 
> PPMC vote call:
> http://mail-archives.apache.org/mod_mbox/incubator-apex-dev/201602.mbox/%3CCAHvM9d2ZWZAvyhZcWGsKQBQHc_O%2BbC%2BexnppXU8FYyjiWsL8PA%40mail.gmail.com%3E
> 
> PPMC vote result:
> http://mail-archives.apache.org/mod_mbox/incubator-apex-dev/201602.mbox/%3CCAHvM9d01_jUQhtQPSGj11dwWwUqUg2dBfMwKjuxDL2EHBUizRg%40mail.gmail.com%3E
> 
> This is a source release with binary artifacts published to Maven.
> 
> List of all issues fixed: https://s.apache.org/E2rj
> 
> Staging directory:
> https://dist.apache.org/repos/dist/dev/incubator/apex/v3.3.1-incubating-RC1/
> Source zip:
> https://dist.apache.org/repos/dist/dev/incubator/apex/v3.3.1-incubating-RC1/malhar-3.3.1-incubating-source-release.zip
> Source tar.gz:
> https://dist.apache.org/repos/dist/dev/incubator/apex/v3.3.1-incubating-RC1/malhar-3.3.1-incubating-source-release.tar.gz
> Maven staging repository:
> https://repository.apache.org/content/repositories/orgapacheapex-1008
> 
> Git source:
> https://git-wip-us.apache.org/repos/asf?p=incubator-apex-malhar.git;a=commit;h=refs/tags/v3.3.1-incubating-RC1
> (commit: a2a3a0f976f153c6bda83586f6f4df01b596c616)
> 
> PGP key:
> http://pgp.mit.edu:11371/pks/lookup?op=vindex&search=bhup...@apache.org
> KEYS file:
> https://dist.apache.org/repos/dist/release/incubator/apex/KEYS
> 
> More information at:
> http://apex.incubator.apache.org
> 
> Please try the release and vote; vote will be open for at least 72 hours.
> 
> Thanks,
> Bhupesh


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

Re: [VOTE] Accept Airflow into the Incubator

[Hitesh Shah]

/blob/master/LICENSE.txt|mock (BSD)]]
> * [[https://github.com/mtth/hdfs/blob/master/LICENSE|hdfs (MIT)]]
> 
> == Cryptography ==
> 
> None
> 
> == Required Resources ==
> 
> === Mailing Lists ===
> 
> * priv...@airflow.incubator.apache.org (moderated)
> * d...@airflow.incubator.apache.org
> * comm...@airflow.incubator.apache.org
> 
> === Subversion Directory ===
> 
> Git is the preferred source control system: git://git.apache.org/Airflow
> 
> === Issue Tracking ===
> 
> JIRA Airflow (Airflow)
> 
> === Other Resources ===
> 
> The existing code already has unit tests, so we would like a Travis
> instance to run them whenever a new patch is submitted. This can be
> added after project creation.
> 
> == Initial Committers ==
> 
> * Maxime Beauchemin
> * Siddharth Anand
> * Chris Riccomini
> * Bolke de Bruin
> * Arthur Wiedmer
> * Dan Davydov
> * Jeremiah Lowin
> * Patrick Leo Tardif
> 
> == Affiliations ==
> 
> * Maxime Beauchemin (Airbnb)
> * Siddharth Anand (Agari)
> * Chris Riccomini (WePay)
> * Bolke de Bruin (ING)
> * Arthur Wiedmer (Airbnb)
> * Dan Davydov (Airbnb)
> * Jeremiah Lowin (Kokino)
> * Patrick Leo Tardif (Airbnb)
> 
> == Sponsors ==
> 
> === Champion ===
> 
> Chris Riccomini (WePay, Apache Samza PMC)
> 
> === Nominated Mentors ===
> 
> * Chris Nauroth (HortonWorks, Apache Hadoop Committer/PMC Member,
> Apache ZooKeeper Committer, Apache Software Foundation Member)
> * Hitesh Shah (HortonWorks, Apache Hadoop Committer/PMC Member,
> Apache Ambari Committer/PMC Member, Apache Tez Committer/PMC Member,
> Apache Software Foundation Member)
> * Jakob Homan (OfferUp, Apache Hadoop Committer/PMC Member, Apache
> Kafka Committer/PMC Member, Apache Samza Committer/PMC Member, Apache
> Giraph Committer/PMC Member,  Apache Software Foundation Member)
> 
> === Sponsoring Entity ===
> 
> We are requesting the Incubator to sponsor this project.


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

Re: [VOTE] Graduate Apex from the Incubator

[Hitesh Shah]

+1 (binding)

— Hitesh

On Mar 28, 2016, at 2:20 PM, Pramod Immaneni  wrote:

> The Apache Apex community has discussed and voted on graduation to top
> level project.
> The vote passed with 42 +1 votes (12 from the PPMC) and no 0 or -1 votes.
> 
> Maturity Assessment:
> http://apex.incubator.apache.org/maturity.html
> Discussion:
> https://s.apache.org/qrvY
> Vote:
> https://s.apache.org/R8MR
> Result:
> https://s.apache.org/sJIC
> 
> Please vote on the resolution pasted below to graduate Apache Apex
> from the incubator to top level project.
> 
> [ ] +1 Graduate Apache Apex from the Incubator.
> [ ] +0 Don't care.
> [ ] -1 Don't graduate Apache Apex from the Incubator becauseÖ
> 
> This vote will be open for at least 72 hours.
> 
> Many thanks to our mentors and everyone else for the support,
> 
> Pramod Immaneni, for the Apache Apex PPMC


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

Re: [VOTE] Graduate Zeppelin from the Incubator

[Hitesh Shah]

+1 (binding)

— Hitesh 

On Apr 16, 2016, at 2:01 AM, moon soo Lee  wrote:

> Hi,
> 
> Apache Zeppelin started incubating about a year and 4 months ago
> (2014-12-23) and the members of the community think that it is ready to
> graduate from the incubator to be a TLP.
> 
> Since it's inception, Zeppelin community has made 3 releases, recruited 4
> PPMC and resolved 500+ issues [1] with 90+ contributors [2]. Now, community
> is very open, active and continuously growing.
> 
> The Apache Zeppelin community has discussed and voted on graduation to
> top level
> project.
> The vote passed with 22 +1 votes (9 binding) and no 0 or -1 votes.
> 
> Incubation Status:
> http://incubator.apache.org/projects/zeppelin.html
> Maturity Assessment:
> https://cwiki.apache.org/confluence/display/ZEPPELIN/Apache+Zeppelin+Project+Maturity+Model
> Discussion:
> https://s.apache.org/gLi0
> https://s.apache.org/GhqY (continue)
> Vote:
> https://s.apache.org/7hCK
> Result:
> https://s.apache.org/1rJD
> 
> Please vote on the resolution pasted below to graduate Apache Zeppelin
> from the incubator to top level project.
> 
> [ ] +1 Graduate Apache Zeppelin from the Incubator.
> [ ] +0 Don't care.
> [ ] -1 Don't graduate Apache Zeppelin from the Incubator because
> 
> This vote will be open for at least 72 hours.
> Many thanks to our mentors and everyone else for the support,
> 
> [1] https://s.apache.org/eswD
> [2] https://s.apache.org/gi3o
> 
> Apache Zeppelin top-level project resolution:
> 
> 
> 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 a collaborative data analytics and
> visualization tool for general-purpose data processing systems.
> 
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> Committee (PMC), to be known as the "Apache Zeppelin Project",
> be and hereby is established pursuant to Bylaws of the
> Foundation; and be it further
> 
> RESOLVED, that the Apache Zeppelin Project be and hereby is
> responsible for the creation and maintenance of software
> related to a collaborative data analytics and
> visualization tool for general-purpose data processing systems; and be it
> further
> 
> RESOLVED, that the office of "Vice President, Apache Zeppelin" 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 Zeppelin Project, and to have primary responsibility
> for management of the projects within the scope of
> responsibility of the Apache Zeppelin 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 Zeppelin Project:
> 
> * Alexander Bezzubov 
> * Anthony Corbacho 
> * Damien Corneau 
> * Felix Cheung 
> * Jongyoul Lee 
> * Kevin Sangwoo Kim 
> * Lee Moon Soo 
> * Mina Lee 
> * Prabhjyot Singh 
> 
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Lee Moon Soo
> be appointed to the office of Vice President, Apache Zeppelin, 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 initial Apache Zeppelin PMC be and hereby is
> tasked with the creation of a set of bylaws intended to
> encourage open development and increased participation in the
> Apache Zeppelin Project; and be it further
> 
> RESOLVED, that the Apache Zeppelin Project be and hereby
> is tasked with the migration and rationalization of the Apache
> Incubator Zeppelin podling; and be it further
> 
> RESOLVED, that all responsibilities pertaining to the Apache
> Incubator Zeppelin podling encumbered upon the Apache Incubator
> Project are hereafter discharge.


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

Re: [VOTE] Accept Fluo into the Apache Incubator

[Hitesh Shah]

+1 (binding)

— HItesh

> On May 13, 2016, at 11:22 AM, Billie Rinaldi  wrote:
> 
> Since discussion has died down, I would like to call a VOTE on accepting
> Fluo into the Apache Incubator.
> 
> Proposal: http://wiki.apache.org/incubator/FluoProposal
> 
> [ ] +1 Accept Fluo into the Apache Incubator
> [ ] +0 Abstain.
> [ ] -1 Do not accept Fluo into the Apache Incubator because…
> 
> This vote will be open for at least 72 hours.
> 
> Here is my +1 (binding).
> 
> Billie
> --
> 
> Fluo Proposal
> 
> Abstract
> 
> Fluo is a distributed system for incrementally processing large data sets
> stored in Accumulo.
> 
> Proposal
> 
> Fluo is a distributed transaction and notification system that enables the
> incremental processing of large data sets. Its transaction system allows
> for concurrent, cross-node updates to data stored in Accumulo. Its
> notification system enables developers to write code to be executed when
> observed data changes. Fluo provides a core API to perform transactional
> updates using minimalistic get/set methods. Fluo also provides a higher
> order recipes API that builds on the core API to support more complex
> methods for transactional updates.
> 
> Background
> 
> Several frameworks exist for batch (i.e Spark, MapReduce) and stream (i.e
> Storm, Spark Streaming) processing of data. While batch and stream
> processing have strong use cases, they are not suited for joining incoming
> data in real-time to a large existing data set. To fill this need, Google
> developed an incremental processing system called Percolator and described
> it in the paper, Large-scale Incremental Processing Using Distributed
> Transactions and Notifications1.
> 
> Rationale
> 
> Fluo fills the need for cross-row (and cross-node) transactions in Accumulo
> by providing it with an open source implementation of Percolator. Fluo also
> satisfies a gap in Accumulo’s ability to incrementally process data. Fluo
> also provides a novel recipes API which offers higher level abstractions
> for transactional updates.
> 
> Current Status
> 
> Fluo currently exists as an open source project on GitHub and has been in
> active development since 2013. The project has made an alpha release and
> two beta releases. The major features of Fluo outlined in this proposal
> have been implemented. Several example Fluo applications have been created
> and run successfully on clusters (up to 24 nodes).
> 
> Meritocracy
> 
> The Fluo project operates as a meritocracy and will continue to do so
> because we feel that a project comprised of a diverse set of committers
> will thrive. Therefore, we welcome new contributors and encourage them on
> their path to committership.
> 
> Community
> 
> Fluo is currently being used by a subset of the Accumulo community. The
> initial developers have been responsive to external contributions through
> pull requests and issues on GitHub. As Fluo releases a stable 1.0 version
> that is production-ready, we expect this community to grow. To encourage
> growth, we have created a project website with documentation, given talks
> at Meetups and the Accumulo Summit, and engaged with new users on GitHub
> and the Fluo mailing list.
> 
> Core Developers
> 
> The project was started by Keith Turner (an Apache Member and committer/PMC
> on Gora and Accumulo) in 2013, and the development has primarily consisted
> of his and Mike Walch’s continued efforts. Additional developers have
> contributed over time, which has led to new committers.
> 
> Alignment
> 
> Fluo is closely linked to the Accumulo community, and fits well within the
> larger Hadoop ecosystem at Apache. Fluo utilizes several Apache projects,
> such as Accumulo, YARN, Twill, and ZooKeeper. Enabling closer collaboration
> between these communities through its coexistence within the ASF would help
> further drive the success of them all.
> 
> In addition to our technical ties to other ASF projects, our development
> philosophy aligns with Apache philosophies. Based on our experience with
> existing Apache projects, we are interested in establishing formal
> governance with a PMC and community bylaws, which we feel would best be
> done within Apache.
> 
> Known Risks
> 
> Orphaned Products
> 
> Fluo could be orphaned if the project fails to gain adoption and the core
> developers abandon their interest (this is not anticipated). This risk can
> be mitigated by attracting more committers and developing further
> documentation to ease adoption.
> 
> Inexperience with Open Source
> 
> Fluo has been an open source project on GitHub from the start of its
> development. Several Fluo developers are committers on other ASF projects
> as well as open source projects outside ASF, and understand open source
> development.
> 
> Homogeneous Developers
> 
> The initial committers work for different employers. We hope add more
> developers from other employers and industries.
> 
> Reliance on Salaried Developers
> 
> While most of the initial committers are p

Re: [VOTE] Accept PredictionIO into the Apache Incubator

[Hitesh Shah]

+1 (binding)

— Hitesh

> On May 23, 2016, at 3:22 PM, Andrew Purtell  wrote:
> 
> Since discussion on the matter of PredictionIO has died down, I would like
> to call a VOTE
> on accepting PredictionIO into the Apache Incubator.
> 
> Proposal: https://wiki.apache.org/incubator/PredictionIO
> 
> ​[ ] +1 Accept PredictionIO into the Apache Incubator
> [ ] +0 Abstain
> [ ] -1 Do not accept PredictionIO into the Apache Incubator, because ...
> 
> This vote will be open for at least 72 hours.
> 
> My vote is +1 (binding)
> 
> --
> 
> PredictionIO Proposal
> 
> Abstract
> 
> PredictionIO is an open source Machine Learning Server built on top of
> state-of-the-art open source stack, that enables developers to manage and
> deploy production-ready predictive services for various kinds of machine
> learning tasks.
> 
> Proposal
> 
> The PredictionIO platform consists of the following components:
> 
>   * PredictionIO framework - provides the machine learning stack for
> building, evaluating and deploying engines with machine learning
> algorithms. It uses Apache Spark for processing.
> 
>   * Event Server - the machine learning analytics layer for unifying events
> from multiple platforms. It can use Apache HBase or any JDBC backends
> as its data store.
> 
> The PredictionIO community also maintains a Template Gallery, a place to
> publish and download (free or proprietary) engine templates for different
> types of machine learning applications, and is a complemental part of the
> project. At this point we exclude the Template Gallery from the proposal,
> as it has a separate set of contributors and we’re not familiar with an
> Apache approved mechanism to maintain such a gallery.
> 
> Background
> 
> PredictionIO was started with a mission to democratize and bring machine
> learning to the masses.
> 
> Machine learning has traditionally been a luxury for big companies like
> Google, Facebook, and Netflix. There are ML libraries and tools lying
> around the internet but the effort of putting them all together as a
> production-ready infrastructure is a very resource-intensive task that is
> remotely reachable by individuals or small businesses.
> 
> PredictionIO is a production-ready, full stack machine learning system that
> allows organizations of any scale to quickly deploy machine learning
> capabilities. It comes with official and community-contributed machine
> learning engine templates that are easy to customize.
> 
> Rationale
> 
> As usage and number of contributors to PredictionIO has grown bigger and
> more diverse, we have sought for an independent framework for the project
> to keep thriving. We believe the Apache foundation is 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 PredictionIO. PredictionIO is also a good fit for the Apache foundation.
> PredictionIO was built on top of several Apache projects (HBase, Spark,
> Hadoop). We are familiar with the Apache process and believe that the
> democratic and meritocratic nature of the foundation aligns with the
> project goals.
> 
> Initial Goals
> 
> The initial milestones 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, as well as growing our developer and user communities.
> 
> Current Status
> 
> PredictionIO has undergone nine minor releases and many patches.
> PredictionIO is being used in production by Salesforce.com as well as many
> other organizations and apps. The PredictionIO codebase is currently
> hosted at GitHub, which will form the basis of the Apache git repository.
> 
> Meritocracy
> 
> We plan to invest in supporting a meritocracy. We will discuss the
> requirements in an open forum. We intend to invite additional developers
> to participate. We will encourage and monitor community participation so
> that privileges can be extended to those that contribute.
> 
> Community
> 
> Acceptance into the Apache foundation would bolster the already strong
> user and developer community around PredictionIO. That community includes
> many contributors from various other companies, and an active mailing list
> composed of hundreds of users.
> 
> Core Developers
> 
> The core developers of our project are listed in our contributors and
> initial PPMC below. Though many are employed at Salesforce.com, there are
> also engineers from ActionML, and independent developers.
> 
> Alignment
> 
> The ASF is the natural choice to host the PredictionIO project as its goal
> is democratizing Machine Learning by making it more easily accessible to
> every user/developer. PredictionIO is built on top of several top level
> Apache projects as outlined above.
> 
> Known Risks
> 
> Orphaned Products
> 
> PredictionIO has a solid and growing community. It is 

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

[Hitesh Shah]

+1 (binding).

Verified sigs/checksums.
DISCLAIMER files in all 3 bundles.
Source tarball is clean.
License and Notice file look fine though I agree with Josh's comment on the
copyright statements within the License file. Shedding more light on the
source of the copyrights would be good.
I have seen cases where the full license text is kept in a separate file so
as long as there is a direct pointer to the text from the main License
file, I think it should be okay.

Apologies on the delay in getting to review this release.

thanks
-- Hitesh





On Tue, Feb 21, 2017 at 12:13 PM, Chip Senkbeil 
wrote:

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

Re: Airflow voting on release artifacts

[Hitesh Shah]

Hi folks,

Given that the source bits are the official release, would it be okay if
the community as a whole decided on say the following approach:

1) Bundle source with version set to 1.8.1
2) Bundle binary convenience artifacts built using version set to 1.8.1rc1
3) Publish source and binary bits to dist.a.o/dev for vote
4) If vote passes, publish the source tarball that was voted upon and
"modified" binary convenience artifacts built with version set to 1.8.1

The implication here is that the release manager is being trusted by the
PMC to release the modified convenience artifacts from the voted-upon
source without a new vote.

If it helps, there are a couple of variations of the above which could be
applied to reduce the no. of total votes:

2a) Create 2 binary sets for the vote - one with version 1.8.1rc1 and other
with version 1.8.1 ( with only 1.8.1 being published on a successful vote)

OR

4a) After PPMC vote passes, use the original source and modified binaries
for the IPMC vote and therefore the IPMC vote is on the final bits being
published.

Any comments?

thanks
-- Hitesh


On Tue, Apr 25, 2017 at 9:02 PM, Alex Harui  wrote:

>
>
> >
> >3. There is no “separate” build script. Pip will just install a binary
> >(“wheel”) or uses the source package (as shown above). Both are used
> >interchangeable by users. We only distribute source packages at the
> >moment.
> >
> >@Alex: I have to think a little bit more about what you wrote, but it is
> >currently confusing the hell out of me :). Furthermore, I am not sure if
> >it applies considering the above #3.
>
> It could still apply.  You would just have to add a build script that
> renames the package and metadata.
>
> Let's say I wanted to release a single file that reported the version
> number.  Forgive me that I don't know Python so I just grabbed what I
> think it would look like from the internet.
>
> ---MyRelease.py---
> print("I am version 1.2.3.")
>
> Let's assume this is what your "customers" want to use.
>
> I am proposing that the Apache Source Package also contain the following
> file:
>
> ---BuildScript.sh---
> # creates Customer Package in out folder.
> mkdir out
> sed s/1.2.3/1.2.3$1/ < MyRelease.py > out/MyRelease$1.py
>
> Voters would run:
>
>BuildScript.sh RC1
>
> That would result in:
>
> ---out/MyReleaseRC1.py---
> print("I am version 1.2.3RC1.")
>
> And this version would be tested by the voters.  The source package being
> voted on contains the original MyRelease.py and BuildScript.sh.  The
> release manager would also run:
>
>
> BuildScript.sh
>
> That would result in:
>
> ---out/MyRelease.py---
> print("I am version 1.2.3.")
>
> In our project, the RM posts the source package in the RC folder and
> creates a folder called "binaries" for the compiled source.  You could
> call the folder something else, but let's keep the names for now.  The RM
> would copy a zip of MyRelease.py and BuildScript.sh (and LICENSE, NOTICE,
> README) into the RC folder and out/MyRelease.py to the "binaries" folder.
> Along with signatures and checksum files.
>
>
> Voters would download the zip, expand it, run "BuildScript.sh RC1" and
> test with their out/MyReleaseRC1.py.  They would examine the zip to make
> sure it is compliant with Apache release policy.  This is what all other
> voters on all other projects generally do.  But they would perform one
> different step, which is, instead of testing the MyRelease.py in the
> "binaries" folder, they would simply diff their MyReleaseRC1.py against
> the MyRelease.py in the "binaries" folder.  If the only diffs are the
> version, they should feel satisfied that the resulting "customer" packages
> is ok for release.
>
> Of course, I could be wrong...
>
> HTH,
> -Alex
>
>

Re: Airflow voting on release artifacts

[Hitesh Shah]

Hi Justin,

Currently, the podling has been modifying the contents and hence this
discussion.

thanks
-- Hitesh

On Thu, Apr 27, 2017 at 8:48 PM, Justin Mclean 
wrote:

> Hi,
>
> > The implication here is that the release manager is being trusted by the
> > PMC to release the modified convenience artifacts from the voted-upon
> > source without a new vote.
>
> How are the artefacts modified after the vote?
>
> IMO As long as the hashes and signature are the same there is no issue. If
> any of the contents change, rather than just files names, then it would no
> longer be a valid release.
>
> If it is just a rename, a safer way to rename the file this would be to do
> so when you do the svn move from dev staging area to the release area.
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Livy to enter Apache Incubator

[Hitesh Shah]

+1

-- Hitesh

On Wed, May 31, 2017 at 6:03 AM, Sean Busbey  wrote:

> Hi folks!
>
> I'm calling a vote to accept "Livy" into the Apache Incubator.
>
> The full proposal is available below, and is also available in the wiki:
>
> https://wiki.apache.org/incubator/LivyProposal
>
> For additional context, please see the discussion thread:
>
> https://s.apache.org/incubator-livy-proposal-thread
>
> Please cast your vote:
>
> [ ] +1, bring Livy into Incubator
> [ ] -1, do not bring Livy into Incubator, because...
>
> The vote will open at least for 72 hours and only votes from the Incubator
> PMC are binding.
>
> I start with my vote:
> +1
>
> 
>
> = Abstract =
>
> Livy is web service that exposes a REST interface for managing long running
> Apache Spark contexts in your cluster. With Livy, new applications can be
> built on top of Apache Spark that require fine grained interaction with
> many
> Spark contexts.
>
> = Proposal =
>
> Livy is an open-source REST service for Apache Spark. Livy enables
> applications to submit Spark applications and retrieve results without a
> co-location requirement on the Spark cluster.
>
> We propose to contribute the Livy codebase and associated artifacts (e.g.
> documentation, web-site context etc) to the Apache Software Foundation.
>
> = Background =
>
> Apache Spark is a fast and general purpose distributed compute engine, with
> a versatile API. It enables processing of large quantities of static data
> distributed over a cluster of machines, as well as processing of continuous
> streams of data. It is the preferred distributed data processing engine for
> data engineering, stream processing and data science workloads. Each Spark
> application uses a construct called the SparkContext, which is the
> application’s connection or entry point to the Spark engine. Each Spark
> application will have its own SparkContext.
>
> Livy enables clients to interact with one or more Spark sessions through
> the
> Livy Server, which acts as a proxy layer. Livy Clients have fine grained
> control over the lifecycle of the Spark sessions, as well as the ability to
> submit jobs and retrieve results, all over HTTP. Clients have two modes of
> interaction: RPC Client API, available in Java and Python, which allows
> results to be retrieved as Java or Python objects. The serialization and
> deserialization of the results is handled by the Livy framework. HTTP based
> API that allows submission of code snippets, and retrieval of the results
> in
> different formats.
>
> Multi-tenant resource allocation and security: Livy enables multiple
> independent Spark sessions to be managed simultaneously. Multiple clients
> can also interact simultaneously with the same Spark session and share the
> resources of that Spark session. Livy can also enforce secure,
> authenticated
> communication between the clients and their respective Spark sessions.
>
> More information on Livy can be found at the existing open source website:
> http://livy.io/
>
> = Rationale =
>
> Users want to use Spark’s powerful processing engine and API as the data
> processing backend for interactive applications. However, the job
> submission
> and application interaction mechanisms built into Apache Spark are
> insufficient and cumbersome for multi-user interactive applications.
>
> The primary mechanism for applications to submit Spark jobs is via
> spark-submit
> (http://spark.apache.org/docs/latest/submitting-applications.html), which
> is
> available as a command line tool as well as a programmatic API. However,
> spark-submit has the following limitations that make it difficult to build
> interactive applications: It is slow: each invocation of spark-submit
> involves a setup phase where cluster resources are acquired, new processes
> are forked, etc. This setup phase runs for many seconds, or even minutes,
> and hence is too slow for interactive applications. It is cumbersome and
> lacks flexibility: application code and dependencies have to be
> pre-compiled
> and submitted as jars, and can not be submitted interactively.
>
> Apache Spark comes with an ODBC/JDBC server, which can be used to submit
> SQL
> queries to Spark. However, this solution is limited to SQL and does not
> allow the client to leverage the rest of the Spark API, such as RDDs, MLlib
> and Streaming.
>
> A third way of using Spark is via its command-line shell, which allows the
> interactive submission of snippets of Spark code. However, the shell
> entails
> running Spark code on the client machine and hence is not a viable
> mechanism
> for remote clients to submit Spark jobs.
>
> Livy solves the limitations of the above three mechanisms, and provides the
> full Spark API as a multi-tenant service to remote clients.
>
> Since the open source release of Livy in late 2015, we have seen tremendous
> interest among a diverse set of application developers and ISVs that want
> to
> build applications with Apache Spark. To make Livy a robust and flexible
>

Re: [DISCUSS] Storage-class memory ecosystem program

[Hitesh Shah]

Hello Gary,

Would it be better to create a mailing list for this workgroup (I am
guessing it is too early to be thinking about a new podling for this) where
any interested folks could subscribe to?

thanks
-- Hitesh


On Tue, Oct 24, 2017 at 10:14 AM, Gang(Gary) Wang  wrote:

> It is a great idea if we could have a common benchmark and APIs for
> storage-class memory oriented library/framework/application, please go
> ahead to propose one for discussion in our workgroup. Thanks!
>
> On Mon, Oct 23, 2017 at 4:27 PM, Debojyoti Dutta  wrote:
>
> > Would love to help out in any way including working towards common
> > benchmarks, APIs etc.
> >
> > Debo
> >
> > Sent from my iPhone
> >
> > > On Oct 23, 2017, at 4:06 PM, Gang(Gary) Wang  wrote:
> > >
> > > There are suggested initial goals for our workgroup
> > >
> > >   - Sharing idea and good practice
> > >   - Identifying common opportunities
> > >   - Promoting storage-class memory application
> > >   - Delivering solid solution
> > >   - Avoiding reinvent the wheel
> > >   - Integrating one another
> > >   - Coordinating the progress
> > >
> > >
> > >> On Mon, Oct 23, 2017 at 4:02 PM, Gang(Gary) Wang 
> > wrote:
> > >>
> > >> Add ORC
> > >>
> > >>   - *Ignite* represented by Denis Magda
> > >>   - *Arrow *represented by Wes McKinney
> > >>   - *Hbase *represented by Anoop John
> > >>   - *Crail* represented by *Patrick Stuedi*
> > >>   - *ORC *represented by* Owen O'Malley*
> > >>   - *Mnemonic *represented by* Gary*
> > >>
> > >> With above projects, we could cover Storage-class memory oriented
> > *Distributed
> > >> Database, KV Store, Columnar Structured Dataset, Distributed Data
> Store,
> > >> Columnar Storage, **Durable Object Model, Durable Computing Model* for
> > >> new generation high-performance applications, e.g. data querying,
> > >> processing, and analytics.
> > >>
> > >>
> > >> On Mon, Oct 23, 2017 at 1:21 PM, Owen O'Malley <
> owen.omal...@gmail.com>
> > >> wrote:
> > >>
> > >>> I can represent ORC within the group.
> > >>>
> > >>> .. Owen
> > >>>
> >  On Oct 19, 2017, at 11:55 AM, Gang(Gary) Wang 
> > wrote:
> > 
> >  Hi all,
> > 
> >  We can expect more and more projects will take the huge potential
> >  advantages of storage-class memory for data processing and analytics
> >  because silicon companies are able to produce high capacity
> > non-volatile
> >  memory on a large scale, this hardware technology will fundamentally
> > >>> change
> >  the way to construct high performance applications similar to what
> > >>> happened
> >  when replacing tape with disk technology since the 1980s. so if
> > >>> possible, I
> >  advocate establishing an Apache working group to enhance the
> > >>> collaboration
> >  and synergies mentioned by Patrick Stuedi for storage-class memory
> >  technology-oriented projects.
> > 
> >  Best.
> >  Gary.
> > >>>
> > >>>
> > >>
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: [VOTE] Graduate Samza from the Incubator

[Hitesh Shah]

+1 (non-binding)

— Hitesh 

On Dec 12, 2014, at 3:54 PM, Jakob Homan  wrote:

> Restarting vote having fixed resolution detail, dastardly AWOL paragraph 
> breaks
> and removed nod to increased diversity in introduction.
> 
> The Samza podling community has voted to graduate from the Incubator.
> 
> The vote passed with 17 +1s and no -1s or +/-0s.
> 
> Binding +1s x 10 : Jakob, Chinmay, Yan, Chris Riccomini, Sriram,
> Zhijie, Martin, Roman, Garry, Chris Douglas
> Non-binding +1s x 7: Claudio, TJ, Robert, Roger, Danny, Jon, Yi
> 
> Links to votes and discussions:
> http://s.apache.org/samzaGradResult
> http://s.apache.org/samzaGradDiscuss
> 
> Samza has been incubating for a bit more than a year.  In that time
> the community has:
> * Completed two Incubator-approved releases
> * Opened nearly 500 JIRAs
> * Added five new committers/PMC members.
> 
> This thread is to vote on the graduation resolution Samza has
> approved.  It will run for at least 96 hours (to Tuesday, 12/22 4pm
> PST, the extra day to accommodate the weekend and holiday schedule).
> 
> [ ] +1 Graduate Apache Samza from the Incubator.
> [ ] +0 Don't care.
> [ ] -1 Don't graduate Apache Samza from the Incubator because ...
> 
> Here's my binding vote: +1.
> 
> -Jakob
> 
> 
> 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 low-latency, distributed processing of streaming data.
> 
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee (PMC),
> to be known as the "Apache Samza Project", be and hereby is established
> pursuant to Bylaws of the Foundation; and be it further
> 
> RESOLVED, that the Apache Samza Project be and hereby is responsible for
> the creation and maintenance of software related to low-latency,
> distributed processing of streaming data; and be it further
> 
> RESOLVED, that the office of "Vice President, Apache Samza" 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 Samza Project, and to
> have primary responsibility for management of the projects within the scope
> of responsibility of the Apache Samza 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 Samza Project:
> 
> * Chinmay Soman 
> * Chris Riccomini 
> * Garry Turkington 
> * Jakob Homan 
> * Jay Kreps 
> * Martin Kleppman 
> * Sriram Subramanian 
> * Yan Fang 
> * Zhijie Shen 
> 
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Chris Riccomini be
> appointed to the office of Vice President, Apache Samza, 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 Samza Project be and hereby is tasked with
> the migration and rationalization of the Apache Incubator Samza
> podling; and be it further
> 
> RESOLVED, that all responsibilities pertaining to the Apache Incubator
> Samza 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
> 


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

Some questions regarding License/Notice file for a binary distribution ( convenience artifacts )

[Hitesh Shah]

Hi folks 

Could someone point to a project’s ( or multiple projects ) License/Notice 
files where the project bundles the following as part of its binary 
distribution: 

   - jetty-6.1.x-jar and jetty-utils-6.1.jar - jetty is Apache License v2 but 
has some bits in the Notice file ( 
http://svn.codehaus.org/jetty/jetty/branches/jetty-6.1/NOTICE.txt ) that I 
would like to understand whether I should call out in either the License and/or 
Notice files
   - jersey-client, jersey-core,jersey-* jars - these have a dual license - 
CDDL and GPLv2 with Classpath Exception. I did not see any wording that stated 
that the jar could be used under either license. Again, I am not sure whether 
just calling out these licenses in the distribution’s license file is 
sufficient. 

thanks
— Hitesh


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

Re: Some questions regarding License/Notice file for a binary distribution ( convenience artifacts )

[Hitesh Shah]

Thanks for the helpful pointers and a good starting point, Justin and 
Amareshwari. 

— Hitesh

On Apr 22, 2015, at 9:10 PM, Justin Mclean  wrote:

> Hi,
> 
>>  - jetty-6.1.x-jar and jetty-utils-6.1.jar - jetty is Apache License v2 but 
>> has some bits in the Notice file ( 
>> http://svn.codehaus.org/jetty/jetty/branches/jetty-6.1/NOTICE.txt ) that I 
>> would like to understand whether I should call out in either the License 
>> and/or Notice files
> 
> Just take the bits mentioned that are actually bundled into your release 
> artefact and add those to NOTICE. [1] You can, but there no need, to add to 
> LICENSE. [2] This probably mean looking inside the jars and seeing what 
> you’re bundlling. I would be concerned about "jboss integration module”(LGPL) 
> but I assume that is not being bundled.
> 
>>  - jersey-client, jersey-core,jersey-* jars - these have a dual license - 
>> CDDL and GPLv2 with Classpath Exception. I did not see any wording that 
>> stated that the jar could be used under either license.
> 
> Anything that is dual licensed you get to select the license, CDDL is a weak 
> copyleft license and should be treated as per [3]. IMO you would add this to 
> LICENSE including where to get the source. NOTICE should be kept as minimal 
> as possible.
> 
> Thanks,
> Justin
> 
> 1.http://www.apache.org/dev/licensing-howto.html#guiding-principle
> 2.http://www.apache.org/dev/licensing-howto.html#alv2-dep
> 3.http://www.apache.org/legal/resolved.html#category-b
> 
> 
> -
> 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] Release Airflow 1.10.0 (new vote based on rc4)

[Hitesh Shah]

+1 (binding)

Ran through the basic checks.

Minor nit which can be fixed in the next release: there are a bunch of
documentation files which could have a license header added (e.g. .md,
.rst, )

thanks
Hitesh

On Mon, Aug 20, 2018 at 4:08 AM Bolke de Bruin  wrote:

> Sorry Willem that should be of course. Apologies.
>
> Sent from my iPhone
>
> > On 20 Aug 2018, at 13:07, Bolke de Bruin  wrote:
> >
> > Hi William
> >
> > You seem to be missing a "4" at the end of the URL? Ah it seems that my
> original email had a quirk. Would you mind using the below?
> >
> > https://github.com/apache/incubator-airflow/releases/tag/1.10.0rc4
> >
> > Thanks!
> > Bolke
> >
> > Sent from my iPhone
> >
> >> On 20 Aug 2018, at 13:03, Willem Jiang  wrote:
> >>
> >> Hi,
> >>
> >> The Git tag cannot be accessed.  I can only get the 404  error there.
> >>
> >> https://github.com/apache/incubator-airflow/releases/tag/1.10.0rc
> >>
> >>
> >> Willem Jiang
> >>
> >> Twitter: willemjiang
> >> Weibo: 姜宁willem
> >>
> >>> On Sun, Aug 12, 2018 at 8:25 PM, Bolke de Bruin 
> wrote:
> >>>
> >>> Hello Incubator PMC’ers,
> >>>
> >>> The Apache Airflow community has voted and approved the proposal to
> release
> >>> Apache Airflow 1.10.0 (incubating) based on 1.10.0 Release Candidate
> 4. We
> >>> now kindly request the Incubator PMC members to review and vote on this
> >>> incubator release.
> >>>
> >>> Airflow is a platform to programmatically author, schedule, and monitor
> >>> workflows. Use Airflow to author workflows as directed acyclic graphs
> >>> (DAGs) of tasks. The airflow scheduler executes your tasks on an array
> of
> >>> workers while following the specified dependencies. Rich command line
> >>> utilities make performing complex surgeries on DAGs a snap. The rich
> user
> >>> interface makes it easy to visualize pipelines running in production,
> >>> monitor progress, and troubleshoot issues when needed. When workflows
> are
> >>> defined as code, they become more maintainable, versionable, testable,
> and
> >>> collaborative.
> >>>
> >>> After a successful IPMC vote Artifacts will be available at:
> >>>
> >>> https://www.apache.org/dyn/closer.cgi/incubator/airflow <
> >>> https://www.apache.org/dyn/closer.cgi/incubator/airflow>
> >>>
> >>> Public keys are available at:
> >>>
> >>> https://www.apache.org/dist/incubator/airflow/ <
> >>> https://www.apache.org/dist/incubator/airflow/>
> >>>
> >>> apache-airflow-1.10.0rc4+incubating-source.tar.gz
> >>>
> >>> https://dist.apache.org/repos/dist/dev/incubator/airflow/1.
> >>> 10.0rc4/apache-airflow-1.10.0rc4+incubating-source.tar.gz <
> >>>
> https://dist.apache.org/repos/dist/dev/incubator/airflow/1.10.0rc4/apache-
> >>> airflow-1.10.0rc4+incubating-source.tar.gz>
> >>>
> >>> is a source release that comes with INSTALL instructions. Along with
> it,
> >>> for
> >>> convenience, find the binary Python "sdist" as
> >>> apache-airflow-1.10.0rc4+incubating-bin.tar.gz *
> >>>
> >>> https://dist.apache.org/repos/dist/dev/incubator/airflow/1.
> >>> 10.0rc4/apache-airflow-1.10.0rc4+incubating-bin.tar.gz <
> >>>
> https://dist.apache.org/repos/dist/dev/incubator/airflow/1.10.0rc4/apache-
> >>> airflow-1.10.0rc4+incubating-bin.tar.gz>
> >>>
> >>> Vote thread:
> >>> https://mail-archives.apache.org/mod_mbox/airflow-dev/
> >>> 201807.mbox/%3c4ab16d90-7184-4c05-a125-fbc5c5af7...@gmail.com%3E <
> >>> https://mail-archives.apache.org/mod_mbox/airflow-dev/
> >>> 201807.mbox/%3c4ab16d90-7184-4c05-a125-fbc5c5af7...@gmail.com%3E>
> >>>
> >>> Git tag:
> >>> https://github.com/apache/incubator-airflow/releases/tag/1.10.0rc <
> >>> https://github.com/apache/incubator-airflow/releases/tag/1.10.0rc>4
> >>>
> >>> The vote will be open for at least 72 hours and until the necessary
> number
> >>> of
> >>> votes are reached.
> >>>
> >>> Members please be sure to indicate "(Binding)" with your vote which
> will
> >>> help in tallying the vote(s).
> >>>
> >>> * Here is my +1 (non-binding) *
> >>>
> >>> Cheers,
> >>> Bolke
> >>>
> >>> * WARNING: Due to licensing requirements you will need to set
> >>> SLUGIFY_USES_TEXT_UNIDECODE=yes in your environment when
> >>> installing or upgrading. We will try to remove this requirement for the
> >>> next release.
> >>>
>

Re: [VOTE] Release Airflow 1.10.0 (new vote based on rc4)

[Hitesh Shah]

Hi Bolke

The general approach I have used in the past is to find the correct
"comment" syntax to allow addition of the license text such that it does
not break the language parser. For markdown, that would mean just using an
html comment.

thanks
Hitesh





On Mon, Aug 20, 2018 at 10:56 AM Bolke de Bruin  wrote:

> Appreciated Hitesh. Do you know how to add headers to .MD files? There
> seems to be no technical standard way[1]. Is there a way to solve this
> elegantly?
>
> Cheers
> Bolke
>
> [1]
> https://alvinalexander.com/technology/markdown-comments-syntax-not-in-generated-output
>
>
>
> Sent from my iPhone
>
> > On 20 Aug 2018, at 19:48, Hitesh Shah  wrote:
> >
> > +1 (binding)
> >
> > Ran through the basic checks.
> >
> > Minor nit which can be fixed in the next release: there are a bunch of
> > documentation files which could have a license header added (e.g. .md,
> > .rst, )
> >
> > thanks
> > Hitesh
> >
> >> On Mon, Aug 20, 2018 at 4:08 AM Bolke de Bruin 
> wrote:
> >>
> >> Sorry Willem that should be of course. Apologies.
> >>
> >> Sent from my iPhone
> >>
> >>> On 20 Aug 2018, at 13:07, Bolke de Bruin  wrote:
> >>>
> >>> Hi William
> >>>
> >>> You seem to be missing a "4" at the end of the URL? Ah it seems that my
> >> original email had a quirk. Would you mind using the below?
> >>>
> >>> https://github.com/apache/incubator-airflow/releases/tag/1.10.0rc4
> >>>
> >>> Thanks!
> >>> Bolke
> >>>
> >>> Sent from my iPhone
> >>>
> >>>> On 20 Aug 2018, at 13:03, Willem Jiang 
> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> The Git tag cannot be accessed.  I can only get the 404  error there.
> >>>>
> >>>> https://github.com/apache/incubator-airflow/releases/tag/1.10.0rc
> >>>>
> >>>>
> >>>> Willem Jiang
> >>>>
> >>>> Twitter: willemjiang
> >>>> Weibo: 姜宁willem
> >>>>
> >>>>> On Sun, Aug 12, 2018 at 8:25 PM, Bolke de Bruin 
> >> wrote:
> >>>>>
> >>>>> Hello Incubator PMC’ers,
> >>>>>
> >>>>> The Apache Airflow community has voted and approved the proposal to
> >> release
> >>>>> Apache Airflow 1.10.0 (incubating) based on 1.10.0 Release Candidate
> >> 4. We
> >>>>> now kindly request the Incubator PMC members to review and vote on
> this
> >>>>> incubator release.
> >>>>>
> >>>>> Airflow is a platform to programmatically author, schedule, and
> monitor
> >>>>> workflows. Use Airflow to author workflows as directed acyclic graphs
> >>>>> (DAGs) of tasks. The airflow scheduler executes your tasks on an
> array
> >> of
> >>>>> workers while following the specified dependencies. Rich command line
> >>>>> utilities make performing complex surgeries on DAGs a snap. The rich
> >> user
> >>>>> interface makes it easy to visualize pipelines running in production,
> >>>>> monitor progress, and troubleshoot issues when needed. When workflows
> >> are
> >>>>> defined as code, they become more maintainable, versionable,
> testable,
> >> and
> >>>>> collaborative.
> >>>>>
> >>>>> After a successful IPMC vote Artifacts will be available at:
> >>>>>
> >>>>> https://www.apache.org/dyn/closer.cgi/incubator/airflow <
> >>>>> https://www.apache.org/dyn/closer.cgi/incubator/airflow>
> >>>>>
> >>>>> Public keys are available at:
> >>>>>
> >>>>> https://www.apache.org/dist/incubator/airflow/ <
> >>>>> https://www.apache.org/dist/incubator/airflow/>
> >>>>>
> >>>>> apache-airflow-1.10.0rc4+incubating-source.tar.gz
> >>>>>
> >>>>> https://dist.apache.org/repos/dist/dev/incubator/airflow/1.
> >>>>> 10.0rc4/apache-airflow-1.10.0rc4+incubating-source.tar.gz <
> >>>>>
> >>
> https://dist.apache.org/repos/dist/dev/incubator/airflow/1.10.0rc4/apache-
> >>>>> airflow-1.10.0rc4+incubating-source.tar.gz>
> >>>>>
> >>>>>

Re: [VOTE] Release Airflow 1.10.1 (incubating)

[Hitesh Shah]

+1 (binding)

Looked at the source tar ball:
  - DISCLAIMER looks good
  - rat-check was clean
  - License and NOTICE files look good.
  - Signatures and checksums verified

thanks
Hitesh




On Mon, Nov 19, 2018 at 3:45 AM Ash Berlin-Taylor  wrote:

> Done, (and updated our project scripts to not create them anymore.)
>
> Thanks,
> Ash
>
> > On 19 Nov 2018, at 07:32, Henk P. Penning  wrote:
> >
> > On Sun, 18 Nov 2018, Ash Berlin-Taylor wrote:
> >
> >> Date: Sun, 18 Nov 2018 22:06:42 +0100
> >> From: Ash Berlin-Taylor 
> >> To: general@incubator.apache.org
> >> Subject: [VOTE] Release Airflow 1.10.1 (incubating)
> >> Hello Incubator PMC’ers,
> >>
> >> The Apache Airflow community has voted and approved the proposal to
> release
> >> Apache Airflow 1.10.1 (incubating) based on 1.10.1 Release Candidate 2.
> We
> >> now kindly request the Incubator PMC members to review and vote on this
> >> incubator release.
> >
> >> https://dist.apache.org/repos/dist/dev/incubator/airflow
> >
> >  .md5 checksum files should not be published ; please remove.
> >  The vote may continue.
> >
> >  Regards,
> >
> >  HPP
> >
> >    _
> > Henk P. Penning, ICT-beta R Uithof MG-403_/ \_
> > Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
> > Leuvenlaan 4, 3584CE Utrecht, NL  F +31 30 253 4553 \_/ \_/
> > http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/
> >
> > -
> > 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] Graduate Apache Airflow to TLP

[Hitesh Shah]

+1 (binding)

-- Hitesh

On Wed, Dec 5, 2018 at 7:28 PM Dave Fisher  wrote:

> +1 (binding)
>
> Regards,
> Dave
>
> Sent from my iPhone
>
> > On Dec 5, 2018, at 7:07 PM, Bolke de Bruin  wrote:
> >
> > Hi Dave,
> >
> > Yes it is optional. Please See installation instructions.
> >
> > Bolke
> >
> >
> > Op do 6 dec. 2018 00:59 schreef Dave Fisher  >
> >> Hi -
> >>
> >> Please explain the status of the GPL’d code mentioned here -
> >> https://issues.apache.org/jira/browse/AIRFLOW-3400
> >>
> >> Is it an optional dependency?
> >>
> >> Regards,
> >> Dave
> >>
> >>> On Dec 5, 2018, at 3:31 PM, Jakob Homan  wrote:
> >>>
> >>> Hello-
> >>>
> >>> The Airflow podling community has VOTEd[0] to graduate, following a
> >>> very successful DISCUSS[1].  Accordingly I'm bringing the resolution
> >>> up for an IPMC VOTE.
> >>>
> >>> The podling result was:
> >>> Overall: 21 x +1 votes, 0 x -1 votes
> >>>
> >>> Binding +1 x 11: Kaxil, Tao, Bolke, Fokko, Maxime, Arthur, Hitesh,
> >>> Chris, Sid, Ash, Jakob.
> >>> Non-binding +1 x 10: Daniel, Shah, Stefan, Kevin, Marc, Sunil,
> >>> Adityan, Deng, Neelesh, Sai
> >>>
> >>> Since entering the Incubator in 2016, the Airflow community has:
> >>>  * successfully produced 7 releases
> >>>  * added 9 new committers/PPMC members
> >>>  * built a diverse group of committers from multiple different
> employers
> >>>  * had more than 3,300 JIRA tickets opened
> >>>  * completed the project maturity model with positive responses[2]
> >>>
> >>> Here's my binding +1.  The VOTE will run for at least 72 hours.
> >>>
> >>> Thanks,
> >>> Jakob
> >>>
> >>> [0]
> >>
> https://mail-archives.apache.org/mod_mbox/airflow-dev/201812.mbox/%3c115b1380-619d-41d7-a30e-9c041cd4d...@gmail.com%3E
> >>> [1]
> >>
> https://lists.apache.org/thread.html/%3c0a763b0b-7d0d-4353-979a-ac6769eb0...@gmail.com%3E
> >>> [2]
> >> https://cwiki.apache.org/confluence/display/AIRFLOW/Maturity+Evaluation
> >>>
> >>> 
> >>>
> >>> Establish the Apache Airflow 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 workflow automation and scheduling
> >>> that can be used to author and manage data pipelines.
> >>>
> >>> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> >>> Committee (PMC), to be known as the "Apache Airflow Project",
> >>> be and hereby is established pursuant to Bylaws of the
> >>> Foundation; and be it further
> >>>
> >>> RESOLVED, that the Apache Airflow Project be and hereby is
> >>> responsible for the creation and maintenance of software
> >>> related to workflow automation and scheduling that can be
> >>> used to author and manage data pipelines; and be it further
> >>>
> >>> RESOLVED, that the office of "Vice President, Apache Airflow" 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 Airflow Project, and to have primary responsibility
> >>> for management of the projects within the scope of
> >>> responsibility of the Apache Airflow 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 Airflow Project:
> >>>
> >>> * Alex Guziel 
> >>> * Alex Van Boxel 
> >>> * Arthur Wiedmer 
> >>> * Ash Berlin-Taylor 
> >>> * Bolke de Bruin 
> >>> * Chris Riccomini 
> >>> * Dan Davydov 
> >>> * Fokko Driesprong 
> >>> * Hitesh Shah 
> >>> * Jakob Homan 
> >>> * Jeremiah Lowi

Re: Does a new podling committer require notice to the IPMC?

[Hitesh Shah]

The notice is only for new PPMC members. Most podlings do not differentiate
between committers and PPMC so you would end up seeing notice emails for
new committers being sent to the IPMC.

https://incubator.apache.org/guides/ppmc.html#voting_in_a_new_ppmc_member

Hitesh


On Thu, Dec 20, 2018 at 3:13 PM Alan Gates  wrote:

> We used to require that a podling notify the IPMC after its PPMC had voted
> to invite a contributor to be a committer and before the candidate was
> notified.  Do we still require that? I can't recall seeing any emails from
> other podlings on that lately and I couldn't find any docs on the incubator
> site one way or another.
>
> Alan.
>

Re: [VOTE] Accept XTable into the ASF Incubator

[Hitesh Shah]

+1 (binding)

— Hitesh

On Fri, Dec 15, 2023 at 20:17 Jesus Camacho Rodriguez 
wrote:

> Hi All,
>
> Following the discussion in the incubator mailing list [1], I am starting
> this official vote for the XTable project.
>
> Here is the proposal -
> https://cwiki.apache.org/confluence/display/INCUBATOR/XTable+Proposal
>
> Please cast your vote:
>
> [ ] +1, bring XTable into the Incubator
> [ ] +0, I don't care either way
> [ ] -1, do not bring XTable into the Incubator, because...
>
> This majority vote is open for at least 96 hours (due to the weekend).
>
> Only votes from Incubator PMC members are binding, but other votes are
> welcome!
>
> Thanks,
> Jesús
>
> [1] https://lists.apache.org/thread/rx9z8ffrf37qjhpkf1vp5rqg5lhht7jm
>

Re: [VOTE] Accept YuniKorn into Apache Incubator

[Hitesh Shah]

+1 (binding)

-- Hitesh

On Sun, Jan 12, 2020 at 9:57 PM Rakesh Radhakrishnan 
wrote:

> +1 (non-binding).
>
> Regards,
> Rakesh
>
> On Fri, Jan 10, 2020 at 11:17 PM Vinod Kumar Vavilapalli <
> vino...@apache.org>
> wrote:
>
> > Hi,
> >
> > I'd like to call a vote on accepting YuniKorn into the Apache Incubator.
> >
> > Please see the discussion thread [1].
> >
> > Please see the full proposal:
> > https://cwiki.apache.org/confluence/display/INCUBATOR/YuniKornProposal
> >
> > Please cast your vote
> >
> > [ ] +1 Accept YuniKorn into the Incubator
> > [ ] +0 Indifferent to the acceptance of YuniKorn
> > [ ] -1 Do not accept YuniKorn because …
> >
> > The vote will be open at least for 72 hours.
> >
> > Incubator PMC member votes are binding. Everyone else is welcomed to vote
> > too (mark them as non-binding if you can)!
> >
> > Thanks
> > +Vinod
> >
> > [1] [DISCUSS] YuniKorn Proposal
> >
> https://lists.apache.org/thread.html/59a3fc019119352f06e75a2bae5c25cd1b652282d7a59b85ed2188cf%40%3Cgeneral.incubator.apache.org%3E
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: [VOTE] Recommend Apache Iceberg graduation to top-level project resolution to the board

[Hitesh Shah]

+1 (binding)

-- Hitesh

On Fri, May 15, 2020 at 5:40 PM Ryan Blue  wrote:

> Hi everyone,
>
> With the support of our mentors (as well as helpful ASF members), the
> Apache Iceberg community has voted to graduate to a top-level project.
>
> I propose a vote to recommend graduation for the Iceberg community to the
> board. Here is the proposed resolution:
>
> ```
> Establish the Apache Iceberg 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 managing huge analytic datasets using a standard at-rest
> table format that is designed for high performance and ease of use..
>
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> (PMC), to be known as the "Apache Iceberg Project", be and hereby is
> established pursuant to Bylaws of the Foundation; and be it further
>
> RESOLVED, that the Apache Iceberg Project be and hereby is responsible
> for the creation and maintenance of software related to managing huge
> analytic datasets using a standard at-rest table format that is designed
> for high performance and ease of use; and be it further
>
> RESOLVED, that the office of "Vice President, Apache Iceberg" 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 Iceberg
> Project, and to have primary responsibility for management of the
> projects within the scope of responsibility of the Apache Iceberg
> 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 Iceberg Project:
>
>  * Anton Okolnychyi 
>  * Carl Steinbach   
>  * Daniel C. Weeks  
>  * James R. Taylor  
>  * Julien Le Dem
>  * Owen O'Malley
>  * Parth Brahmbhatt 
>  * Ratandeep Ratti  
>  * Ryan Blue
>
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ryan Blue be appointed to
> the office of Vice President, Apache Iceberg, 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 Iceberg Project be and hereby is tasked with
> the migration and rationalization of the Apache Incubator Iceberg
> podling; and be it further
>
> RESOLVED, that all responsibilities pertaining to the Apache Incubator
> Iceberg podling encumbered upon the Apache Incubator PMC are hereafter
> discharged.
> ```
>
> The community vote passed with 19 +1 votes:
>
> https://lists.apache.org/thread.html/r9081df0181768f26490f5a85aed7b5a111a82a741764eb3a0e99621d%40%3Cdev.iceberg.apache.org%3E
>
> We also addressed concerns on the IPMC thread, which you can read here:
>
> https://lists.apache.org/thread.html/r3e5795d959feb0a19b233aeaf1121a1d97fd473f5e9b14227de41c54%40%3Cgeneral.incubator.apache.org%3E
>
> Please vote on whether to recommend graduation for the Apache Iceberg
> community to the board.
>
> [ ] +1 Apache Iceberg should graduate
> [ ] +0
> [ ] -1 Apache Iceberg should not graduate because . . .
>
> The vote will be open for at least 72 hours.
>
> --
> Ryan Blue
>