Re: [VOTE] Accept Quarks into the Apache Incubator

[Amol Kekre]

+1 (non binding)

Thks
Amol

On Thu, Feb 25, 2016 at 3:28 AM, Bhupesh Chawda 
wrote:

> +1 (non-binding)
>
> Thanks.
> -Bhupesh
>
> On Thu, Feb 25, 2016 at 4:42 PM, Sandeep Deshmukh  >
> wrote:
>
> > +1 (non-binding)
> >
> > Regards,
> > Sandeep
> >
> > On Thu, Feb 25, 2016 at 3:01 AM, Luciano Resende 
> > wrote:
> >
> > > (+1) binding
> > >
> > > On Wed, Feb 24, 2016 at 9:01 AM, Katherine Marsden <
> kmars...@apache.org>
> > > wrote:
> > >
> > > > The Quarks proposal has been discussed on the incubator list.  The
> > > > discussion thread is at:
> > > >
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/%3c56c27489.7090...@apache.org%3E
> > > >
> > > > Feedback from the discussion including addition of mentor Justin
> Mclean
> > > > has been incorporated into the proposal below and available on the
> wiki
> > > at:
> > > > https://wiki.apache.org/incubator/QuarksProposal
> > > >
> > > > Please cast your vote to:
> > > > [] +1 - accept Quarks as a new incubating project
> > > > []  0 - not sure
> > > > [] -1 - do not accept the Quarks project (because: ...)
> > > >
> > > > Thanks,
> > > >
> > > > Kathey Marsden
> > > >
> > > > = Quarks Proposal =
> > > > === Abstract ===
> > > > Quarks is a stream processing programming model and lightweight
> runtime
> > > to
> > > > execute analytics at devices on the edge or at the gateway.
> > > >
> > > > === Proposal ===
> > > >  . Quarks  is a programming model and runtime for streaming analytics
> > at
> > > > the edge.   Applications are developed using a functional flow api to
> > > > define operations on data streams that is executed as a graph of
> > "oplets"
> > > > in a lightweight embeddable runtime.   The SDK provides capabilities
> > like
> > > > windowing, aggregation  and connectors with an extensible model for
> the
> > > > community to expand its  capabilities.
> > > >
> > > > === Background ===
> > > >  . Stream processing systems are commonly used to process  data from
> > edge
> > > > devices and there is a need to push some of the  streaming analytics
> to
> > > the
> > > > edge to reduce communication costs, react  locally and offload
> > processing
> > > > from the central systems.  Quarks was developed by IBM as an entirely
> > new
> > > > project to provide an SDK  and lightweight embeddable runtime for
> > > streaming
> > > > analytics at the edge.   Quarks was created to be an open source
> > project
> > > > that could provide edge  analytics to a broad community and foster
> > > > collaboration on common  analytics and connectors across a broad
> > > ecosystem
> > > > of devices.
> > > >
> > > > === Rationale ===
> > > >  . With the growth in number of connected devices (Internet of
> Things)
> > > > there is a need to execute analytics at the edge in order to take
> local
> > > > actions based upon sensor information and/or reduce the volume of
> data
> > > > sent to back-end analytic systems to reduce communication cost.
> > > >  Quarks rationale is to provide  consistent and easy to use
> programming
> > > > models to allow application developers to focus on their  application
> > > > rather than issues like device connectivity, threading etc.   Quarks'
> > > > functional data flow programming model is similar to systems  like
> > Apache
> > > > Flink, Beam (An incubating Apache project), Java 8 Streams & Apache
> > > Spark.
> > > >  The API currently has language bindings for Java8, Java7 and
> Android.
> > > > Quarks was developed to address requirements for analytics at the
> edge
> > > for
> > > > IoT use cases that were not addressed by central analytic  solutions.
> > We
> > > > believe that these capabilities will be useful to many  organizations
> > and
> > > > that the diverse nature of edge devices and use cases  is best
> > addressed
> > > by
> > > > an open community. Therefore, we would like to contribute Quarks to
> the
> > > ASF
> > > > as an open source project and begin developing a community of
> > developers
> > > > and users within Apache.
> > > >
> > > > === Initial Goals ===
> > > >  . Quarks initial code contribution provides:
> > > >
> > > >  * APIs for developing applications that execute  analytics using a
> > > > per-event (data item) streaming paradigm including  support for
> windows
> > > > against a stream for aggregation
> > > >  * A micro-kernel style runtime for execution.
> > > >  * Connectors for MQTT, HTTP, JDBC, File, Apache Kafka &  IBM Watson
> > IoT
> > > > Platform
> > > >  * Simple analytics aimed at device sensors (using Apache Common
> Math)
> > > >  * Development mode including a web-console to view the graph of
> > running
> > > > applications
> > > >  * Testing mechanism for Quarks applications that integrates with
> > > > assertion based testing systems like JUnit
> > > >  * Android specific functionality such as producing a stream that
> > > contains
> > > > a phone's sensor events (e.g. ambient temperature, pressure)
> > > >  * JUnit tests
> > > >  .

Re: [VOTE] Accept Omid into the Apache Incubator

[Amol Kekre]

+1

Thks
Amol

On Wed, Mar 23, 2016 at 7:30 PM, Chris Douglas  wrote:

> +1 (binding) -C
>
> On Wed, Mar 23, 2016 at 3:31 PM, Daniel Dai  wrote:
> > Following the discussion earlier, I'm calling a vote to accept Omid as
> > a new Incubator project.
> >
> > [ ] +1 Accept Omid into the Incubator
> > [ ] +0 Indifferent to the acceptance of Omid
> > [ ] -1 Do not accept Omid because ...
> >
> > The vote will be open for the next 72 hours.
> >
> > https://wiki.apache.org/incubator/OmidProposal
> >
> > Thanks,
> > Daniel
> >
> > = Omid Proposal =
> >
> > === Abstract ===
> > Omid is a flexible, reliable, high performant and scalable ACID
> > transactional framework that allows client applications to execute
> > transactions on top of MVCC key/value-based NoSQL datastores
> > (currently Apache HBase) providing Snapshot Isolation guarantees on
> > the accessed data.
> >
> > === Proposal ===
> > Omid is a flexible open-source transactional framework that provides
> > ACID transactions with Snapshot Isolation guarantees on top of NoSQL
> > datastores. In particular, the current codebase brings the concept of
> > transactions to the popular Apache HBase datastore. Omid offers great
> > performance, it is highly available, and scalable. Omid's current
> > version is able to scale to thousands of clients triggering concurrent
> > transactions on application data stored in HBase. Omid can scale
> > beyond 100K transactions per second on mid-range hardware while
> > incurring in a minimal impact on the speed of data access in the
> > datastore. We’re currently experimenting with a prototype version that
> > can improve the performance up to ~380K TPS.
> >
> > Omid has been publicly available as an open-source project in Github
> > under Apache License Version 2.0 since 2011 [1]. During these years,
> > it has generated certain interest in the open source community,
> > especially since the public presentation of the first version in
> > Hadoop Summit 2013 [2]. Currently the Github project has 241 Stars and
> > 93 forks. Yahoo Inc. submits this proposal to the Apache Software
> > Foundation with the aim to transfer the Omid project -including its
> > source code and documentation- to Apache in order to start the build
> > of a stable open source community around it.
> >
> > [1] https://github.com/yahoo/omid
> > [2] Omid presentation at Hadoop Summit 2013:
> >
> https://www.youtube.com/watch?v=Rhdmo9pVGgU&index=68&list=PLSAiKuajRe2luyqLU464Nxz4aQe7EPBus
> >
> > === Background ===
> > An Omid prototype was first released as an open-source project back in
> > 2011. Inspired by Google Percolator [1], it offered a lock-free
> > approach to transactions in NoSQL datastores (See [2]). However,
> > during these years, the design of Omid has evolved significantly.
> > Whilst the current open-sourced version maintains many aspects of the
> > original implementation, it is the result of a major redesign of the
> > first prototype released in 2011.
> >
> > Omid has now a more decentralized design that does not sacrifice the
> > consistency and performance of the original version. The current
> > design also enables Omid to scale to thousands of clients executing
> > transactions concurrently on application data stored in HBase.
> > Internally, Omid still utilizes a lock-free approach to support
> > multiple concurrent clients. Its design also relies on a centralized
> > conflict detection component, the TSO, which now resolves in an
> > efficient manner writeset collisions among concurrent transactions
> > without having to piggyback commit information to the clients. Another
> > important benefit of Omid is that it doesn't require any modification
> > of the underlying key-value datastore, HBase in this case. Moreover,
> > the recently added high availability algorithm allows to eliminate the
> > single point of failure represented by the TSO in those system
> > deployments requiring a higher degree of dependability. Last but not
> > least, the provided user API is very simple, mimicking transaction
> > managers in the relational world: begin, commit, rollback.
> >
> > Omid is used internally at Yahoo. Sieve, Yahoo’s web-scale content
> > management platform powering some of next-generation search and
> > personalization products is using Omid as a transaction manager in its
> > processing pipeline. Sieve essentially acts as a huge processing hub
> > between content feeds and serving systems. It provides an environment
> > for highly customizable, real-time, streamed information processing,
> > with typical discovery-to-service latencies of just a few seconds. In
> > terms of scale and availability, Omid’s new design was largely driven
> > by Sieve’s requirements.
> >
> > At Yahoo, we are also making an effort to disseminate the current
> > status of the project through blog entries (See [3], [4] and [5]) and
> > submissions to technical and academic conferences such as ATC 2016,
> > Hadoop Summit 2016, HBaseConf 2016. Last but not 

Re: [VOTE] Graduate Apex from the Incubator

[Amol Kekre]

+1

Thks,
Amol


On Mon, Mar 28, 2016 at 4:06 PM, Alan Gates  wrote:

> +1.
>
> Alan.
>
> > On Mar 28, 2016, at 14:46, Pramod Immaneni 
> wrote:
> >
> > Sorry missed including the resolution. Here is the full email again..
> >
> > 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
> >
> >
> >
> > Apache Apex 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 Hadoop native, distributed,
> > large-scale, high throughput, low-latency, fault tolerant,
> > easily operable, unified stream and batch processing platform.
> >
> > NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> > Committee (PMC), to be known as the "Apache Apex Project",
> > be and hereby is established pursuant to Bylaws of the
> > Foundation; and be it further
> >
> > RESOLVED, that the Apache Apex Project be and hereby is
> > responsible for the creation and maintenance of software
> > related to Hadoop native, distributed, large-scale,
> > high throughput, low-latency, fault tolerant, easily operable,
> > unified stream and batch processing platform;
> > and be it further
> >
> > RESOLVED, that the office of "Vice President, Apache Apex" 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 Apex Project, and to have primary responsibility
> > for management of the projects within the scope of
> > responsibility of the Apache Apex 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 Apex Project:
> >
> > * Ilya Ganelin 
> > * P. Taylor Goetz 
> > * Gaurav Gupta 
> > * Pramod Immaneni 
> > * Amol Kekre 
> > * Justin Mclean 
> > * Chetan Narsude 
> > * Chris Nauroth 
> > * Vlad Rozov 
> > * Hitesh Shah 
> > * Thomas Weise 
> > * David Yan 
> > * Brennon York 
> >
> > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Thomas Weise
> > be appointed to the office of Vice President, Apache Apex, 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 Apex 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 Apex Project; and be it further
> >
> > RESOLVED, that the Apache Apex Project be and hereby
> > is tasked with the migration and rationalization of the Apache
> > Incubator Apex podling; and be it further
> >
> > RESOLVED, that all responsibilities pertaining to the Apache
> > Incubator Apex podling encumbered upon the Apache Incubator
> > Project are hereafter discharged.
> >
> >
> > On Mon, Mar 28, 2016 at 2:24 PM, Ted Dunning 
> wrote:
> >
> >> There hasn't been a discussion thread here on the general list, but I am
> >> still prepared to vote in favor of this.
> >>
> >> +1
> >>
> >> See!
> >>
> >> I just did.
> >>
> >>
> >>
> >> On Mon, Mar 28, 2016 at 2:20 PM, Pra

Re: [VOTE] Graduate Johnzon from the Incubator

[Amol Kekre]

+1

Thks
Amol


On Fri, Apr 1, 2016 at 4:10 PM, John D. Ament  wrote:

> +1
>
> On Fri, Apr 1, 2016 at 3:49 PM Hendrik Dev  wrote:
>
> > The Apache Johnzon community has discussed and voted on graduation to
> > a top level project. The vote passed with 8 +1 votes (5 from the PPMC)
> > and no 0 or -1 votes.
> >
> > Incubation Status:
> > http://incubator.apache.org/projects/johnzon.html
> > Maturity Assessment:
> > https://s.apache.org/d88S
> > Discussions:
> > https://s.apache.org/5vxO
> > https://s.apache.org/8VkX
> > Vote:
> > https://s.apache.org/suuK
> > (http://markmail.org/message/mawumtfqokgye5xn)
> > Result:
> > https://s.apache.org/Erd0
> > (http://markmail.org/message/qmqvk56ccqkq2gob)
> >
> > Please vote on the resolution pasted below to graduate Apache Johnzon
> > from the incubator to top level project.
> >
> > [ ] +1 Graduate Apache Johnzon from the Incubator.
> > [ ] +0 Don't care.
> > [ ] -1 Don't graduate Apache Johnzon 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,
> >
> > Hendrik Saly on behalf of the Apache Johnzon PPMC
> >
> > Apache Johnzon 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 JSR-353 compliant JSON parsing and a
> > set of useful modules to help with the usage of JSR-353
> > as well as JSR successors (like JSR-374) or related JSRs
> > (like JSR-367).
> >
> >
> > NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> > Committee (PMC), to be known as the "Apache Johnzon Project",
> > be and hereby is established pursuant to Bylaws of the
> > Foundation; and be it further
> >
> > RESOLVED, that the Apache Johnzon Project be and hereby is
> > responsible for the creation and maintenance of software
> > related to JSR-353 compliant JSON parsing and a
> > set of useful modules to help with the usage of JSR-353
> > as well as JSR successors (like JSR-374) or related JSRs
> > (like JSR-367); and be it further
> >
> > RESOLVED, that the office of "Vice President, Apache Johnzon" 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 Johnzon Project, and to have primary responsibility
> > for management of the projects within the scope of
> > responsibility of the Apache Johnzon 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 Johnzon Project:
> >
> > * Justin Mclean 
> > * Romain Manni-Bucau 
> > * Jean-Louis Monteiro 
> > * Mark Struberg 
> > * Hendrik Saly 
> >
> > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Hendrik Saly (salyh)
> > be appointed to the office of Vice President, Apache Johnzon, 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 Johnzon 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 Johnzon Project; and be it further
> >
> > RESOLVED, that the Apache Johnzon Project be and hereby
> > is tasked with the migration and rationalization of the Apache
> > Incubator Johnzon podling; and be it further
> >
> > RESOLVED, that all responsibilities pertaining to the Apache
> > Incubator Johnzon podling encumbered upon the Apache Incubator
> > Project are hereafter discharged.
> >
> > --
> > Hendrik Saly (salyh, hendrikdev22)
> > @hendrikdev22
> > PGP: 0x22D7F6EC
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>

Re: [VOTE] Accept Gossip into the Apache Incubator

[Amol Kekre]

+1

Thks,
Amol

On Mon, Apr 25, 2016 at 11:22 AM, Josh Elser  wrote:

> +1 (binding)
>
> P. Taylor Goetz wrote:
>
>> Following the discussion thread [1], I would like to call a VOTE to
>> accept Gossip into the Apache Incubator.
>>
>> The Gossip proposal can be found here [2] and is also listed below.
>>
>> [ ] +1 Accept Gossip into the Apache Incubator
>> [ ] +0 Abstain.
>> [ ] -1 Do not accept Gossip into the Apache Incubator because…
>>
>> This vote will be open for at least 72 hours.
>>
>> Obviously I am +1 (binding).
>>
>> -Taylor
>>
>> [1] https://s.apache.org/gossip-discuss
>> [2] https://wiki.apache.org/incubator/GossipProposal
>>
>> 
>> = Abstract =
>>
>> Apache Gossip will be an implementation of the Gossip Protocol based on
>> code available here: https://github.com/edwardcapriolo/gossip/ which is
>> already licenced using the glorious Apache V2 License.
>>
>> = Proposal =
>>
>> Apache Gossip aims to provide a gossip based consensus protocol written
>> in Java for peer-to-peer communication to the Apache Incubator
>> (http://incubator.apache.org/). This implementation will effectively
>> scale from one to one-thousand node clusters. In addition to the code
>> implementation, the project should produce specifications of the wire
>> protocol, features, and expected behavior of the system such that
>> compatible implementations can communicate.
>>
>> = Background =
>>
>> The gossip protocol has been implemented to varying levels of rigor by a
>> number of entities. In particular, Apache Cassandra uses an
>> implementation of gossip to locate peers and transmit up/down state.
>> Apache Spark leverages tooling in Akka which provides peer-to-peer node
>> discovery capabilities.
>>
>> *
>>
>> http://highscalability.com/blog/2011/11/14/using-gossip-protocols-for-failure-detection-monitoring-mess.html
>>
>> * https://en.wikipedia.org/wiki/Gossip_protocol
>>
>> = Rationale =
>>
>> With distributed computing becoming extremely widespread, and the growth
>> of the buzz-factor of ‘the-internet-of-things’ it is increasingly
>> important that networks of IP addressable devices can form a
>> peer-to-peer network. Applications of peer-to-peer networks include
>> generating crypto currency, managing hardware such as solar power
>> micro-grids, and more traditional roles like grid/High Performance
>> Computing and distributed storage systems. Different implementations of
>> gossip based consensus protocols have been implemented in numerous
>> languages or as part of more complex software stacks. The Apache
>> Software Foundation should lead the effort of producing a purpose built
>> tool that can be used by downstream projects to form peer-to-peer
>> networks.
>>
>> = Initial Goals =
>>
>> * Migration of current code https://github.com/edwardcapriolo/gossip and
>> existing community to the Apache Software Foundation infrastructure
>> * Secure communications
>> * Transport security using a pre-shared key
>> * Public Key Infrastructure
>> * Introduce a cluster name to wire protocol to avoid misconfigurations
>> * Effectively operate when systems have multiple network interfaces by
>> controlling IP binding settings
>> * Effectively operate when systems have Network Address Translations
>> devices between them using a broadcast IP settings
>> * Develop advanced integration testing from cluster sizes of 1-1000 nodes
>> * Test convergence times
>> * Demonstrate the tradeoffs of different settings in regard to
>> bandwidth/cpu/convergence time/accuracy
>> * Gossip data other than cluster state such as application/user data
>> * Provide detailed specifications such that others can implement the
>> protocol in other programming languages
>> * Explore HTTP transport as an alternative to UDP
>>
>> = Current Status =
>>
>> The current code has been around for some time. Previously it was a
>> Google code project. Since the fork in January 2015 there have been 55
>> commits and 4 releases.
>>
>> == Meritocracy ==
>>
>> We believe in meritocracy. All suggestions are taken seriously. We enjoy
>> helping new people become part of process. For other projects available
>> on our Github, once a user shows enough activity we grant them
>> collaborator status.
>>
>> == Community ==
>>
>> In a relatively short amount of time, with a small amount of promotion
>> on twitter and through blogging, we have 50+ followers on Github and
>> several forks of the project. With the Apache brand we should be able to
>> attract more. Once we have entered the incubator we believe it will be
>> easier to attempt to unify with other similar implementations.
>>
>> == Core Developers ==
>>
>> The code was forked on Jan 9th 2015, since then there have been 4
>> releases and 55 commits. Since that period, the majority of the work was
>> undertaken by Edward Capriolo. Several people are interested in the
>> features of this proposal and have indicated they will volunteer their
>> time.
>>
>> == Alignment ==
>>
>> Apache is the perfect o

Re: [VOTE] Accept Pony Mail into the Apache Incubator

[Amol Kekre]

+1 (non-binding)

Thks
Amol

On Fri, May 27, 2016 at 6:35 AM, Shane Curcuru  wrote:

> +1 (binding)
>
> Daniel Gruno wrote on 5/24/16 1:56 AM:
> > Since it seems the discussion has died down, I am now calling a vote on
> > accepting Pony Mail into the Incubator. Sorry in advance for potato.
> >
> > This vote will run for the usual 72 hours.
> >
> > ### PROPOSAL BELOW ###
> >
> > Abstract
> >
> > Pony Mail is a mail-archiving, archive viewing, and interaction service,
> > that can be integrated with many email platforms.
> ...
>
> > Affiliations
> >
> > Daniel Gruno - Quenda IvS
> > Tony Stevenson - pctony ltd, VocalIQ Ltd
> > Richard Bowen - Redhat, inc.
> > Ulises Beresi - Datastax, inc.
> > David P Kendal - Quenda IvS
> > Francesco Chicchiriccò - Tirasa S.r.l.
> > Sam Ruby - IBM
> > Shane Curcuru - IBM(?)
> > Jim Jagielski - Capital One
>
> Please note I will (very, very soon) be independent, as my last day with
> $Employer is Tuesday, so we should take off my affiliation.
>
> Thanks,
> - Shane
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Accept CarbonData into the Apache Incubator

[Amol Kekre]

+1 (non-binding)

Thks
Amol

On Fri, May 27, 2016 at 5:53 AM, Jim Jagielski  wrote:

> Thx for the feedback...
>
> I change my vote to +1 (binding)
> > On May 27, 2016, at 1:46 AM, Jean-Baptiste Onofré 
> wrote:
> >
> > Hi Jim,
> >
> > good point. Let me try to explain this "gap" regarding my discussion
> with the team:
> >
> > 1. Some people have been involved mostly in architecture and design more
> directly in code. That's why they are part of the initial committer list,
> whereas they didn't really provide "visible" code on github.
> >
> > 2. Some people are no more involved in the project. That's why they
> don't appear on the initial committer list.
> >
> > Regards
> > JB
> >
> > On 05/26/2016 05:45 PM, Jim Jagielski wrote:
> >> I am trying to align the list of initial committers with
> >> the list of current/active contributors, according to
> >> Github, and I am seeing people proposed who have not
> >> contributed anything and people NOT proposed who seem
> >> to be kinda active...
> >>
> >> Sooo. -0
> >>
> >>> On May 25, 2016, at 4:24 PM, Jean-Baptiste Onofré 
> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> following the discussion thread, I'm now calling a vote to accept
> CarbonData into the Incubator.
> >>>
> >>> ​[ ] +1 Accept CarbonData into the Apache Incubator
> >>> [ ] +0 Abstain
> >>> [ ] -1 Do not accept CarbonData into the Apache Incubator, because ...
> >>>
> >>> This vote is open for 72 hours.
> >>>
> >>> The proposal follows, you can also access the wiki page:
> >>> https://wiki.apache.org/incubator/CarbonDataProposal
> >>>
> >>> Thanks !
> >>> Regards
> >>> JB
> >>>
> >>> = Apache CarbonData =
> >>>
> >>> == Abstract ==
> >>>
> >>> Apache CarbonData is a new Apache Hadoop native file format for faster
> interactive
> >>> query using advanced columnar storage, index, compression and encoding
> techniques
> >>> to improve computing efficiency, in turn it will help speedup queries
> an order of
> >>> magnitude faster over PetaBytes of data.
> >>>
> >>> CarbonData github address: https://github.com/HuaweiBigData/carbondata
> >>>
> >>> == Background ==
> >>>
> >>> Huawei is an ICT solution provider, we are committed to enhancing
> customer experiences for telecom carriers, enterprises, and consumers on
> big data, In order to satisfy the following customer requirements, we
> created a new Hadoop native file format:
> >>>
> >>> * Support interactive OLAP-style query over big data in seconds.
> >>> * Support fast query on individual record which require touching all
> fields.
> >>> * Fast data loading speed and support incremental load in period of
> minutes.
> >>> * Support HDFS so that customer can leverage existing Hadoop cluster.
> >>> * Support time based data retention.
> >>>
> >>> Based on these requirements, we investigated existing file formats in
> the Hadoop eco-system, but we could not find a suitable solution that
> satisfying requirements all at the same time, so we start designing
> CarbonData.
> >>>
> >>> == Rationale ==
> >>>
> >>> CarbonData contains multiple modules, which are classified into two
> categories:
> >>>
> >>> 1. CarbonData File Format: which contains core implementation for file
> format such as columnar,index,dictionary,encoding+compression,API for
> reading/writing etc.
> >>> 2. CarbonData integration with big data processing framework such as
> Apache Spark, Apache Hive etc. Apache Beam is also planned to abstract the
> execution runtime.
> >>>
> >>> === CarbonData File Format ===
> >>>
> >>> CarbonData file format is a columnar store in HDFS, it has many
> features that a modern columnar format has, such as splittable, compression
> schema ,complex data type etc. And CarbonData has following unique features:
> >>>
> >>>  Indexing 
> >>>
> >>> In order to support fast interactive query, CarbonData leverage
> indexing technology to reduce I/O scans. CarbonData files stores data along
> with index, the index is not stored separately but the CarbonData file
> itself contains the index. In current implementation, CarbonData supports 3
> types of indexing:
> >>>
> >>> 1. Multi-dimensional Key (B+ Tree index)
> >>> The Data block are written in sequence to the disk and within each
> data blocks each column block is written in sequence. Finally, the metadata
> block for the file is written with information about byte positions of each
> block in the file, Min-Max statistics index and the start and end MDK of
> each data block. Since, the entire data in the file is in sorted order, the
> start and end MDK of each data block can be used to construct a B+Tree and
> the file can be logically  represented as a B+Tree with the data blocks as
> leaf nodes (on disk) and the remaining non-leaf nodes in memory.
> >>> 2. Inverted index
> >>> Inverted index is widely used in search engine. By using this index,
> it helps processing/query engine to do filtering inside one HDFS block.
> Furthermore, query acceleration for count distinct like operation is made
> possible 

Re: [DICSUSS] Graduation of Apache Twill as Top Level Project

[Amol Kekre]

+1 (non-binding)

Thks,
Amol

On Wed, Jun 1, 2016 at 10:53 AM, Suneel Marthi  wrote:

> +1 binding
>
> On Wed, Jun 1, 2016 at 1:24 PM, Henry Saputra 
> wrote:
>
> > Hi All,
> >
> > The Apache Twill PPMCs and the community had discussed and voted to
> > graduate to become Apache TLP.
> >
> > It is a small but welcoming community, and the mentors and rest of PPMCs
> > believe that we have satisfied the learning phase during our incubation
> > period.
> >
> > The community has made several good releases and added new PPMC during
> its
> > time in incubator [1]
> >
> > It also has been used by external project such as Cask Data CDAP [2] and
> > Apache Fluo [3]
> >
> > The PPMCs also have made some presentations in conferences and meetups to
> > be open and inclusive [4] [5]
> >
> >
> > Here is the link to the VOTE:
> >
> >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-twill-dev/201605.mbox/%3cCALuGr6ZB1DZVWZJNd+-ib0NXZwyWebSBE0evs0Yp8uthe+=o...@mail.gmail.com%3e
> >
> >
> > Here is link to the VOTE result summary:
> >
> >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-twill-dev/201605.mbox/%3cCALuGr6aSYs=daVpeeYO0GPKdfu=dkhvyhw12jdj66-dpzsq...@mail.gmail.com%3e
> >
> > Thanks,
> >
> > - Henry
> > On behalf of Apache Twill PPMC
> >
> >
> > [1] http://incubator.apache.org/projects/twill.html
> > [2] http://cdap.io
> > [3] https://wiki.apache.org/incubator/FluoProposal
> > [4]
> >
> >
> http://apacheconnorthamerica2014.sched.org/event/1fhOZ6T/harnessing-the-power-of-yarn-with-apache-twill
> > [5]
> >
> >
> http://apachebigdata2016.sched.org/event/6Lzt/building-large-scale-applications-in-apache-hadoop-yarn-with-apache-twill-henry-saputra-terence-yim-apache-software-foundation?iframe=no&w=&sidebar=yes&bg=no
> >
> > ## Resolution to create a TLP from graduating Incubator podling
> >
> >
> > X. Establish the Apache Twill 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 providing a set of libraries to provide
> > abstraction
> >
> >to develop distributed applications such as with Apache Hadoop
> YARN.
> >
> >
> >NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> >
> >Committee (PMC), to be known as the "Apache Twill Project",
> >
> >be and hereby is established pursuant to Bylaws of the
> >
> >Foundation; and be it further
> >
> >
> >RESOLVED, that the Apache Twill Project be and hereby is
> >
> >responsible for the creation and maintenance of software
> >
> >related to providing a set of libraries to provide abstraction
> > to develop
> >
> >distributed applications such as with Apache Hadoop YARN
> >
> >and be it further
> >
> >
> >RESOLVED, that the office of "Vice President, Apache Twill" 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 Twill Project, and to have primary responsibility
> >
> >for management of the projects within the scope of
> >
> >responsibility of the Apache Twill 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 Twill Project:
> >
> >
> >  * Terence Yim 
> >
> >  * Andreas Neumann 
> >
> >  * Gary Helmling 
> >
> >  * Albert Shau 
> >
> >  * Poorna Chandra 
> >
> >  * Henry Saputra 
> >
> >
> >NOW, THEREFORE, BE IT FURTHER RESOLVED, that Terence Yim
> >
> >be appointed to the office of Vice President, Apache Twill, 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 Twill 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 Twill Project; and be it further
> >
> >
> >RESOLVED, that the Apache Twill Project be and hereby
> >
> >is tasked with the migration and rationalization of the Apache
> >
> >Incubator Twill podling; and be it further
> >
> >
> >RESOLVED, that all responsibilities pertaining to the Apache
> >
> >Incubator Twill podling encumbered upon the Apache Incubator
> >
> >Project are her

Re: [VOTE] Graduate Apache Twill as Top Level Project

[Amol Kekre]

+1 (non-binding)

Thks
Amol

On Thu, Jun 2, 2016 at 3:27 PM, James Taylor  wrote:

> +1 (binding)
>
> On Thursday, June 2, 2016, Andrew Purtell  wrote:
>
> > +1 (binding)
> >
> > On Thu, Jun 2, 2016 at 3:06 PM, Henry Saputra  > >
> > wrote:
> >
> > > Hi All,
> > >
> > > Following the DISCUSS thread about Apache Twill graduating as TLP, I
> > would
> > > like to send VOTE request thread.
> > >
> > > All the +1 binding votes sent in the DISCUSS will be counted in the
> final
> > > tally unless the individual request otherwise.
> > >
> > > Here is the link to the VOTE in dev@ list:
> > >
> > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-twill-dev/201605.mbox/%3cCALuGr6ZB1DZVWZJNd+-ib0NXZwyWebSBE0evs0Yp8uthe+=o...@mail.gmail.com%3e
> > >
> > >
> > > Here is link to the VOTE result summary in the dev@list :
> > >
> > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/incubator-twill-dev/201605.mbox/%3cCALuGr6aSYs=daVpeeYO0GPKdfu=dkhvyhw12jdj66-dpzsq...@mail.gmail.com%3e
> > >
> > >
> > > The VOTE will run until June 6, 2016 4pm PST
> > >
> > > +1 [  ]
> > > 0 [  ]
> > > -1 [  ]
> > >
> > >
> > >
> > > Thanks,
> > >
> > > - Henry
> > > On behalf of Apache Twill PPMC
> > >
> > >
> > > PS:
> > >
> > > Here is my vote:
> > >
> > > +1 (binding)
> > >
> > >
> > >
> > >
> > > ## Resolution to create a TLP from graduating Incubator podling
> > >
> > >
> > > X. Establish the Apache Twill 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 providing a set of libraries as
> > > abstraction to develop
> > >
> > >distributed applications, with a programming model that is
> similar
> > > to
> > >
> > >running threads, inside compute cluster such as Apache Hadoop
> YARN
> > >
> > >NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> > >
> > >Committee (PMC), to be known as the "Apache Twill Project",
> > >
> > >be and hereby is established pursuant to Bylaws of the
> > >
> > >Foundation; and be it further
> > >
> > >
> > >RESOLVED, that the Apache Twill Project be and hereby is
> > >
> > >responsible for the creation and maintenance of software
> > >
> > >related to providing a set of libraries as abstraction to
> develop
> > >
> > >distributed applications, with a programming model that is
> similar
> > > to
> > >
> > >running threads, inside compute cluster such as Apache Hadoop
> YARN
> > >
> > >and be it further
> > >
> > >
> > >RESOLVED, that the office of "Vice President, Apache Twill" 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 Twill Project, and to have primary responsibility
> > >
> > >for management of the projects within the scope of
> > >
> > >responsibility of the Apache Twill 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 Twill Project:
> > >
> > >
> > >  * Terence Yim >
> > >
> > >  * Andreas Neumann >
> > >
> > >  * Gary Helmling >
> > >
> > >  * Albert Shau >
> > >
> > >  * Poorna Chandra >
> > >
> > >  * Henry Saputra >
> > >
> > >
> > >NOW, THEREFORE, BE IT FURTHER RESOLVED, that Terence Yim
> > >
> > >be appointed to the office of Vice President, Apache Twill, 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 Twill 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 Twill Project; and be it further
> > >
> > >
> > >RESOLVED, that the Apache Twill Project be and hereby
> > >
> > >is tasked with the migration and rationalization of the Apache
> > >
> > >Incubator Twill podling; and be it further
> > >
> > >
> > >RESOLVED, that all responsibilities pertaining to the Apache
> > >
> > >Incubator Twill podling encumbered upon the Apache Incubator
> > >
> > >Project are hereafter discharged.
> > >
> >
> >
> >

Re: [VOTE] Graduate Apache Geode (incubating)

[Amol Kekre]

+1

Thks
Amol

On Mon, Nov 7, 2016 at 7:10 PM, Nitin Lamba  wrote:

> +1!
>
> On Mon, Nov 7, 2016 at 7:05 PM, Niall Pemberton  >
> wrote:
>
> > On Mon, Nov 7, 2016 at 6:34 PM, Daniel Gruno 
> wrote:
> >
> > > I was looking at Snoot, and some figures jumped at me.
> > >
> > > Is the Podling (and the IPMC) satisfied that there is no concern with
> > > people affiliated with a single company providing more than 90% of all
> > > commits over the past year and, as far as I can tell, the vast majority
> > > of tickets and email, as well as a 73% stake in the proposed PMC?
> > >
> > > Is the IPMC satisfied that, should this company opt to not further
> spend
> > > resources on this project, that the project would still be as viable?
> > >
> >
> > Hi Daniel,
> >
> > I've observed this project since it joined the incubator and they've
> worked
> > hard to create an open and welcoming community and to fix all the issues
> > raised that could be barriers to their graduation.
> >
> > In terms of percentages, these things have been debated previously in
> > graduation of projects such as Ignite, Flume, Tez etc and I'm not going
> to
> > repeat the arguments from those discussions. Geode would be better with
> > served with a wider community, but I think what matters is 1) have they
> > demonstrated the behaviors we expect and 2) are they moving in the right
> > direction. Geode is a great community and a pleasure to be involved with
> > and I would say yes to both of these. I believe they are going in the
> right
> > direction to make this project less dependent on one company and except
> to
> > change the percentages you've pointed out, theres no purpose left for
> them
> > being in the incubator. They've shown that they can manage themselves and
> > theres enough independent oversight to mitigate concerns which is why I
> > think we should vote for them to graduate.
> >
> > Niall
> >
> >
> >
> > >
> > > With regards,
> > > Daniel.
> > >
> > > On 11/07/2016 07:17 PM, Mattmann, Chris A (3010) wrote:
> > > > +1 (binding). Great work!
> > > >
> > > > ++
> > > > Chris Mattmann, Ph.D.
> > > > Principal Data Scientist, Engineering Administrative Office (3010)
> > > > Manager, Open Source Projects Formulation and Development Office
> (8212)
> > > > NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> > > > Office: 180-503E, Mailstop: 180-502
> > > > Email: chris.a.mattm...@nasa.gov
> > > > WWW:  http://sunset.usc.edu/~mattmann/
> > > > ++
> > > > Director, Information Retrieval and Data Science Group (IRDS)
> > > > Adjunct Associate Professor, Computer Science Department
> > > > University of Southern California, Los Angeles, CA 90089 USA
> > > > WWW: http://irds.usc.edu/
> > > > ++
> > > >
> > > >
> > > > On 11/7/16, 10:16 AM, "gch...@gmail.com on behalf of Greg Chase" <
> > > gch...@gmail.com on behalf of g...@gregchase.com> wrote:
> > > >
> > > > +1!
> > > >
> > > > On Mon, Nov 7, 2016 at 10:13 AM, Nabarun Nag 
> > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > On Mon, Nov 7, 2016 at 10:11 AM Mark Bretl 
> > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > --Mark
> > > > > >
> > > > > > On Sun, Nov 6, 2016 at 11:07 PM, Avinash Dongre <
> > > adon...@apache.org>
> > > > > > wrote:
> > > > > >
> > > > > > > +1
> > > > > > >
> > > > > > > On Mon, Nov 7, 2016 at 12:35 PM, Sergio Fernández <
> > > wik...@apache.org>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > +1
> > > > > > > >
> > > > > > > > good luck, guys!
> > > > > > > >
> > > > > > > > On Sun, Nov 6, 2016 at 11:42 PM, John D. Ament <
> > > > > johndam...@apache.org>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > +1
> > > > > > > > >
> > > > > > > > > On Nov 6, 2016 15:58, "Roman Shaposhnik" <
> > > ro...@shaposhnik.org>
> > > > > > wrote:
> > > > > > > > >
> > > > > > > > > > Hi!
> > > > > > > > > >
> > > > > > > > > > after a very positive discussion in the Geode
> community
> > > > > > > > > > and at the IPMC level:
> > > > > > > > > > http://markmail.org/message/z4prj62hr7rn6cu6
> > > > > > > > > > I'd like to bring the following resolution for a
> formal
> > > vote.
> > > > > > > > > >
> > > > > > > > > > Please vote on the resolution pasted below to
> graduate
> > > > > > > > > > Apache Geode from the incubator to top level project.
> > > > > > > > > >
> > > > > > > > > > [ ] +1 Graduate Apache Geode from the Incubator.
> > > > > > > > > > [ ] +0 Don't care.
> > > > > > > > > > [ ] -1 Don't graduate Apache Geode from the Incubator
> > > because...
> > > > > > > > > >
> > > > > > > > > > This vote will be open for at least 72 hours.
> > > > > > > > > >
> > >

Re: [VOTE] Accept RocketMQ into the Apache Incubator

[Amol Kekre]

+1 (non-binding)

Thks
Amol


On Thu, Nov 10, 2016 at 10:20 AM, Debo Dutta (dedutta) 
wrote:

> +1 non binding
>
>
>
>
> On 11/10/16, 10:07 AM, "Myrle Krantz"  wrote:
>
> >+1 non binding
> >
> >-Myrle
> >
> >> On 10 Nov 2016, at 19:04, John D. Ament  wrote:
> >>
> >> +1
> >>
> >>> On Nov 10, 2016 11:41, "Bruce Snyder"  wrote:
> >>>
> >>> Subsequent to the discussion on RocketMQ, I would like to call a vote
> on
> >>> accepting RocketMQ into the Apache Incubator.
> >>>
> >>> [ ] +1 Accept RocketMQ into the Apache Incubator
> >>> [ ] +0 Abstain.
> >>> [ ] -1 Do not accept RocketMQ into the Apache Incubator because...
> >>>
> >>> The proposal is pasted below and also available in the wiki here:
> >>>https://wiki.apache.org/incubator/RocketMQProposal
> >>>
> >>> Also, the ASF voting guidelines are available here:
> >>>http://www.apache.org/foundation/voting.html
> >>>
> >>> Thanks,
> >>>
> >>> Bruce
> >>>
> >>>
> >>> = RocketMQ Proposal =
> >>>
> >>> == Abstract ==
> >>>
> >>> RocketMQ is a fast, low latency, reliable, scalable, distributed, easy
> to
> >>> use message-oriented middleware, especially for processing large
> amounts of
> >>> streaming data.
> >>>
> >>> == Proposal ==
> >>>
> >>> RocketMQ provides a message model including both pub/sub and P2P and it
> >>> supports both reliable FIFO and strict sequential message queues. It
> also
> >>> has the ability to accumulate a billion messages in a single queue,
> >>> provides mobile, internet-friendly protocols such as MQTT and HTTP.
> >>> RocketMQ also supports the ability to load data into Apache Hadoop for
> >>> offline storage or to handle stream processing for Apache Storm.
> >>>
> >>> == Background ==
> >>>
> >>> RocketMQ was developed at Alibaba in 2011 and has been used in
> production
> >>> there since that time. It can process the large amounts of events
> generated
> >>> by various systems and provides a common repository for many types of
> >>> consumers to access and process those events. RocketMQ also handles
> dozens
> >>> of types of events including trade order process, search, social
> network
> >>> activity stream and data pipeline. Every day at Alibaba, RocketMQ
> clusters
> >>> process more than 500 billion events. The Alibaba Group also uses
> RocketMQ
> >>> to provide message services for more than 3000 core applications.
> >>>
> >>> RocketMQ was developed to meet Alibaba's particular use cases to
> provide
> >>> low latency message delivery and high throughput message sending.
> Alibaba
> >>> has also created its cornerstone product derived from RocketMQ, a
> Platform
> >>> as a Service (PaaS) product named the Alibaba Cloud Platform (
> >>> https://intl.aliyun.com/).  More than 100 companies use the RocketMQ
> open
> >>> source version today. We believe RocketMQ can benefit more people so,
> we
> >>> would like to share it via the ASF and begin developing a community of
> >>> developers and users via The Apache Way.
> >>>
> >>>
> >>> == Rationale ==
> >>>
> >>> As background description, many organizations can benefit from a low
> >>> latency, reliable, high throughput, distributed platform. Its usage is
> >>> varied and we expect many new use cases to emerge. RocketMQ provides
> many
> >>> features to support many use cases from enterprise application
> integration,
> >>> to web applications to the flourishing of IoT applications.
> >>>
> >>> == Current Status ==
> >>>
> >>> === Meritocracy ===
> >>>
> >>> The intent of this proposal is to start building a diverse developer
> and
> >>> user community around RocketMQ following the ASF meritocracy model.
> Since
> >>> RocketMQ was open sourced, we have solicited contributions via the
> website
> >>> and presentations given to user groups and technical audiences and have
> >>> received positive feedback and contributions including clients for C++
> and
> >>> .NET. We plan to continue this support for new contributors and work
> with
> >>> those who contribute significantly to the project to encourage them to
> >>> become committers.
> >>>
> >>> === Community ===
> >>>
> >>> RocketMQ is currently being developed by engineers working for Alibaba
> >>> where it is highly used in a production environment. We also have
> active
> >>> users in or have received contributions from a diverse set of companies
> >>> including CMBC(China Minsheng Bank), Schneider Electric(
> >>> http://www.schneider-electric.com/), the China Railway Ministry
> official
> >>> ticketing website, China Union, Sina, Umei (http://sh.jumei.com),
> Chinese
> >>> Academy of Sciences and many more. We hope to grow the base of
> contributors
> >>> by inviting all those who offer significant contributions and excel
> through
> >>> the use of The Apache Way. Contributions from outside of Alibaba are
> now
> >>> being received by the RocketMQ project, including a dashboard, the
> >>> flume-rocketmq module, the storm-rocketmq and more.
> >>>
> >>> To further this goal, the project currently makes use of GitHub proje

Re: [RESTART] [VOTE] Graduate Apache Beam

[Amol Kekre]

+1 (non-binding)

Thks
Amol

On Tue, Dec 6, 2016 at 7:44 PM, Thomas Weise  wrote:

> +1
>
> On 2016-12-06 09:44 (-0800), James Taylor  wrote:
> > +1 (binding)
> >
> > On Tue, Dec 6, 2016 at 7:38 AM, Tom Barber  wrote:
> >
> > > +1
> > >
> > > On Tue, Dec 6, 2016 at 3:37 PM, Stephan Ewen  wrote:
> > >
> > > > +1 (binding)
> > > >
> > > >
> > > >
> > > > On Tue, Dec 6, 2016 at 1:27 PM, Sandeep Deshmukh <
> > > sand...@datatorrent.com>
> > > > wrote:
> > > >
> > > > > +1 (non-binding)
> > > > >
> > > > > Regards,
> > > > > Sandeep
> > > > >
> > > > > On Tue, Dec 6, 2016 at 6:24 PM, Stian Soiland-Reyes <
> st...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > +1 (binding)
> > > > > >
> > > > > > On 5 December 2016 at 23:30, Davor Bonaci 
> wrote:
> > > > > > > Hi everyone,
> > > > > > > Please vote on the draft resolution proposed by the Apache Beam
> > > PPMC
> > > > > > below,
> > > > > > > which establishes Apache Beam as a new top-level project at the
> > > > Apache
> > > > > > > Software Foundation, as follows:
> > > > > > >
> > > > > > > [ ] +1, Graduate Apache Beam from the Incubator.
> > > > > > > [ ] +0, Don't care.
> > > > > > > [ ] -1, Don't graduate Apache Beam from the Incubator
> because...
> > > > > > >
> > > > > > > Please note that this is a restarted vote, per John's request,
> to
> > > > > clarify
> > > > > > > the alternatives. The old voting thread is archived [1].
> > > > > > >
> > > > > > > Before voting, please see the full text of the draft resolution
> > > below
> > > > > and
> > > > > > > the corresponding discussion thread [2], and vote only after
> you
> > > feel
> > > > > > ready
> > > > > > > to do so. The vote will be open for at least 72 hours. This is
> a
> > > > > > procedural
> > > > > > > vote [3]; it is adopted by a simple majority of qualified votes
> > > (with
> > > > > no
> > > > > > > minimum).
> > > > > > >
> > > > > > > If approved by the Apache Incubator, the proposed resolution
> will
> > > be
> > > > > > > submitted to the Board of Directors for their consideration.
> > > > > > >
> > > > > > > Thank you!
> > > > > > >
> > > > > > > Davor
> > > > > > >
> > > > > > > [1]
> > > > > > > https://lists.apache.org/thread.html/
> > > a8e9cecfe93f0e464cc7c1774d2761
> > > > > > ca14326df1101b7670ca8b1dc3@%3Cgeneral.incubator.apache.org%3E
> > > > > > > [2]
> > > > > > > https://lists.apache.org/thread.html/
> > > b9c1071b35558846836814575ada3c
> > > > > > dca61c72dc1e672ab994a9c936@%3Cgeneral.incubator.apache.org%3E
> > > > > > > [3] http://apache.org/foundation/voting.html
> > > > > > >
> > > > > > > The full-text of the draft resolution proposed by the Apache
> Beam
> > > > PPMC:
> > > > > > >
> > > > > > > X. Establish the Apache Beam 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 a unified programming model for
> both
> > > > > > >batch and streaming data processing, enabling efficient
> > > > > > >execution across diverse distributed execution engines
> > > > > > >and providing extensibility points for connecting to
> > > different
> > > > > > >technologies and user communities.
> > > > > > >
> > > > > > >NOW, THEREFORE, BE IT RESOLVED, that a Project
> Management
> > > > > > >Committee (PMC), to be known as the "Apache Beam
> Project",
> > > > > > >be and hereby is established pursuant to Bylaws of the
> > > > > > >Foundation; and be it further
> > > > > > >
> > > > > > >RESOLVED, that the Apache Beam Project be and hereby is
> > > > > > >responsible for the creation and maintenance of software
> > > > > > >related to a unified programming model for both batch
> and
> > > > > > >streaming data processing, enabling efficient execution
> > > across
> > > > > > >diverse distributed execution engines and providing
> > > > > extensibility
> > > > > > >points for connecting to different technologies and user
> > > > > > >communities; and be it further
> > > > > > >
> > > > > > >RESOLVED, that the office of "Vice President, Apache
> Beam"
> > > 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 Beam Project, and to have primary
> > > responsibility
> > > > > > >for management of the projects within the scope of
> > > > > > >responsibility of the Apache Beam Project; and be it
> further
> > > > > > >
> > > > > > >RESOLVED, that the persons listed immediately below be
> and
>

Need to be able to edit a page on wiki.apache.org

[Amol Kekre]

I want to create a wiki page for a proposal to incubate Apex with ASF. Can
someone give me edit access for the following page?

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

For those unfamiliar with Apex; it is an unified batch and stream
processing compute platform native to Yarn that was open sourced under
Apache 2.0 by DataTorrent over a month ago.

my username is AmolKekre

Thks,
Amol

[DISCUSS] Apex Incubation Proposal

[Amol Kekre]

orks. 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)
   * 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 (rikin dot shah at capitalone dot com)
   * Luis Ramos (l dot ramos at ge dot com)
   * Munagala Ramanath (ram at datatorrent dot com)
   * Vlad Rozov (vlad dot rozov at datatorrent dot com)
   * Atri Sharma (atri dot jiit at gmail dot com)
   * Chandni Singh (chandni at datatorrent dot com)
   * Venkatesh Sivasubramanian (venkateshs at ge dot com)
   * Aniruddha Thombare (aniruddha at datatorrent dot com)
   * Jessica Wang (jessica at datatorrent dot com)
   * Thomas Weise (thomas at datatorrent dot com)
   * David Yan (david at datatorrent dot com)
   * Kevin Yang (yang dot k at ge dot com)
   * Brennon York (brennon dot york at capitalone dot com)

== Affiliations ==
   * Apple: Vitaly Li, Rohan Mehta
   * Barclays: Atri Sharma
   * Class Software: Justin Mclean
   * CapitalOne: Ilya Ganelin, Rikin Shah, Brennon York
   * DataTorrent: everyone else on this proposal
   * DirecTV: Roma Ahuja, Sunaina Chaudhary, Dongsu Lee, Adi Mishra
   * General Electric: Cem Ezberci, Parag Goradia, Anuj Lal, Luis Ramos,
Venkatesh Sivasubramanian, Kevin Yang
   * Hortonworks: Alan Gates, Taylor Goetz, Chris Nauroth, Hitesh Shah
   * MapR: Ted Dunning
   * SilverSpring Networks: Raja Ali, Ajith Joseph, Darin Nee

== Sponsors ==

=== Champion ===
Ted Dunning

=== Nominated Mentors ===

The initial mentors are listed below:
   * Ted Dunning - Apache Member, MapR
   * Alan Gates - Apache Member, Hortonworks
   * Taylor Goetz - Apache Member, Hortonworks
   * Justin Mclean - Apache Member, Class Software
   * Chris Nauroth - Apache Member, Hortonworks
   * Hitesh Shah: Apache Member, Hortonworks

=== Sponsoring Entity ===

We would like to propose Apache incubator to sponsor this project.

Re: [DISCUSS] Apex Incubation Proposal

[Amol Kekre]

Roman,
It is a single proposal. Ted and I talked at length on this. The main
difference is the release frequency and need for Malhar to work off a
stable release of Apex. The proposal is for a single community not two, and
to share all the community aspects (emails, commiters, etc.)

Thks,
Amol



On Sun, Aug 9, 2015 at 8:18 PM, Ted Dunning  wrote:

> I had some long talks with Amol on exactly this point when he was getting
> started with this proposal.
>
> At the current time, it appears that the developer communities for these
> two systems are indistinguishable.  Moreover, neither project is actually
> much use without the other.  Malhar requires Apex to run and Apex provides
> low-level capabilities that are not particularly useful without Malhar.
> These two are even more strongly linked than, say Lucene and Solr.  Or HDFS
> and Yarn.
>
> The primary difference between these is that Malhar is expected to be
> released much more frequently than Apex as new functions are added.  Also,
> as a platform, there is much more burden on Apex to be stable, thus
> decreasing the desirable release frequency.  Over time, it is likely that
> newcomers are more likely to find it easy to contribute on the Malhar side
> initially, but the existing community is fine with keeping the committer
> pool uniform.
>
>
>
> On Sun, Aug 9, 2015 at 8:09 PM, Roman Shaposhnik 
> wrote:
>
> > I'm confused about whether this is one proposal or two
> > proposals rolled into one. On one hand it seems like
> > Apex and Malhar are independent. On the other hand
> > the proposal covers Apex in great details but not so
> > much Malhar.
> >
> > As usual with ASF, the real question here is the community
> > for the two. If we're talking about the same initial community
> > for both -- I think it makes sense to treat them as a single
> > project, not two.
> >
> > Thanks,
> > Roman.
> >
> > On Wed, Aug 5, 2015 at 5:23 PM, Amol Kekre  wrote:
> > > I would like to start a discussion on DataTorrent's core engine and its
> > > operators joining the ASF as an incubating project under the name Apex.
> > >
> > > The proposal is available on the wiki here:
> > > https://wiki.apache.org/incubator/ApexProposal
> > >
> > > The text of the proposal is also available at the end of this email
> > >
> > > Apex is an enterprise grade native YARN big data-in-motion platform
> that
> > > unifies batch and stream processing. Apex is a highly distributed,
> > > performant, fault tolerant, stateful and easily operable platform.
> > >
> > > Thanks in advance for your time and help.
> > >
> > > Thks,
> > > Amol
> > >
> > >
> >
> 
> > >
> > > == Abstract ==
> > > Apex is an enterprise grade native YARN big data-in-motion platform
> that
> > > unifies stream processing as well as batch processing. Apex processes
> big
> > > data in-motion in a highly scalable, highly performant, fault tolerant,
> > > stateful, secure, distributed, and an easily operable way. It provides
> a
> > > simple API that enables users to write or re-use generic Java code,
> > thereby
> > > lowering the expertise needed to write big data applications.
> > >
> > > Functional and operational specifications are separated. Apex is
> designed
> > > in a way to enable users to write their own code (aka user defined
> > > functions) as is and leave all operability to the platform. The API is
> > very
> > > simple and is designed to allow users to drop in their code as is. The
> > > platform mainly deals with operability and treats functional code as a
> > > black box. Operability includes fault tolerance, scalability, security,
> > > ease of use, metrics api, webservices, etc. In other words there is no
> > > separation of UDF (user defined functions), as all functional code is
> > UDF.
> > > This frees users to focus on functional development, and lets platform
> > > provide operability support. The same code runs as is with different
> > > operability attributes. The data-in-motion architecture of Apex unifies
> > > stream as well as batch processing in a single platform. Since Apex is
> a
> > > native YARN application, it leverages all the components of YARN
> without
> > > duplication. Apex was developed with YARN in mind and has no
> overlapping
> > > components/functionality with YARN.
> > >
> >

Re: [DISCUSS] Apex Incubation Proposal

[Amol Kekre]

Bertrand,
The list is indeed long. This issue was discussed within the community
after feedback from Ted. We also sought out our mentors (Alan, Chris,
Hitesh, Justin, Taylor) and others from ASF community. Under advice Apex
community came to a conclusion that it is better to engage as committers
all those who are interested, than to create a small list of initial
committers.

Do note that a big part of the list is DataTorrent engs who already are
active just as part of their job. Almost all of the rest are a sub-section
of current users who are already engaged in using DataTorrent and expressed
interest in helping the community.

Thks,
Amol

On Mon, Aug 10, 2015 at 7:12 AM, Bertrand Delacretaz  wrote:

> Hi,
>
> On Thu, Aug 6, 2015 at 2:23 AM, Amol Kekre  wrote:
> > ...I would like to start a discussion on DataTorrent's core engine and
> its
> > operators joining the ASF as an incubating project under the name
> Apex
>
> The list of initial committers is huge - do you expect so many people
> to be active on the project?
>
> It might be easier to start with a smaller list of initial committers
> and grow based on who's actually active - but there's no one size fits
> all, at this stage I'm mostly curious.
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Apex Incubation Proposal

[Amol Kekre]

Bertrand
Agreed. In incubator we will strive to achieve diversity, and inculcate
habits to reflect and do discussions on apache dev list.

Thks,
Amol


On Mon, Aug 10, 2015 at 8:25 AM, Bertrand Delacretaz  wrote:

> Hi,
>
> On Mon, Aug 10, 2015 at 5:15 PM, Amol Kekre  wrote:
> > ...Under advice Apex
> > community came to a conclusion that it is better to engage as committers
> > all those who are interested,...
>
> Ok, if that's a conscious decision made with your mentors that's fine.
>
> As you mention, a big part of initial committers are from DataTorrent,
> so to graduate it will be crucial to demonstrate inclusiveness by
> making all decisions and reflect any backchannel discussions on your
> dev list.
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Apex Incubation Proposal

[Amol Kekre]

Roman,
Malhar has much faster release frequency. We have so far managed the
discrepancy in release frequency with two repos. Malhar depends on a stable
Apex branch. Operationally we found two repos to be very efficient. Same
folks worked on both, so the coding roles are not separated. There may be
other ways of resolving this, but as Ted say it has become a matter of de
gustibus.

We are proposing that we be approved to evaluate two repos during
incubation. If it does not work well, the community can always evaluate
single repo.

Thks,
Amol


On Mon, Aug 10, 2015 at 9:57 PM, Ted Dunning  wrote:

> On Mon, Aug 10, 2015 at 8:04 PM, Roman Shaposhnik 
> wrote:
>
> > > The primary difference between these is that Malhar is expected to be
> > > released much more frequently than Apex as new functions are added.
> > Also,
> > > as a platform, there is much more burden on Apex to be stable, thus
> > > decreasing the desirable release frequency.  Over time, it is likely
> that
> > > newcomers are more likely to find it easy to contribute on the Malhar
> > side
> > > initially, but the existing community is fine with keeping the
> committer
> > > pool uniform.
> >
> > Ok, that makes sense, but it also leads to the next question. With such
> > tight integration why ask for different JIRAs for the two projects and
> two
> > different repos? Keeping with your HDFS/YARN analogy, say what you
> > will, but part of the reason Hadoop was able to innovate so quickly
> > was that those were part of the same project.
>
>
> I argued against the dual repository, but the project contributors
> apparently had a strong opinion about that.
>
> This will have nothing to do with whether the two systems are part of the
> same project. They will still be synchronized.
>
> In the end, it seemed a matter of de gustibus.
>

Re: [DISCUSS] Apex Incubation Proposal

[Amol Kekre]

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

Re: [DISCUSS] Apex Incubation Proposal

[Amol Kekre]

Bertrand,
Good point. I will take it up with folks and get back soon.

Thks
Amol

On Tue, Aug 11, 2015 at 2:32 AM, Bertrand Delacretaz  wrote:

> On Tue, Aug 11, 2015 at 5:04 AM, Roman Shaposhnik 
> wrote:
> > ...With such
> > tight integration why ask for different JIRAs for the two projects and
> two
> > different repos?...
>
> I don't have a problem with asking for multiple Git repositories but
> their names should share a common prefix to express that they belong
> to the same PMC.
>
> So instead of incubator-apex.git and incubator-malhar.git I would much
> prefer
>
>   incubator-apex-core.git
>   incubator-apex-malhar.git
>
> Or something like that, dunno if "core" makes sense.
>
> As for JIRA, I would apply the same rule, so APX-CORE and APX-MHAR maybe.
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [DISCUSS] Apex Incubation Proposal

[Amol Kekre]

Bertrand,
We discussed your suggesstion on naming the git repos as follows. There was
a consensus on using git repos scoped with apex.

incubator-apex-core.git
incubator-apex-malhar.git

I have changed the names on the wiki as per your suggesstion. I will cover
your suggesstion of jira projects name in another reply.

Thks,
Amol


On Tue, Aug 11, 2015 at 8:28 AM, Amol Kekre  wrote:

>
> Bertrand,
> Good point. I will take it up with folks and get back soon.
>
> Thks
> Amol
>
> On Tue, Aug 11, 2015 at 2:32 AM, Bertrand Delacretaz <
> bdelacre...@apache.org> wrote:
>
>> On Tue, Aug 11, 2015 at 5:04 AM, Roman Shaposhnik 
>> wrote:
>> > ...With such
>> > tight integration why ask for different JIRAs for the two projects and
>> two
>> > different repos?...
>>
>> I don't have a problem with asking for multiple Git repositories but
>> their names should share a common prefix to express that they belong
>> to the same PMC.
>>
>> So instead of incubator-apex.git and incubator-malhar.git I would much
>> prefer
>>
>>   incubator-apex-core.git
>>   incubator-apex-malhar.git
>>
>> Or something like that, dunno if "core" makes sense.
>>
>> As for JIRA, I would apply the same rule, so APX-CORE and APX-MHAR maybe.
>>
>> -Bertrand
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>

Re: [DISCUSS] Apex Incubation Proposal

[Amol Kekre]

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

Re: [DISCUSS] Apex Incubation Proposal

[Amol Kekre]

oh! We preferred that during our discussion. Somehow we thought there was a
limit. I have changed it to full names (APEX-CORE, APEX-MALHAR). If there
is a limit we can reduce the number of chars later. wiki is updated.

https://wiki.apache.org/incubator/ApexProposal

Thks,
Amol


On Tue, Aug 11, 2015 at 1:44 PM, Hitesh Shah  wrote:

> 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 <
> cnaur...@hortonworks.com>
> > 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 <
> bdelacre...@apache.org
> >>>
> >>>> 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: [DISCUSS] Apex Incubation Proposal

[Amol Kekre]

Niall,
Thanks for catching. I replaced '-' with '_' as per atlassian policy. I am
suspecting that ASF does not allow '_' as none of the project keys have
'_'. I have added a comment that '_' can be removed if that is the policy.
Wiki updated.

Thks,
Amol


On Tue, Aug 11, 2015 at 7:46 PM, Niall Pemberton 
wrote:

> On Wed, Aug 12, 2015 at 2:08 AM, Amol Kekre  wrote:
>
> > oh! We preferred that during our discussion. Somehow we thought there
> was a
> > limit. I have changed it to full names (APEX-CORE, APEX-MALHAR). If there
> > is a limit we can reduce the number of chars later. wiki is updated.
> >
> > https://wiki.apache.org/incubator/ApexProposal
> >
>
> Hyphens are not allowed as project keys, but underscore is a possibility.
> The default format is only upper case letters - but you'll need to check
> what ASF has configured.
>
>
> https://confluence.atlassian.com/display/JIRA/Changing+the+Project+Key+Format
>
> Niall
>
>
> Thks,
> > Amol
> >
> >
> > On Tue, Aug 11, 2015 at 1:44 PM, Hitesh Shah  wrote:
> >
> > > 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 <
> > > cnaur...@hortonworks.com>
> > > > 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 <
> ted.dunn...@gmail.com>
> > > >>> 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 <
> > > bdelacre...@apache.org
> > > >>>
> > > >>>> 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: [DISCUSS] Apex Incubation Proposal

[Amol Kekre]

Rod,
We did consider prefixed versions. We also understand and agree that
technically prefix works. There is discomfort among us with regards to
using prefixes. Based on community discussions, I prefer to keep the ask
for separate jiras. If during incubation approval, this becomes a blocker,
we will reconsider the ask for separate jiras.

Thks,
Amol


On Wed, Aug 12, 2015 at 2:15 AM, Rob Vesse  wrote:

> Not really an issue
>
> JIRA allows a lot of flexibility in the configuration of Versions (I.e.
> the version strings are free text) so you could easily have "Apex x.y.z"
> and "Malhar x.y.z" as separate versions under a single JIRA key.  It just
> needs the community managing the JIRA to be careful about ensuring issues
> are tagged with the correct Affects and Fix Versions as necessary
>
> We've used this workflow for years in the Jena project and not had an
> issue with it.
>
> Of course the community may prefer to have separate JIRA keys as appears
> to be the case here in which case I see no reason not to allow them that
> and there are other precedents for that (e.g. Apache Commons)
>
> Rob
>
> On 11/08/2015 18:03, "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

[Amol Kekre]

   * 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)
>* Munagala Ramanath (ram at datatorrent dot com)
>* Vlad Rozov (vlad dot rozov at datatorrent dot com)
>* Atri Sharma (atri dot jiit at gmail dot com)
>* Chandni Singh (chandni at datatorrent dot com)
>* Venkatesh Sivasubramanian (venkateshs at ge dot com)
>* Aniruddha Thombare (aniruddha at datatorrent dot com)
>* Jessica Wang (jessica at datatorrent dot com)
>* Thomas Weise (thomas at datatorrent dot com)
>* David Yan (david at datatorrent dot com)
>* Kevin Yang (yang dot k at ge dot com)
>* Brennon York (brennon dot york at capitalone dot com)
>
> == Affiliations ==
>* Apple: Vitaly Li, Rohan Mehta
>* Barclays: Atri Sharma
>* Class Software: Justin Mclean
>* CapitalOne: Ilya Ganelin, Brennon York
>* DataTorrent: everyone else on this proposal
>* Datachief: Rikin Shah
>* DirecTV: Roma Ahuja, Sunaina Chaudhary, Dongsu Lee, Adi Mishra
>* E8security: Vitthal Gogate
>* General Electric: Cem Ezberci, Parag Goradia, Anuj Lal, Luis Ramos,
> Venkatesh Sivasubramanian, Kevin Yang
>* Hortonworks: Alan Gates, Taylor Goetz, Chris Nauroth, Hitesh Shah
>* MapR: Ted Dunning
>* SilverSpring Networks: Raja Ali, Ajith Joseph, Darin Nee
>
> == Sponsors ==
>
> === Champion ===
> Ted Dunning
>
> === Nominated Mentors ===
>
> The initial mentors are listed below:
>* Ted Dunning - Apache Member, MapR
>* Alan Gates - Apache Member, Hortonworks
>* Taylor Goetz - Apache Member, Hortonworks
>* Justin Mclean - Apache Member, Class Software
>* Chris Nauroth - Apache Member, Hortonworks
>* Hitesh Shah: Apache Member, Hortonworks
>
> === Sponsoring Entity ===
>
> We would like to propose Apache incubator to sponsor this project.
>
>

Re: [DISCUSS] Apex Incubation Proposal

[Amol Kekre]

Niall,
Thanks for following up and resolving the ask. We will remove '_' from the
keys.

Thks,
Amol


On Fri, Aug 14, 2015 at 1:03 PM, Niall Pemberton 
wrote:

> On Wed, Aug 12, 2015 at 3:55 AM, Amol Kekre  wrote:
>
> > Niall,
> > Thanks for catching. I replaced '-' with '_' as per atlassian policy. I
> am
> > suspecting that ASF does not allow '_' as none of the project keys have
> > '_'. I have added a comment that '_' can be removed if that is the
> policy.
> > Wiki updated.
> >
>
> I asked on the infra list what the JIRA key format was and whether it could
> be changed to include underscore and got the following response:
>
> "They are all uppercase alpha characters. Sadly it cannot be changed."
>
> Niall
>
>
>
> >
> > Thks,
> > Amol
> >
> >
> > On Tue, Aug 11, 2015 at 7:46 PM, Niall Pemberton <
> > niall.pember...@gmail.com>
> > wrote:
> >
> > > On Wed, Aug 12, 2015 at 2:08 AM, Amol Kekre 
> > wrote:
> > >
> > > > oh! We preferred that during our discussion. Somehow we thought there
> > > was a
> > > > limit. I have changed it to full names (APEX-CORE, APEX-MALHAR). If
> > there
> > > > is a limit we can reduce the number of chars later. wiki is updated.
> > > >
> > > > https://wiki.apache.org/incubator/ApexProposal
> > > >
> > >
> > > Hyphens are not allowed as project keys, but underscore is a
> possibility.
> > > The default format is only upper case letters - but you'll need to
> check
> > > what ASF has configured.
> > >
> > >
> > >
> >
> https://confluence.atlassian.com/display/JIRA/Changing+the+Project+Key+Format
> > >
> > > Niall
> > >
> > >
> > > Thks,
> > > > Amol
> > > >
> > > >
> > > > On Tue, Aug 11, 2015 at 1:44 PM, Hitesh Shah 
> > wrote:
> > > >
> > > > > 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 <
> > > > > cnaur...@hortonworks.com>
> > > > > > 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 accidental

Re: [DISCUSS] Apex Incubation Proposal

[Amol Kekre]

Taylor,
Got it. I am learning incubation nuances :)

Thks,
Amol


On Fri, Aug 14, 2015 at 2:11 PM, P. Taylor Goetz  wrote:

> Amol,
>
> I don't think there's a need to update the proposal for this, it's an
> implementation detail that can be dealt with upon entry. The proposal
> should be treated as immutable while the vote is underway (which is why
> proposals are always attached to the VOTE -- so people know exactly what
> they are voting on).
>
> In the (seemingly unlikely) event that the vote doesn't pass, the proposal
> can be revisited.
>
> Just an FYI...
>
> -Taylor
>
> > On Aug 14, 2015, at 4:49 PM, Amol Kekre  wrote:
> >
> > Niall,
> > Thanks for following up and resolving the ask. We will remove '_' from
> the
> > keys.
> >
> > Thks,
> > Amol
> >
> >
> > On Fri, Aug 14, 2015 at 1:03 PM, Niall Pemberton <
> niall.pember...@gmail.com>
> > wrote:
> >
> >>> On Wed, Aug 12, 2015 at 3:55 AM, Amol Kekre 
> wrote:
> >>>
> >>> Niall,
> >>> Thanks for catching. I replaced '-' with '_' as per atlassian policy. I
> >> am
> >>> suspecting that ASF does not allow '_' as none of the project keys have
> >>> '_'. I have added a comment that '_' can be removed if that is the
> >> policy.
> >>> Wiki updated.
> >>>
> >>
> >> I asked on the infra list what the JIRA key format was and whether it
> could
> >> be changed to include underscore and got the following response:
> >>
> >> "They are all uppercase alpha characters. Sadly it cannot be changed."
> >>
> >> Niall
> >>
> >>
> >>
> >>>
> >>> Thks,
> >>> Amol
> >>>
> >>>
> >>> On Tue, Aug 11, 2015 at 7:46 PM, Niall Pemberton <
> >>> niall.pember...@gmail.com>
> >>> wrote:
> >>>
> >>>> On Wed, Aug 12, 2015 at 2:08 AM, Amol Kekre 
> >>> wrote:
> >>>>
> >>>>> oh! We preferred that during our discussion. Somehow we thought there
> >>>> was a
> >>>>> limit. I have changed it to full names (APEX-CORE, APEX-MALHAR). If
> >>> there
> >>>>> is a limit we can reduce the number of chars later. wiki is updated.
> >>>>>
> >>>>> https://wiki.apache.org/incubator/ApexProposal
> >>>>>
> >>>>
> >>>> Hyphens are not allowed as project keys, but underscore is a
> >> possibility.
> >>>> The default format is only upper case letters - but you'll need to
> >> check
> >>>> what ASF has configured.
> >>>>
> >>>>
> >>>>
> >>>
> >>
> https://confluence.atlassian.com/display/JIRA/Changing+the+Project+Key+Format
> >>>>
> >>>> Niall
> >>>>
> >>>>
> >>>> Thks,
> >>>>> Amol
> >>>>>
> >>>>>
> >>>>> On Tue, Aug 11, 2015 at 1:44 PM, Hitesh Shah 
> >>> wrote:
> >>>>>
> >>>>>> 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

Re: [VOTE] Accept HAWQ into the Apache Incubator

[Amol Kekre]

+1 (non-binding)

Amol


On Mon, Aug 31, 2015 at 3:03 PM, Justin Mclean  wrote:

> +1 (binding)
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Graduate Calcite from the Apache Incubator

[Amol Kekre]

+1 (non-binding)

Thks
Amol

On Tue, Sep 15, 2015 at 2:22 PM, Seetharam Venkatesh <
venkat...@innerzeal.com> wrote:

> +1.
>
> Thanks,
> Venkatesh
>
> On Tue, Sep 15, 2015 at 2:16 PM Henry Saputra 
> wrote:
>
> > +1
> >
> > Good job guys
> >
> > On Mon, 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 Concerted into the Apache Incubator

[Amol Kekre]

+1 (non-binding)

Amol


On Fri, Oct 9, 2015 at 8:55 AM, Atri Sharma  wrote:

> Hi all,
>
> Following the discussion about Concerted I would like to call a vote for
> accepting Concerted as a new incubator project.
>
> The proposal text is included below, and available on the wiki:
>
> https://wiki.apache.org/incubator/ConcertedProposal
>
> The vote is open for 72 hours:
>
> [ ] +1 accept Concerted in the Incubator
> [ ] ±0
> [ ] -1 (please give reason)
>
> Regards,
>
> Atri
>
> = Abstract =
>
> Concerted is an in memory write less read more engine aimed to provide
> extreme read performance with very high degree of concurrency and
> scalability and focus on minimizing own resource footprint.
>
> = Proposal =
> Concerted is built on the principal that a new type of workload is
> dominating the scene and is now needed to be supported. These are the large
> data set analytical workloads being analyzed or used on large clusters or
> high power machines. Large analytical workloads depend on the ability to
> query large data sets efficiently and in high concurrency while maintaining
> semantics such as immediate consistency. An in memory engine designed to
> support extreme read queries while providing support for aggregation
> through various features (such as multidimensional representation of
> tuples) will accelerate many usecases around large scale analytics.
>
> Concerted believes that best understanding of user application lies with
> user application developer. The need for massive read scaling should be on
> demand and should be flexible to the level that user can decide as to which
> representation and access of data suits his/her current requirements.
> Hence, Concerted is not built in a traditional client/server model.
> Concerted provides users with an API which can be used to load, read,
> update and delete data. User chooses which data structure has to be used
> for his current requirements. All API access is covered by Concerted's
> internal systems like lock manager, transaction manager and cache manager
> which ensure that reads scale to high level in every API call.
>
> Concerted is a Do It Yourself in memory platform for making in memory
> supporting engines. The use case we think of is supporting big data
> warehouses like Hive, but there are endless use cases for a custom, highly
> scalable in memory platform.
>
> The goal of this proposal is to leverage an existing code base available on
> Github and licensed under the Apache License 2.0 to build a community
> around the project. Currently the community consists of existing hackers of
> Concerted as well as people who have been following and associated with the
> project since a while as well as database experts who are excited about
> building a project like this. We are hoping that entering into Apache would
> help us attract more contributors as well as connect with existing big data
> projects like Apache Hive, Apache HAWQ, Apache Storm, Apache Tajo, Apache
> Spark, Apache Geode to leverage their community base while assisting in
> their use cases with Concerted. We had a discussion with founders of Apache
> Tajo and they showed interest in using Concerted for some of their use
> cases.
> = Background =
> Relational databases were built with the cost of physical memory in mind.
> The cost is no longer very relevant and physical memory is now available on
> demand. Another driving factor behind Concerted is that there is a paradigm
> shift with big data coming into picture. Disk IO speeds are more of a
> bottleneck than ever before. Combining the read dominance of analytical
> workload with the speed of in memory structures, Concerted fits the current
> scene. Also, supporting OLAP workloads with in memory support for faster
> read constant queries and joins will be useful.
>
> = Rationale =
> As explained above, large analytical workloads need an in memory
> lightweight engine which supports massive read concurrency, ground level
> support for aggregations and analytics, extreme scalability and high read
> performance, along with the engine being very light itself. Concerted aims
> to solve these needs. Concerted is designed and built with three goals as
> objectives:
>
>
> Performance
> To provide high performance access to data from a large number of rows,
> Concerted uses efficient representation and in memory indexing of data
> coupled with high performance transactions, custom transactions and
> lightweight locking and lockless techniques and an intelligent locking
> manager.
>
> Scalability
> Concerted is built with extreme concurrency and scalability in mind.
>
> Efficiency
> Concerted aims to give expected performance under vast variety of
> workloads and aims to have as low footprint as possible.
>
> = Initial Goals =
> The initial goal is to leverage an existing code base and invest in
> building a community around the project. We anticipate a lot of initial
> restructuring of the existing code so that it becomes

Re: [IP Clearance] Alibaba JStorm

[Amol Kekre]

+1 (non-binding)

Amol


On Thu, Oct 22, 2015 at 1:13 PM, P. Taylor Goetz  wrote:

> Apache Storm has received a code donation for Alibaba JStorm:
>
> http://incubator.apache.org/ip-clearance/storm-jstorm.html
>
> The source code can be found at https://github.com/alibaba/jstorm with
> the following git commit SHA: e935da91a897797dad56e24c4ffa57860ac91878
>
> Please vote to approve this contribution. Lazy consensus applies. If no -1
> votes are cast within the next 72 hours, the vote passes.
>
> Regards,
>
> -Taylor
>

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

[Amol Kekre]

+1 (binding) // already voted on PPMC

Thks
Amol

On Tue, 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
>

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

[Amol Kekre]

+1 (non-binding)

I too am carrying over vote from dev. Did my testing too.

Thks
Amol

On Sat, Nov 14, 2015 at 1:42 PM, Justin Mclean  wrote:

> Hi,
>
> +1 (binding)
>
> Carry over vote from dev list, didi all of the usual checks.
>
> Thanks,
> Justin
>
> -
> 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

[Amol Kekre]

+1 (non-binding)

Amol


On Wed, Nov 25, 2015 at 12:44 AM, Tom White  wrote:

> +1 (binding)
>
> Tom
>
> On Tue, Nov 24, 2015 at 9: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 patche

Re: [VOTE] Accept Kudu into the Apache Incubator

[Amol Kekre]

+1 (non-binding)

Amol


On Wed, Nov 25, 2015 at 3:19 AM, Roman Shaposhnik  wrote:

> On Tue, 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)
>
> +1 (binding)
>
> Bets of luck guys!
>
> Thanks,
> Roman.
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Accept Metron into Apache Incubator

[Amol Kekre]

+1 (non-binding)

Amol


On Fri, Dec 4, 2015 at 8:02 AM, Ryan Merriman 
wrote:

> +1 (non-binding)
>
>
> On 12/4/15, 10:00 AM, "james sirota" 
> wrote:
>
> >+1 (non-binding)
> >  From: Billie Rinaldi 
> > To: general@incubator.apache.org
> > Sent: Friday, December 4, 2015 8:06 AM
> > Subject: Re: [VOTE] Accept Metron into Apache Incubator
> >
> >+1 (binding)
> >
> >On Thu, Dec 3, 2015 at 12:33 PM, Owen O'Malley 
> wrote:
> >> The [DISCUSS] thread has would down, so I'd like to start a VOTE on
> >whether
> >> Apache Incubator should accept Metron as a podling. The proposal is
> >>pasted
> >> below and is available on the wiki as well.
> >>
> >> https://wiki.apache.org/incubator/MetronProposal
> >>
> >> We've added a paragraph in the background section discussing how Apache
> >> avoids hostile forks of projects, because we don't want to fork
> >> communities. We've also added Larry McCay, P. Taylor Goetz, and Phillip
> >> Rhodes to the proposal.
> >>
> >> The vote will run until 12pm PST on Sunday.
> >>
> >> Thanks,
> >>Owen
> >
> >
> >
>
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Accept the iota project into the Apache Incubator

[Amol Kekre]

+1 (non-binding)

Thks
Amol

On Sun, Jan 17, 2016 at 10:47 PM, Naresh Agarwal 
wrote:

> +1 (non-binding)
>
> Thanks
> Naresh Agarwal
>
> On Mon, Jan 18, 2016 at 12:00 PM, Bruno Mahé  wrote:
>
> > +1 (non-binding)
> >
> > On 01/16/2016 12:12 PM, Hadrian Zbarcea wrote:
> >
> >> Hi,
> >>
> >> The iota proposal [1] (initially Tempo) was proposed about 6 weeks ago.
> >>
> >> Because of the naming conflict that would have likely required to change
> >> name at graduation, the project name was changed to "Apache iota" (the
> >> greek letter), which resonates better with the IoT field the project
> >> targets and passed a summary podling name search.
> >>
> >> The code was made available in December for our review and answers on
> the
> >> general@ list have been answered.
> >>
> >> We think it's time to move to the next step, a formal vote. Therefore...
> >>
> >> Please cast your vote to:
> >> [] +1 - accept Apache iota as a new incubating project
> >> []  0 - not sure
> >> [] -1 - do not accept the Apache iota project (because: ...)
> >>
> >> Thanks,
> >> Hadrian
> >>
> >>
> >> [1] https://wiki.apache.org/incubator/IotaProposal
> >> [2] https://en.wikipedia.org/wiki/Iota
> >>
> >>
> >> -
> >>
> >> iota Proposal
> >>
> >> Abstract
> >>
> >> The Apache Foundation has been very successful in bringing together key
> >> software components that have enabled people to interact with each other
> >> via a variety of content platforms and it will no doubt continue to do
> so.
> >> At the same time modern society is becoming increasingly dependent on
> >> devices that interact with each other and with people. The amount of
> data
> >> that will be produced by devices will be orders of magnitude greater
> than
> >> what has been produced by humans in the past. In addition, the
> >> orchestration of devices and people will be an important area of growth
> for
> >> the foreseeable future. This new dynamic will eventually become
> manifest in
> >> a growing number of Apache projects that enable this to occur. Our wish
> is
> >> to contribute to this movement by contributing the iota system to the
> Open
> >> Source Community via the Apache Foundation. Apache iota is an open
> platform
> >> to interconnect any and all devices, sensors, people, and applications,
> >> henceforth referred to as points, through a scalable, secure, and
> modular
> >> architecture, enabling applications to generate analysis, create actions
> >> and/or add intelligence to their behaviors and patterns.
> >>
> >> Proposal
> >>
> >> Perhaps you are a homeowner configuring the interaction between your
> >> family and all the smart devices in your home. Or you might be a global
> >> company orchestrating millions of devices and people across different
> >> continents. Either way you face the same fundamental problem; namely,
> how
> >> do you manage many points in a secure robust and meaningful manner?
> Apache
> >> iota is an open source software system that enables homeowners and
> global
> >> companies to download a software system that provides secure and robust
> >> orchestration.
> >>
> >> The iota system consists of a variety of components:
> >>
> >> A basic but extensible desktop
> >> An extensible mechanism for capturing data from a variety of sources
> >> A set of translators that feed the data capture mechanism and a
> framework
> >> for the development of additional translators
> >> A secure means of moving data using digital envelopes based on symmetric
> >> and asymmetric encryption and decryption via Apache Kafka
> >> Optionally maintaining data encrypted in a datastore
> >> Support for a variety of data repositories
> >> Authentication and authorization using OAuth2
> >> Secure APIs for access to data and the system information
> >> User management
> >> Device management
> >> Automated software upgrades via Salt
> >> Configuration management
> >> Robust basic infrastructure based on Apache Mesos that enables
> scalability
> >> Dockerized applications
> >> Background
> >>
> >> We are in the midst of a revolution in which the Internet of Things
> (IoT)
> >> is poised to impact the development of our society in ways we can not
> even
> >> begin to imagine. Unfortunately, we know of no coherent OSS (Open Source
> >> Software) solution that can harness the potentialities of this
> increasingly
> >> important trend. Manufacturers of IoT devices, both in the consumer and
> >> industrial spaces, continue to develop proprietary systems. Apache iota
> is
> >> an open source IoT system that creates an open source solution enabling
> the
> >> orchestration of IoT devices that brings the benefits of OSS to this
> space.
> >> Apache iota was initially developed by Litbit and is deployed in a
> growing
> >> number of Industrial contexts, especially in the context of Data Center
> >> Infrastructure.
> >>
> >> Rationale
> >>
> >> Apache iota is a general platform for orchestrating IoT devices in both
> >> consumer and industrial contex

Re: [DISCUSS] Druid incubation proposal

[Amol Kekre]

+1. Great to see Druid joining ASF.


Thks,
Amol



E:a...@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre*

www.datatorrent.com


On Thu, Feb 22, 2018 at 8:57 AM, Brian McCallister  wrote:

> +1 - glad to see Druid finally (hopefully) landing here!
>
> On Wed, Feb 21, 2018 at 10:57 PM, Henning Schmiedehausen <
> henn...@schmiedehausen.org> wrote:
>
> > Woot!
> >
> > +1 for druid incubation.
> >
> > -h
> >
> >
> >
> > On Fri, Feb 16, 2018 at 12:15 PM, Gian Merlino  wrote:
> >
> > > Hi all,
> > >
> > > I would like to open up a discussion about incubating Druid at Apache.
> > I've
> > > included a proposal in this mail and have also posted a draft at
> > > https://wiki.apache.org/incubator/DruidProposal. More information
> about
> > > Druid is also available on our project web site at: http://druid.io/
> > >
> > > Thanks for your consideration!
> > >
> > > Gian
> > >
> > > = Druid Proposal =
> > >
> > > == Abstract ==
> > >
> > > Druid is a high-performance, column-oriented, distributed data store.
> > >
> > > == Proposal ==
> > >
> > > Druid is an open source data store designed for real-time exploratory
> > > analytics on large data sets. Druid's key features are a
> column-oriented
> > > storage layout, a distributed shared-nothing architecture, and ability
> to
> > > generate and leverage indexing and caching structures. Druid is
> typically
> > > deployed in clusters of tens to hundreds of nodes, and has the ability
> to
> > > load data from Apache Kafka and Apache Hadoop, among other data
> sources.
> > > Druid offers two query languages: a SQL dialect (powered by Apache
> > Calcite)
> > > and a JSON-over-HTTP API.
> > >
> > > Druid was originally developed to power a slice-and-dice analytical UI
> > > built on top of large event streams. The original use case for Druid
> > > targeted ingest rates of millions of records/sec, retention of over a
> > year
> > > of data, and query latencies of sub-second to a few seconds. Many
> people
> > > can benefit from such capability, and many already have (see
> > > http://druid.io/druid-powered.html). In addition, new use cases have
> > > emerged since Druid's original development, such as OLAP acceleration
> of
> > > data warehouse tables and more highly concurrent applications operating
> > > with relatively narrower queries.
> > >
> > > == Background ==
> > >
> > > Druid is a data store designed for fast analytics. It would typically
> be
> > > used in lieu of more general purpose query systems like Hadoop
> !MapReduce
> > > or Spark when query latency is of the utmost importance. Druid is often
> > > used as a data store for powering GUI analytical applications.
> > >
> > > The buzzwordy description of Druid is a high-performance,
> > column-oriented,
> > > distributed data store. What we mean by this is:
> > >
> > >  * "high performance": Druid aims to provide low query latency and high
> > > ingest rates possible.
> > >  * "column-oriented": Druid stores data in a column-oriented format,
> like
> > > most other systems designed for analytics. It can also store indexes
> > along
> > > with the columns.
> > >  * "distributed": Druid is deployed in clusters, typically of tens to
> > > hundreds of nodes.
> > >  * "data store": Druid loads your data and stores a copy of it on the
> > > cluster's local disks (and may cache it in memory). It doesn't query
> your
> > > data from some other storage system.
> > >
> > > == Rationale ==
> > >
> > > Druid is a mature, active project with a large number of production
> > > installations, dozens of contributors to each release, and multiple
> > vendors
> > > offering professional support. Given Druid's strong community, its
> close
> > > integration with many other Apache projects (such as Kafka, Hadoop, and
> > > Calcite), and its pre-existing Apache-inspired governance structure, we
> > > feel that Apache is the best home for the project on a long-term basis.
> > >
> > > == Current Status ==
> > >
> > > === Meritocracy ===
> > > Since Druid was first open sourced the original developers have
> solicited
> > > contributions from others, including through our blog, the project
> > mailing
> > > lists, and through accepting !GitHub pull requests. We have an
> > > Apache-inspired governance structure with a PMC and committers, and our
> > > committer ranks include a good number of people from outside the
> original
> > > development team.
> > >
> > > === Community ===
> > >
> > > The Druid core developers have sought to nurture a community throughout
> > the
> > > life of the project. We use !GitHub as the focal point for bug reports
> > and
> > > code contributions, and the mailing lists for most other discussion. To
> > try
> > > to make people feel welcome, we've also spelled this out on a
> > "CONTRIBUTE"
> > > link from the project page: http://druid.io/community/. Today we have
> an
> > > active contributor base (a typical release has ~40 contributors) and
> > > mailing list.
> > >
> > > === Core Developers

Re: [VOTE] Accept Druid into the Apache Incubator

[Amol Kekre]

+1 (non-binding)

Thks,
Amol


E:a...@datatorrent.com | M: 510-449-2606 | Twitter: @*amolhkekre*

www.datatorrent.com


On Thu, Feb 22, 2018 at 11:05 AM, Chris Mattmann 
wrote:

> +1 binding.
>
> Thanks,
> Chris
>
>
>
> On 2/22/18, 11:04 AM, "Julian Hyde"  wrote:
>
> Hi all,
>
> After some discussion on the Druid proposal[1], I'd like to
> start a vote on accepting Druid into the Apache Incubator,
> per the ASF policy[2] and voting rules[3].
>
> A vote for accepting a new Apache Incubator podling is a
> majority vote for which only Incubator PMC member votes are
> binding. Votes from other people are also welcome as an
> indication of people's enthusiasm (or lack thereof).
>
> Please do not use this VOTE thread for discussions.  If
> needed, start a new thread instead.
>
> This vote will run for at least 72 hours. Please VOTE as
> follows:
>  [ ] +1 Accept Druid into the Apache Incubator
>  [ ] +0 Abstain
>  [ ] -1 Do not accept Druid into the Apache Incubator
> because ...
>
> The proposal is listed below, but you can also access it on
> the wiki[4].
>
> Julian
>
> [1] https://lists.apache.org/thread.html/
> b95f90a30b6e8587e9b108f368b07c1b3e23e25ca592448d9c9f81e2@%
> 3Cgeneral.incubator.apache.org%3E
>
> [2] https://incubator.apache.org/policy/incubation.html#
> approval_of_proposal_by_sponsor
>
> [3] http://www.apache.org/foundation/voting.html
>
> [4] https://wiki.apache.org/incubator/DruidProposal
>
>
>
>
>
> = Druid Proposal =
>
> == Abstract ==
>
> Druid is a high-performance, column-oriented, distributed
> data store.
>
> == Proposal ==
>
> Druid is an open source data store designed for real-time
> exploratory analytics on large data sets. Druid's key
> features are a column-oriented storage layout, a distributed
> shared-nothing architecture, and ability to generate and
> leverage indexing and caching structures. Druid is typically
> deployed in clusters of tens to hundreds of nodes, and has
> the ability to load data from Apache Kafka and Apache
> Hadoop, among other data sources. Druid offers two query
> languages: a SQL dialect (powered by Apache Calcite) and a
> JSON-over-HTTP API.
>
> Druid was originally developed to power a slice-and-dice
> analytical UI built on top of large event streams. The
> original use case for Druid targeted ingest rates of
> millions of records/sec, retention of over a year of data,
> and query latencies of sub-second to a few seconds. Many
> people can benefit from such capability, and many already
> have (see http://druid.io/druid-powered.html). In addition,
> new use cases have emerged since Druid's original
> development, such as OLAP acceleration of data warehouse
> tables and more highly concurrent applications operating
> with relatively narrower queries.
>
> == Background ==
>
> Druid is a data store designed for fast analytics. It would
> typically be used in lieu of more general purpose query
> systems like Hadoop MapReduce or Spark when query latency is
> of the utmost importance. Druid is often used as a data
> store for powering GUI analytical applications.
>
> The buzzwordy description of Druid is a high-performance,
> column-oriented, distributed data store. What we mean by
> this is:
>
> * "high performance": Druid aims to provide low query
>   latency and high ingest rates possible.
> * "column-oriented": Druid stores data in a column-oriented
>   format, like most other systems designed for analytics. It
>   can also store indexes along with the columns.
> * "distributed": Druid is deployed in clusters, typically of
>   tens to hundreds of nodes.
> * "data store": Druid loads your data and stores a copy of
>   it on the cluster's local disks (and may cache it in
>   memory). It doesn't query your data from some other
>   storage system.
>
> == Rationale ==
>
> Druid is a mature, active project with a large number of
> production installations, dozens of contributors to each
> release, and multiple vendors offering professional
> support. Given Druid's strong community, its close
> integration with many other Apache projects (such as Kafka,
> Hadoop, and Calcite), and its pre-existing Apache-inspired
> governance structure, we feel that Apache is the best home
> for the project on a long-term basis.
>
> == Current Status ==
>
> === Meritocracy ===
>
> Since Druid was first open sourced the original developers
> have solicited contributions from others, including through
> our blog, the project mailing lists, and through accepting
> GitHub pull requests. We have an Apache-inspired governance
> structure with a PMC and committers, and our committer ranks
> include a good number of people from outside th