This vote is now closed and passes with 15 binding +1 votes, 9 non-binding +1 
votes and not 0 or -1 votes.

Vote tally (* indicates a binding vote):

+1:
Pramod Immaneni
Chris Nauroth*
Gaurav Gupta
Julian Hyde*
Seetharam Venkatesh
Hitesh Shah*
Ted Dunning*
Alan Gates*
P. Taylor Goetz*
Henry Saputra*
Ashwin Chandra Putta
David Yan
John D. Ament*
Amol Kekre
Luke Han
Atri Sharma
Chris Douglas*
Justin Mclean*
Naresh Agarwal
Bertrand Delacretaz*
Jan Iversen*
Amareshwari Sriramdasu*
Roman Shaposhnik*
Niall Pemberton*

0:
-none-

-1:
-none-

Thank you to all who voted.

-Taylor



> On Aug 13, 2015, at 10:48 AM, P. Taylor Goetz <ptgo...@apache.org> wrote:
> 
> Following the discussion thread [1], I would like to call a VOTE for 
> Accepting Apex as a new Apache Incubator project.
> 
> The proposal is available on the wiki [2] and is also attached below.
> 
> The VOTE will be open for at least 72 hours.
> 
> [ ] +1 Accept Apex into the Incubator
> [ ] ±0 No opinion
> [ ] -1 Do not accept Apex into the Incubator because…
> 
> Thanks,
> 
> -Taylor
> 
> [1] http://s.apache.org/apex_discuss <http://s.apache.org/apex_discuss>
> [2] https://wiki.apache.org/incubator/ApexProposal 
> <https://wiki.apache.org/incubator/ApexProposal>
> 
> 
> == 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.
> 
> The Apex platform is supplemented by project Malhar, which is a library of 
> operators that implement common business logic functions needed by customers 
> who want to quickly develop applications. These operators provide access to 
> HDFS, S3, NFS, FTP, and other file systems;  Kafka, ActiveMQ, RabbitMQ, JMS, 
> and other message systems; MySql, Cassandra, MongoDB, Redis, HBase, CouchDB 
> and other databases along with JDBC connectors. The Malhar library also 
> includes a host of other common business logic patterns that help users to 
> significantly reduce the time it takes to go into production. Ease of 
> integration with all other big data technologies is one of the primary 
> missions of Malhar.
> 
> == Proposal ==
> The goal of this proposal is to establish the core engine of DataTorrent RTS 
> product as an Apache Software Foundation (ASF) project in order to build a 
> vibrant, diverse, and self-governed open source community around the 
> technology. DataTorrent will continue to sell management tools, application 
> building tools, easy to use big data applications, and custom high end 
> business logic operators. This proposal covers the Apex source code (written 
> in Java), Apex documentation and other materials currently available on 
> https://github.com/DataTorrent/Apex <https://github.com/DataTorrent/Apex>. 
> This proposal also covers the Malhar source code (written in Java), Malhar 
> documentation, and other materials currently available on 
> https://github.com/DataTorrent/Malhar 
> <https://github.com/DataTorrent/Malhar>. We have done a trademark check on 
> the name Apex, and have concluded that the Apex name is likely to be a 
> suitable project name.
> 
> == Background ==
> DataTorrent RTS is a mature and robust product developed as a native YARN 
> application. RTS 1.0 was launched in summer of 2014; RTS 2.0 was launched in 
> Jan 2015. Both were well received by customers. RTS 3.0 was launched at end 
> of July 2015. RTS is among the first enterprise grade platform that was 
> developed from the ground up as native YARN application. DataTorrent RTS is 
> currently maintained by engineers as a closed source project. Even though the 
> engineers behind RTS are experienced software engineers and are knowledge 
> leaders in data-in-motion platforms, they have had little exposure to the 
> open source governance process. Customers are currently running applications 
> based on DataTorrent RTS in production.
> 
> == Rationale ==
> Big data applications written for non-Hadoop platforms typically require 
> major rewrites  to get them to work with Hadoop. This rewriting creates a 
> significant bottleneck in terms of resources (expertise) which in turn 
> jeopardizes the viability of such an endeavour. It is hard enough to acquire 
> big data expertise, demanding additional expertise to do a major code 
> conversion makes it a very hard problem for projects to successfully migrate 
> to Hadoop. Also, due to the batch processing nature of Hadoop’s MapReduce 
> paradigm, users often have to wait tens of minutes to see results and act on 
> them due to various delays in data flow. DataTorrent’s RTS data-in-motion 
> architecture is designed to address this problem. It enables even the non big 
> data developer to write code and operate it in a scalable, fault tolerant 
> manner. The big data-in-motion architecture of DataTorrent’s RTS enables ease 
> of integration into current enterprise infrastructure. This goal was achieved 
> by keeping the API simple and empowering users to put in the connector code 
> as is (or with minimal changes).
> 
> Malhar is a manifestation of this reality, and we or the customer engineers 
> were able to create these connectors within a day or so if not within a week. 
> Connectors include those to integrate with message bus(es), file systems, 
> databases, other protocols, and more continue to be added. Over a period of 
> time we expect users to simply pick a connector that already exists in Malhar 
> and quickly begin integrating with their current enterprise infrastructure. 
> Within the data-in-motion architecture a stream application is one with 
> connector(s) to say Kafka, JMS, or Flume; while a batch application is one 
> with connector(s) to HDFS, HBase, FTP, NFS, S3n etc. This allows usage of the 
> platform for both stream as well as batch processing with same business 
> logic. Complete separation of user written application code from all 
> operational aspects of the system, as well as support code for YARN, 
> significantly expands the potential use cases that can migrate to use Hadoop.
> 
> Apex will enable Hadoop eco-system to migrate a lot more use cases. It will 
> enable the Hadoop eco-system to deliver on a promise to rapidly transform 
> current IT infrastructure. Apex will help in significantly increasing 
> productization of big data projects. One of the main barometers of success in 
> the Hadoop eco-system is significant reduction of time to market for big data 
> applications migrating to Hadoop. We believe that Apex will be one of the 
> platforms that will enable users to extract value from big data, by reducing 
> time to market. This rapid innovation can be optimally achieved through a 
> vibrant, diverse, self-governed community collectively innovating around Apex 
> and the Malhar library, while at the same time cross-pollinating with various 
> other big data platforms. ASF is an ideal place to meet this goal.
> 
> == Initial Goals ==
> Our initial goals are to bring Apex and Malhar repositories into the ASF, 
> adapt internal engineering processes to open development, and foster a 
> collaborative development model in accordance with the "Apache Way." 
> DataTorrent plans to develop new functionality in an open, community-driven 
> way. To get there, the existing internal build, test and release processes 
> will be refactored to support open development. We already have an active 
> user community on google groups that we intend to migrate to Apache.
> 
> == Current Status ==
> Currently, the project Apex code base is available under Apache 2.0 license 
> (https://github.com/DataTorrent/Apex <https://github.com/DataTorrent/Apex>). 
> Project Malhar code base is available under Apache 2.0 license 
> (https://github.com/DataTorrent/Malhar 
> <https://github.com/DataTorrent/Malhar>). Project Malhar was open sourced 2 
> years ago which should make it easy for the project Malhar team to adapt to 
> an  open, collaborative, and meritocratic environment. Contributors of Malhar 
> are employees of DataTorrent or have agreed to the shift to Apache. Project 
> Apex, in contrast, was developed as a proprietary, closed-source product, but 
> the internal engineering practices adopted by the development team were 
> common to Malhar, and should lend themselves well to an open  environment. 
> DataTorrent plans to execute a software grant agreement as part of the launch 
> of the incubation of Apex as an Apache project.
> 
> The DataTorrent team has always focused on building a robust end user 
> community of paying and non-paying customers. We think that the existing 
> community centered around the existing google groups mailing list should be 
> relatively easy to transform into an Apache-style community including both 
> users and developers.
> 
> === Meritocracy ===
> Our proposed list of initial committers include the current RTS R&D team, and 
> our existing customers. This group will form a base for the broader community 
> we will invite to collaborate on the codebase. We intend to radically expand 
> the initial developer and user community by running the project in accordance 
> with the "Apache Way". Users and new contributors will be treated with 
> respect and welcomed. By participating in the community and providing quality 
> patches/support that move the project forward, they will earn merit. They 
> also will be encouraged to provide non-code contributions (documentation, 
> events, presentations, community management, etc.) and will gain merit for 
> doing so. Those with a proven support and quality track record will be 
> encouraged to become committers.
> 
> === Community ===
> If Apex is accepted for incubation, the primary initial goal will be 
> transitioning the core community towards embracing the Apache Way of project 
> governance. We will solicit major existing contributors to become committers 
> on the project from the start. It should be noted that the existing community 
> is already more diverse in many ways than some top-level Apache projects. We 
> expect that we can encourage even more diversity.
> 
> === Core Developers ===
> While a few core developers are skilled in working in openly governed Apache 
> communities, most of the core developers are currently NOT affiliated with 
> the ASF and would require new ICLAs before committing to the project. There 
> would also be a learning curve associated with this on-boarding. Changing 
> current development practices to be more open will be an important step.
> 
> === Alignment ===
> The following existing ASF projects provide related functionality as that 
> provided by Apex and should be considered when reviewing Apex proposal:
> 
> Apache HadoopⓇ is a distributed storage and processing framework for very 
> large datasets focusing primarily on batch processing for analytic purposes. 
> Apex is a native YARN application. The Apex and Malhar roadmap includes plans 
> to continue to leverage YARN, and help the YARN community develop the ability 
> to support long running applications. Apex uses DFS interface of its core 
> checkpoint/commit. Malhar has a large number of operators that leverage HDFS 
> and other Apache projects. Our roadmap includes plans to continue to deepen 
> the currently close integration with HDFS.
> 
> Apache HBase offers tabular data stored in Hadoop based on the Google 
> Bigtable model. Malhar has HBase connectors to ease integration with HBase. 
> Malhar roadmap includes plans to continue to enhance integration with Apache 
> HBase.
> 
> Apache Kafka offers distributed and durable publish-subscribe messaging. 
> Malhar integrates Kafka with Hadoop through feature rich connectors and 
> supports ingest as well as analytical functions to incoming data. Raw data 
> can be ingested from Kafka and results can be written to Kafka. Malhar 
> roadmap includes plans to continue to enhance integration with Apache Kafka.
> 
> Apache Flume is a distributed, reliable, and available service for 
> efficiently collecting, aggregating, and moving large amounts of log data. 
> Malhar has Flume connectors to ease integration with Flume. These connectors 
> ensures that ingestion with Flume is fault tolerant and thus can be done in 
> real-time with the same SLA as Flume’s HDFS connectors. Malhar roadmap 
> includes plans to continue to enhance integration with Apache Flume.
> 
> Apache Cassandra is a highly scalable, distributed key-value store that 
> focuses on eventual consistency. Malhar has connectors to ease integration 
> with Cassandra. Malhar roadmap includes plans to continue to enhance 
> integration with Apache Cassandra.
> 
> Apache Accumulo is a distributed key-value store based on Google’s BigTable 
> design. Malhar has connectors to ease integration with Accumulo. The Malhar 
> roadmap includes plans to continue to enhance integration with Apache 
> Accumulo.
> 
> Apache Tez is aimed at building an application framework which allows for a 
> complex DAG of tasks for process data. The Apex and Malhar roadmaps include 
> plans to integrate with Apache Tez but this is not currently supported.
> 
> Apache ActiveMQ and its sub project Apache Apollo offers a powerful message 
> queue framework. Malhar has ActiveMQ connectors that ease integration with 
> ActiveMQ.
> 
> Apache Spark is an engine for processing large datasets, typically in a 
> Hadoop cluster. Malhar project makes it easy for users to integrate with 
> Spark. The Malhar roadmap includes plans to continue to enhance integration 
> with Apache Spark.
> 
> Apache Flink is an engine for scalable batch and stream data processing. 
> Malhar project makes it easy for users to integrate with Flink. There is 
> overlap in how Flink leverages data-in-motion architecture for both stream 
> and batch processing, and it does subscribe to our thought process that 
> data-in-motion can handle both stream and batch, meanwhile a batch only 
> engine will find it harder to manage streams. We differ in terms of how we 
> handle operability, user defined code, metrics, webservices etc. Apex is very 
> operational oriented, while Flink has much more focus on functional elements. 
> Malhar and rapid availability of common business logic is another 
> differentiator. We believe both these approaches are valid and the community 
> and innovation will gain by through cross pollination. We plan to integrate 
> with Apache Flink via HDFS for now.
> 
> Apache Hive software facilitates querying and managing large datasets 
> residing in distributed storage. Malhar project makes it easy for users to 
> integrate with Apache Hive. The Malhar roadmap includes plans to continue to 
> enhance integration with Apache Hive.
> 
> Apache Pig is a platform for analyzing large data sets.  Pig consists of a 
> high-level language for expressing data analysis programs, coupled with 
> infrastructure for evaluating these programs. The Apex and Malhar roadmaps 
> include plans to integrate with Apache Pig.
> 
> Apache Storm is a distributed realtime computation system. Malhar makes it 
> easy for users to integrate with Apache Storm. We plan to integrate with 
> Apache Storm via HDFS for now. Malhar roadmaps include plans to continue to 
> support mechanism for integration with Apache Storm.
> 
> Apache Samza is a distributed stream processing framework. Malhar makes it 
> easy for users to integrate with Apache Samza. We plan to integrate with 
> Apache Samza via HDFS or Apache Kafka for now. Malhar roadmaps include plans 
> to continue to support mechanism for integration with Apache Samza.
> 
> Apache Slider is a YARN application to deploy existing distributed 
> applications on YARN, monitor them, and make them larger or smaller as 
> desired even when the application is running. Once Slider matures, we will 
> take a look at close integration of Apex with Slider.
> 
> Project Malhar and Apex are aligned to many more Apache projects and other 
> open source projects as ease of integration with other technologies is one of 
> the primary goals of this project. These include Apache Solr, ElasticSearch, 
> MongoDB, Aerospike, ZeroMQ, CouchDB, CouchBase, MemCache, Redis, RabbitMQ, 
> Apache Derby.
> 
> == Known Risks ==
> Development has been sponsored mostly by a single company (DataTorrent, Inc.) 
> thus far and coordinated mainly by the core DataTorrent RTS and Malhar team, 
> with active participation from our current customers.
> 
> For the project to fully transition to the Apache Way governance model, 
> development must shift towards the merit-centric model of growing a community 
> of contributors balanced with the needs for extreme stability and core 
> implementation coherency.
> 
> The tools and development practices in place for the DataTorrent RTS and 
> Malhar products are compatible with the ASF infrastructure and thus we do not 
> anticipate any on-boarding pains. Migration from the current GitHub 
> repository is also expected to be straightforward.
> 
> === Orphaned products ===
> DataTorrent is fully committed to DataTorrent Apex and Malhar and the product 
> will continue to be based on the Apex project. Moreover, DataTorrent has a 
> vested interest in making Apex succeed by driving its close integration with 
> sister ASF projects. We expect this to further reduce the risk of orphaning 
> the product.
> 
> === Inexperience with Open Source ===
> DataTorrent has embraced open source software by open sourcing Malhar project 
> under Apache 2.0 license. The DataTorrent team includes veterans from the 
> Yahoo! Hadoop team. Although some of the initial committers have not been 
> developers on an entirely open source, community-driven project, we expect to 
> bring to bear the open development practices of Malhar to the Apex project. 
> Additionally, several ASF veterans agreed to mentor the project and are 
> listed in this proposal. The project will rely on their guidance and 
> collective wisdom to quickly transition the entire team of initial committers 
> towards practicing the Apache Way. DataTorrent is also driving the Kafka on 
> YARN (KOYA) initiative.
> 
> === Homogeneous Developers ===
> While most of the initial committers are employed by DataTorrent, we have 
> already seen a healthy level of interest from our existing customers and 
> partners. We intend to convert that interest directly into participation and 
> will be investing in activities to recruit additional committers from other 
> companies.
> 
> === Reliance on Salaried Developers ===
> Most of the contributors are paid to work in the Big Data space. While they 
> might wander from their current employers, they are unlikely to venture far 
> from their core expertises and thus will continue to be engaged with the 
> project regardless of their current employers.
> 
> === Relationships with Other Apache Products ===
> As mentioned in the Alignment section, Apex may consider various degrees of 
> integration and code exchange with Apache Hadoop (YARN and HDFS), Apache 
> Kafka, Apache HBase, Apache Flume, Apache Cassandra, Apache Accumulo, Apache 
> Tez, Apache Hive, Apache Pig, Apache Storm, Apache Samza, Apache Spark, 
> Apache Slider. Given the success that the DataTorrent RTS product enjoyed, we 
> expect integration points to be inside and outside the project. We look 
> forward to collaborating with these communities as well as other communities 
> under the Apache umbrella.
> 
> === An Excessive Fascination with the Apache Brand ===
> While we intend to leverage the Apache ‘branding’ when talking to other 
> projects as testament of our project’s ‘neutrality’, we have no plans for 
> making use of Apache brand in press releases nor posting billboards 
> advertising acceptance of Apex into Apache Incubator.
> 
> 
> == Documentation ==
> See documentation for the current state of the project documentation 
> available as part of the GitHub repositories - 
> https://github.com/DataTorrent/Apex <https://github.com/DataTorrent/Apex>; 
> https://github.com/DataTorrent/Malhar 
> <https://github.com/DataTorrent/Malhar>. In addition a list of demos that 
> serve as a how to guide are available at 
> https://github.com/DataTorrent/Malhar/tree/master/demos 
> <https://github.com/DataTorrent/Malhar/tree/master/demos>
> 
> == Initial Source ==
> DataTorrent has released the source code for Apex under Apache 2.0 License at 
> https://github.com/DataTorrent/Apex <https://github.com/DataTorrent/Apex>, 
> and that of Malhar under Apache 2.0 licence at 
> https://github.com/DataTorrent/Malhar 
> <https://github.com/DataTorrent/Malhar>. We encourage ASF community members 
> interested in this proposal to download the source code, review it and try 
> out the software.
> 
> == Source and Intellectual Property Submission Plan ==
> As soon as Apex is approved to join Apache Incubator, DataTorrent will 
> execute a Software Grant Agreement and the source code will be transitioned 
> onto ASF infrastructure. The code is already licensed under the  Apache 
> Software License, version 2.0. We know of no legal encumberments that would 
> inhibit the transfer of source code to the ASF.
> 
> == External Dependencies ==
> All dependencies fall under the permissive licenses categories, or weak copy 
> left (http://www.apache.org/legal/resolved.html#category-b 
> <http://www.apache.org/legal/resolved.html#category-b>). We intend to remove 
> the dependencies on GPL licensed technologies on which APex or Malhar depend. 
> These technologies are optional and have been marked as such.
> 
> Embedded dependencies (relocated):
>    * None
> 
> Runtime dependencies:
>    * activemq-client
>    * ant
>    * async-http-client
>    * bval-jsr303
>    * commons-beanutils
>    * commons-codec
>    * commons-lang3
>    * commons-compiler
>    * embassador
>    * fastutil
>    * guava
>    * hadoop-common
>    * hadoop-common-tests
>    * hadoop-yarn-client
>    * httpclient
>    * jackson-core-asl
>    * jackson-mapper-asl
>    * javax.mail
>    * jersey-apache-client4
>    * jersey-client
>    * jetty-servlet
>    * jetty-websocket
>    * jline
>    * kryo
>    * named-regexp
>    * netlet
>    * rhino (GPL 2.0, optional)
>    * slf4j-api
>    * slf4j-log4j12
>    * validation-api
>    * xbean-asm5-shaded
>    * zip4j
> 
> Module or optional dependencies
>    * accumulo-core
>    * aerospike-client
>    * amqp-client
>    * aws-java-sdk-kinesis
>    * cassandra-driver-core
>    * couchbase-client
>    * CouchbaseMock
>    * elasticsearch
>    * geoip-api (LGPL, optional)
>    * hbase
>    * hbase-client
>    * hbase-server
>    * hive-exec
>    * hive-service
>    * hiveunit
>    * javax.mail-api
>    * jedis
>    * jms-api
>    * jri (GPL, optional)
>    * jriengine (LGPL, optional)
>    * jruby (LGPL, optional)
>    * jython (PSF License, optional)
>    * jzmq (LGPL, optional)
>    * kafka_2.10
>    * lettuce (GPL, optional)
>    * libthrift
>    * Memcached-Java-Client
>    * mongo-java-driver
>    * mqtt-client
>    * mysql-connector-java (GPL2, optional)
>    * org.ektorp
>    * rengine (LGPL, optional)
>    * rome
>    * solr-core
>    * solr-solrj
>    * spymemcached
>    * sqlite4java
>    * super-csv
>    * twitter4j-core
>    * twitter4j-stream
>    * uadetector-resources
>    * org.apache.servicemix.bundles.splunk
> 
> Build only dependencies:
>    * None
> 
> Test only dependencies:
>    * activemq-broker
>    * activemq-kahadb-store
>    * greenmail
>    * hadoop-yarn-server-tests
>    * hsqldb
>    * janino
>    * junit
>    * MockFtpServer
>    * mockito-all
>    * testng
> 
> Cryptography N/A
> 
> == Required Resources ==
> === Mailing lists ===
>    * priv...@apex.incubator.apache.org 
> <mailto:priv...@apex.incubator.apache.org> (moderated subscriptions)
>    * comm...@apex.incubator.apache.org 
> <mailto:comm...@apex.incubator.apache.org>
>    * d...@apex.incubator.apache.org <mailto: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-core.git>
>    * https://git-wip-us.apache.org/repos/asf/incubator-apex-malhar.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 
> <http://builds.apache.org/>
>    * Means of setting up regular builds for apex-malhar on builds.apache.org 
> <http://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.
> 

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to