Re: [VOTE] Accept Mnemonic into the Apache Incubator

[Arvind Prabhakar]

+1 (binding)

Regards,
Arvind

On Mon, Feb 29, 2016 at 9:37 AM, Patrick Hunt  wrote:

> Hi folks,
>
> OK the discussion is now completed. Please VOTE to accept Mnemonic
> into the Apache Incubator. I’ll leave the VOTE open for at least
> the next 72 hours, with hopes to close it Thursday the 3rd of
> March, 2016 at 10am PT.
> https://wiki.apache.org/incubator/MnemonicProposal
>
> [ ] +1 Accept Mnemonic as an Apache Incubator podling.
> [ ] +0 Abstain.
> [ ] -1 Don’t accept Mnemonic as an Apache Incubator podling because..
>
> Of course, I am +1 on this. Please note VOTEs from Incubator PMC
> members are binding but all are welcome to VOTE!
>
> Regards,
>
> Patrick
>
> 
> = Mnemonic Proposal =
> === Abstract ===
> Mnemonic is a Java based non-volatile memory library for in-place
> structured data processing and computing. It is a solution for generic
> object and block persistence on heterogeneous block and
> byte-addressable devices, such as DRAM, persistent memory, NVMe, SSD,
> and cloud network storage.
>
> === Proposal ===
> Mnemonic is a structured data persistence in-memory in-place library
> for Java-based applications and frameworks. It provides unified
> interfaces for data manipulation on heterogeneous
> block/byte-addressable devices, such as DRAM, persistent memory, NVMe,
> SSD, and cloud network devices.
>
> The design motivation for this project is to create a non-volatile
> programming paradigm for in-memory data object persistence, in-memory
> data objects caching, and JNI-less IPC.
> Mnemonic simplifies the usage of data object caching, persistence, and
> JNI-less IPC for massive object oriented structural datasets.
>
> Mnemonic defines Non-Volatile Java objects that store data fields in
> persistent memory and storage. During the program runtime, only
> methods and volatile fields are instantiated in Java heap,
> Non-Volatile data fields are directly accessed via GET/SET operation
> to and from persistent memory and storage. Mnemonic avoids SerDes and
> significantly reduces amount of garbage in Java heap.
>
> Major features of Mnemonic:
> * Provides an abstract level of viewpoint to utilize heterogeneous
> block/byte-addressable device as a whole (e.g., DRAM, persistent
> memory, NVMe, SSD, HD, cloud network Storage).
>
> * Provides seamless support object oriented design and programming
> without adding burden to transfer object data to different form.
>
> * Avoids the object data serialization/de-serialization for data
> retrieval, caching and storage.
>
> * Reduces the consumption of on-heap memory and in turn to reduce and
> stabilize Java Garbage Collection (GC) pauses for latency sensitive
> applications.
>
> * Overcomes current limitations of Java GC to manage much larger
> memory resources for massive dataset processing and computing.
>
> * Supports the migration data usage model from traditional NVMe/SSD/HD
> to non-volatile memory with ease.
>
> * Uses lazy loading mechanism to avoid unnecessary memory consumption
> if some data does not need to use for computing immediately.
>
> * Bypasses JNI call for the interaction between Java runtime
> application and its native code.
>
> * Provides an allocation aware auto-reclaim mechanism to prevent
> external memory resource leaking.
>
>
> === Background ===
> Big Data and Cloud applications increasingly require both high
> throughput and low latency processing. Java-based applications
> targeting the Big Data and Cloud space should be tuned for better
> throughput, lower latency, and more predictable response time.
> Typically, there are some issues that impact BigData applications'
> performance and scalability:
>
> 1) The Complexity of Data Transformation/Organization: In most cases,
> during data processing, applications use their own complicated data
> caching mechanism for SerDes data objects, spilling to different
> storage and eviction large amount of data. Some data objects contains
> complex values and structure that will make it much more difficulty
> for data organization. To load and then parse/decode its datasets from
> storage consumes high system resource and computation power.
>
> 2) Lack of Caching, Burst Temporary Object Creation/Destruction Causes
> Frequent Long GC Pauses: Big Data computing/syntax generates large
> amount of temporary objects during processing, e.g. lambda, SerDes,
> copying and etc. This will trigger frequent long Java GC pause to scan
> references, to update references lists, and to copy live objects from
> one memory location to another blindly.
>
> 3) The Unpredictable GC Pause: For latency sensitive applications,
> such as database, search engine, web query, real-time/streaming
> computing, require latency/request-response under control. But current
> Java GC does not provide predictable GC activities with large on-heap
> memory management.
>
> 4) High JNI Invocation Cost: JNI calls are expensive, but high
> performance applications usually try to 

Re: [VOTE] Graduate Sentry

[Arvind Prabhakar]

+1 (binding)

Regards,
Arvind

On Wed, Feb 24, 2016 at 11:20 AM, Sravya Tirukkovalur 
wrote:

> Hi all,
>
> Following the positive discussion[1] and vote[2] in the Sentry
> community and a discussion[3] on the incubator list to graduate
> Sentry, I am calling a VOTE to graduate the project from the Incubator
> to a TLP. Please vote on the resolution pasted below.
>
> [ ] +1 Graduate Sentry from the Incubator
> [ ] +0 Don't care
> [ ] -1 Don't graduate Sentry from the Incubator (please specify reason)
>
> This vote will be open for at least 72 hours.
>
> References:
>
> [1] https://s.apache.org/dev_discuss
> [2] https://s.apache.org/dev_vote_result
> [3] https://s.apache.org/general_discuss
> Other:
> https://s.apache.org/general_notify
>
> https://cwiki.apache.org/confluence/display/SENTRY/Sentry+maturity+assessment
>
> Resolution to create a TLP from graduating Incubator podling:
>
> ==
>
>
> X. Establish the Apache Sentry 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 Fine grained authorization to data and
> metadata in Hadoop.
>
>   NOW, THEREFORE, BE IT RESOLVED, that a Project Management
>   Committee (PMC), to be known as the "Apache Sentry Project",
>   be and hereby is established pursuant to Bylaws of the
>   Foundation; and be it further
>
>   RESOLVED, that the Apache Sentry Project be and hereby is
>   responsible for the creation and maintenance of software
>   related to Fine grained authorization to data and metadata in Hadoop;
>   and be it further
>
>   RESOLVED, that the office of "Vice President, Apache Sentry" 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 Sentry Project, and to have primary responsibility
>   for management of the projects within the scope of
>   responsibility of the Apache Sentry 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 Sentry Project:
>
> * Ali Rizvi 
>
>* Anne Yu 
>
>* Arun Suresh 
>
>* Brock Noland 
>
>* Chaoyu Tang 
>
>* Colin Ma 
>
>* Daisy Zhou 
>
>* Dapeng Sun 
>
>* David Nalley 
>
>* Erick Tryzelaar 
>
>* Gregory Chanan 
>
>* Guoquan Shen 
>
>* Hadi Nahari 
>
>* Hao Hao 
>
>* Jarek Jarcec Cecho 
>
>* Johnny Zhang 
>
>* Karthik Ramachandran 
>
>* Mark Grover 
>
>* Milo Polte 
>
>* Lenni Kuff 
>
>* Patrick Daly 
>
>* Patrick Hunt 
>
>* Prasad Mujumdar 
>
>* Raghu Mani 
>
>* Sean Mackrory 
>
>* Shreepadma Venugopalan 
>
>* Sravya Tirukkovalur 
>
>* Tuong Truong 
>
>* Vamsee Yarlagadda 
>
>* Xiaomeng Huang 
>
>* Xuefu Zhang 
>
>   NOW, THEREFORE, BE IT FURTHER RESOLVED, that Sravya Tirukkovalur
>   be appointed to the office of Vice President, Apache Sentry, 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 Sentry 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 Sentry Project; and be it further
>
>   RESOLVED, that the Apache Sentry Project be and hereby
>   is tasked with the migration and rationalization of the Apache
>   Incubator Sentry podling; and be it further
>
>   RESOLVED, that all responsibilities pertaining to the Apache
>   Incubator Sentry podling encumbered upon the Apache Incubator
>   Project are hereafter discharged.
>
> 

Re: [VOTE] Accept Quarks into the Apache Incubator

[Arvind Prabhakar]

+1 (binding)

Regards,
Arvind

On Wed, Feb 24, 2016 at 9:01 AM, Katherine Marsden 
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
>  .
>  . All of the initial code is implemented using Java 8 and when built
> produces jars that can execute on Java 8, Java 7 and Android. The goal is
> to encourage community contributions in any area of Quarks, to  expand the
> community (including new committers) and use of Quarks. We  expect
> contributions will be driven by real-world use of Quarks by  anyone active
> in the IoT space such as auto manufactures, insurance  companies, etc. as
> well as individuals experimenting with devices such  as Raspberry Pis,
> Arduinos and/or smart phone apps etc. Contributions would be welcomed in
> any aspect of Quarks including:
>  .
>  * Support for additional programming languages used in devices such as C,
> OpenSwift, Python etc.
>  * Specific device feature (e.g. Raspberry Pi, Android) or protocol (e.g.
> OBD-2) support
>  * Connectors for device to device (e.g. AllJoyn), device local data
> sources,  or to back-end systems (e.g. a IoT cloud 

Re: [VOTE] Accept Kudu into the Apache Incubator

[Arvind Prabhakar]

+1 (binding)

Regards,
Arvind Prabhakar

On Tue, Nov 24, 2015 at 11:32 AM, Todd Lipcon <t...@apache.org> wrote:

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

Re: [VOTE] Accept Impala into the Apache Incubator

[Arvind Prabhakar]

+1 (binding)

Regards,
Arvind Prabhakar

On Tue, Nov 24, 2015 at 1:03 PM, Henry Robinson <he...@cloudera.com> 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

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Arvind Prabhakar]

Sorry for the tardy response, I am mostly on the road for this week and
have limited time and access to emails. Some comments below.

On Tue, Nov 3, 2015 at 3:54 AM, Joe Brockmeier <j...@zonker.net> wrote:

> 
> If that was your meaning, I do apologize for misinterpreting what you
> said. I do appreciate you understanding that my response was based on an
> honest interpretation of what you wrote.




No apologies necessary Joe, I am glad we are on the same page. If anything,
I will be more careful in the future in wording my opinion... I can see how
it may be interpreted the way you read it.



Just to be clear - you're
> vouching that all of Sentry's development is happening in the open, and
> Sentry development decisions are not being taken offlist?
>



Yes, in my best judgement, I feel the Sentry community is flourishing and
very welcoming of interactions with the broader community of users and
developers. They happen to be Jira centric and I agree that it may not seem
to be as welcoming as a non-Jira centric project. That said, the project's
focus is low-level security integration and it is not something that the
users interact with directly - which in my opinion naturally fits the Jira
centric model.

Regards,
Arvind Prabhakar



On Tue, Nov 3, 2015 at 5:54 PM, Joe Schaefer <joes...@gmail.com> wrote:

> The point I'm making about project dysfunction is something I've learned to
> expect from projects
> that are using inappropriate means to control the project.  Any time you
> challenge their means of
> control, the response you get will indicate whether or not you are barking
> up the wrong tree.
> The absence of inappropriate feedback is in fact a sign that we are not
> gauging things such
> as they actually are, but are projecting our own perceptions onto the
> project.
>
>
> On Tue, Nov 3, 2015 at 8:49 PM, Joe Schaefer <joes...@gmail.com> wrote:
>
> > The whole point of the ASF's archiving policy is to ensure these types of
> > concerns can
> > be examined objectively by others.  With jira we have the ability to
> drill
> > down in considerably
> > more detail than we do trawling the email archives, but in either case
> any
> > objective attempts
> > to discover inappropriate conduct will fail to yield much fruit.  The
> > committers do work fast
> > when it comes to repairing bugs they discover, but that doesn't mean they
> > are doing things
> > in the wrong order.  I have yet to see a large patch prematurely applied
> > to the repo: the bulk
> > of the patches are minor changes that certainly can be worked out hours
> > after discovering the
> > problem and filing the ticket.
> >
> > On Tue, Nov 3, 2015 at 8:25 PM, Joe Schaefer <joes...@gmail.com> wrote:
> >
> >> Look at what we don't see- signs of dysfunction.  Even with this thread,
> >> with serious consequences for the podling,
> >> nobody is behaving in a territorial or defensive way about the project.
> >> The feedback has been very reasonable,
> >> respectful of Joe's concerns, and direct.
> >>
> >> I have a strong suspicion that the core problem here is that the mentors
> >> aren't following the commit list, which is
> >> where the jira email trail gets sent.  Looking there you will see a
> >> plethora of examples where tickets, many filed by
> >> non-project participants, are being discussed by several project
> members,
> >> far from the presentation that discussions
> >> are happening off-Apache-infra and tickets are being "shut down" without
> >> public review.
> >>
> >>
> >> On Tue, Nov 3, 2015 at 8:17 PM, Joe Schaefer <joes...@gmail.com> wrote:
> >>
> >>> The only thing I might recommend of the podling is to try to leave
> >>> low-hanging fruit in jira unpatched for a longer period of time to
> allow
> >>> outside contributors the ability to participate.  Coupled with
> identifying
> >>> these tickets on the mailing list, that might lead to more outside
> >>> contributions.
> >>>
> >>> I do share the concern that we have several elected committers that
> >>> haven't yet advanced to the ppmc level.
> >>> Perhaps there's not enough project-level mentoring (as opposed to IMPC
> >>> mentoring) going on to bring these newer people along.
> >>>
> >>>
> >>> On Tue, Nov 3, 2015 at 7:59 PM, Joe Schaefer <joes...@gmail.com>
> wrote:
> >>>
> >>>> I still consider that hearsay evidence.  If you bother to actually
> look
> >>>> at their Jira you will see t

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Arvind Prabhakar]

Thanks Ted for pointing this out.

The question is "[are you] vouching that all of Sentry's development is
> happening in the open and Sentry development decisions are not being taken
> offlist?"


Yes, to the best of my knowledge, that is the case.

Regards,
Arvind Prabhakar


On Tue, Nov 3, 2015 at 7:13 PM, Ted Dunning <ted.dunn...@gmail.com> wrote:

> On Tue, Nov 3, 2015 at 6:49 PM, Arvind Prabhakar <arv...@apache.org>
> wrote:
>
> >
> > 
> >
> > Just to be clear - you're
> > > vouching that all of Sentry's development is happening in the open, and
> > > Sentry development decisions are not being taken offlist?
> > >
> > 
> >
> >
> > Yes, in my best judgement, I feel the Sentry community is flourishing and
> > very welcoming of interactions with the broader community of users and
> > developers. They happen to be Jira centric and I agree that it may not
> seem
> > to be as welcoming as a non-Jira centric project. That said, the
> project's
> > focus is low-level security integration and it is not something that the
> > users interact with directly - which in my opinion naturally fits the
> Jira
> > centric model.
>
>
>
> Arvind,
>
> Since we just came off of a misunderstanding about an ambiguous statement,
> I would like to point out that your response did not actually answer the
> question.
>
> It might be good to nip any further misunderstanding in the bud by
> clarifying what you said.
>
> The question is "[are you] vouching that all of Sentry's development is
> happening in the open and Sentry development decisions are not being taken
> offlist?"
>

Re: Concerning Sentry: A disagreement over the Apache Way and graduation

[Arvind Prabhakar]

On Mon, Nov 2, 2015 at 12:28 PM, Joe Brockmeier <j...@zonker.net> wrote:

> 
> ... the reply from
> Arvind which basically says he doesn't consider it an issue if the
> project is "following a roadmap the community does not have control
> over... that too is not an issue in my opinion at all." [2]
>



Joe - I trust and respect you enough to feel that this is unintentional,
but I am being taken out of context. In this and previous emails you have
suggested that I admit and approve of an external entity controlling
Sentry. This is a gross misrepresentation. Please stop implying that for
your future responses as it was not what I said or meant.

It is very clear to me that you have taken a firm stance in how you feel
about the project based on high level observations from interactions of
other mentors. If you were to actually engage with the community, see for
yourself how the Jira communication is handled by the project, I think it
may give you information that you may be missing.

Regards,
Arvind Prabhakar

On Mon, Nov 2, 2015 at 2:11 PM, Joe Brockmeier <j...@zonker.net> wrote:

> On Mon, Nov 2, 2015, at 04:59 PM, Patrick Hunt wrote:
> > On Mon, Nov 2, 2015 at 1:55 PM, Joe Brockmeier <j...@zonker.net> wrote:
> >
> > > On 11/02/2015 04:41 PM, Sravya Tirukkovalur wrote:
> > > > I think it is a good sign that community is volunteering to do the
> > > release
> > > > work.
> > >
> > > I think the point I'm making is largely being ignored. I'm not seeing
> > > much room for volunteers, and a lot of indication that
> > > conversations/decisions are happening off list and being carried back
> > > rather than being done entirely openly.
> > >
> > >
> > Sorry, I don't think it's being ignored, just that the rest of us are not
> > able to see the same issues.
> >
> > For example I see over 30 committers on the Sentry status page.
> > http://incubator.apache.org/projects/sentry.html
>
> Sentry started with 24 committers/PPMC. It hasn't added any PPMC members
> since its inception. (IIRC there was some mention on a thread of if
> there was a graduation vote all committers being PMC, but I haven't
> found that reference.)
>
> Note: I'm going to stop thread-sitting for the rest of the day and check
> back in tomorrow.
>
> Best,
>
> jzb
> --
> Joe Brockmeier
> j...@zonker.net
> Twitter: @jzb
> http://www.dissociatedpress.net/
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>
>

Re: [VOTE] Release Sentry incubating version 1.6.0 (rc0)

[Arvind Prabhakar]

+1 (binding)

Regards,
Arvind Prabhakar

On Tue, Sep 15, 2015 at 11:27 PM, Sun, Dapeng <dapeng@intel.com> wrote:

> Hi IPMC,
>
>
>
> This is the incubator release of Apache Sentry, version 1.6.0-incubating.
>
>
>
> A vote on releasing this package has already passed in Apache Sentry. We
> ask for your help to vote on this incubator release.
>
> PPMC[1] including +1 votes from our PPMC (Sravya Tirukkovalur, Lenni Kuff,
> Prasad Mujumdar).
>
>
>
> The list of fixed issues, added features and improvements can be found
> here:
>
> http://s.apache.org/w5
>
> Source files :
> https://dist.apache.org/repos/dist/dev/incubator/sentry/1.6.0-incubating-rc0/
>
> Tag to be voted on (release-1.6.0-rc0/SHA:
> 3c122b76483531db5f0de82cd80d9ce5967f6e00):
>
>
> https://git-wip-us.apache.org/repos/asf?p=incubator-sentry.git;a=commit;h=3c122b76483531db5f0de82cd80d9ce5967f6e00
>
> Sentry's KEYS containing the PGP key we used to sign the release:
>
> http://www.apache.org/dist/incubator/sentry/KEYS
>
>
>
> Note that this is a source only release and we are voting on the source:
>
> tag=release-1.6.0-rc0, SHA=3c122b76483531db5f0de82cd80d9ce5967f6e00
>
>
>
> Vote will be open for 72 hours.
>
>
>
> [ ] +1 approve
>
> [ ] +0 no opinion
>
> [ ] -1 disapprove (and reason why)
>
>
>
> Thanks
>
> Sentry 1.6.0 Release Manager (Dapeng Sun)
>
>
>
> [1] -
> http://mail-archives.apache.org/mod_mbox/sentry-dev/201509.mbox/%3CB957EE1AFDEBFD4B934BCF11804A23DC032933E5%40shsmsx102.ccr.corp.intel.com%3E
>

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

[Arvind Prabhakar]

On Mon, Aug 3, 2015 at 12:37 AM, Bertrand Delacretaz bdelacre...@apache.org
 wrote:

 On Mon, Aug 3, 2015 at 4:05 AM, Roman Shaposhnik ro...@shaposhnik.org
 wrote:
  ...who else thinks the movement towards empowering
  PPMCs and making IPMC very much like the board makes sense?...

 How is that different from the status quo where a podling with active
 mentors can have their releases +1ed by their mentors, requiring
 minimal interaction with the IPMC?


In spirit it may not be very different, but in practice it is the polar
opposite. As someone who has worked through the incubation of a few
projects both as an initial committer as well as a mentor, I feel that the
biggest weakness of the current Incubator is it's very strength of being
all inclusive of different interpretations/understandings of the goals of
incubation. With every IPMC member having their own close-to-heart issues
and inclinations, along with their good intentions, I don't think we are
doing very much to help the podlings understand the principals of Apache
Way or learn self-governance that works best for their communities.
Instead, we often end up prescribing things which go beyond the charter of
the Incubator, just to establish a sense of comfort in ensuring we have met
our responsibilities.

Therefore, I too favor the idea of a smaller, well-defined, tactical IPMC
that:
a) establishes a clear objective criteria for growth and graduation
including the necessary processes and policies,
b) oversees the execution of these processes and policies via measurable
means, and,
c) has the final say in the graduation of the podling

...will be a big step in the right direction. This does look more like the
way our board is organized. Arguably, this IPMC could still enlist the help
of member/mentors but will be doing so without granting the decision making
privileges to them.

Regards,
Arvind Prabhakar




 -Bertrand

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

Re: Reform of Incubator {was; [DISCUSSION] Graduate Ignite from the Apache Incubator)

[Arvind Prabhakar]

On Mon, Aug 3, 2015 at 1:59 PM, Andrew Purtell apurt...@apache.org wrote:

 
 ​
 In fact, in my opinion it leads to the very unfortunate side effect of IPMC
 ​ ​
 feeling in need to justify why it exists by micromanaging podlings.

 I've been through incubation as a mentor on Phoenix, Nifi, and now getting
 up to speed on Trafodion, I have not seen micromanagement of podlings.
 Could you point out an example? Curious what you mean.


It is worth noting that none of the IPMC members micromanage on purpose, or
are even aware that their actions are being interpreted as acts of
micromanagement. From their perspective, it is their responsibility to
guide the podling, and that is what they are trying to do. It will unfair
to bring those out as examples of micromanagement.

That said, I have personally been in positions where I have seen IPMC
members ask - and even demand things at times - that I feel are
unreasonable requests for the podling. The reason I do not challenge those
is because I feel that their asks are rooted in good intentions, and that
the IPMC in its current form encourages such involvement and authority. At
the same time I also worry about the state of the podling and what this
does to their way of thinking about Apache and the Incubator.

Regards,
Arvind Prabhakar




 On Mon, Aug 3, 2015 at 11:33 AM, Roman Shaposhnik ro...@shaposhnik.org
 wrote:

  On Sun, Aug 2, 2015 at 7:18 PM, John D. Ament johndam...@apache.org
  wrote:
   I wonder how much of the silence is a notion of I don't want to be
   accountable if something goes wrong in this podling.
 
  Right, but that same concern could be applied to every single TLP
  and yet the board seems to do the right thing with that.
 
   Having the IPMC safety net means its at least the IPMC's fault if
  something
   goes wrong.
 
  My point all along has been that this is a false sense of security.
  ​​
  In fact,
  in my opinion it leads to the very unfortunate side effect of IPMC
  feeling in need to justify why it exists by micromanaging podlings.
 
   Personally, I'd be happy if the PPMCs had more self governance.  But I
   think there are also some key people on the IPMC that should be able to
   lend their skills out to the broader PPMCs in case of need.
 
  Which would be totally fine and gets us back to the point Daniel and I
 were
  discussing: a release compliance team (horrible name, I know) as part of
  ASF.
 
  Thanks,
  Roman.
 
  -
  To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
  For additional commands, e-mail: general-h...@incubator.apache.org
 
 


 --
 Best regards,

- Andy

 Problems worthy of attack prove their worth by hitting back. - Piet Hein
 (via Tom White)

Re: [VOTE] Release Apache NiFi 0.2.0-incubating

[Arvind Prabhakar]

+1 (binding)

* Verified signatures and checksums
* git tag matches with source distribution
* top level files look good
* sources compile and test correctly
* rat check looks good

Regards,
Arvind Prabhakar


On Mon, Jul 13, 2015 at 6:44 AM, Matt Gilman matt.c.gil...@gmail.com
wrote:

 Hello

 The Apache NiFi PPMC has voted to release Apache NiFi 0.2.0-incubating. The
 vote was based on the release candidate and thread described below. We now
 request the IPMC to vote on this release.

 Here is the PPMC voting result:
 0 +1 (IPMC binding) - IPMC we need your help to reach the requisite 3
 binding votes.
 4 +1 (PPMC non-binding)
 3 +1 (non-binding)
 0  0
 0 -1

 Here is the PPMC vote thread: http://s.apache.org/BcG

 The source zip, including signatures, digests, etc. can be found at:
 https://repository.apache.org/content/repositories/orgapachenifi-1057/

 The Git tag is nifi-0.2.0-incubating-RC1
 The Git commit ID is e4f51eac9d1b9eabbb091a9f2c3eb1fee453cfc6

 https://git1-us-west.apache.org/repos/asf/incubator-nifi/repo?p=incubator-nifi.git;a=commit;h=e4f51eac9d1b9eabbb091a9f2c3eb1fee453cfc6

 Checksums of nifi-0.2.0-incubating-source-release.zip:
 MD5: 22301dc8d9006f73b0fb7aef395e6b92
 SHA1: 1ed4c892d98c059865610fcb5140093c5b4e

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

 KEYS file available here:
 https://dist.apache.org/repos/dist/release/incubator/nifi/KEYS

 110 issues were closed/resolved for this release:

 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12316020version=12332286

 The vote will be open for 72 hours.
 Please download the release candidate and evaluate the necessary items
 including checking hashes, signatures, build from source, and test.  Then
 please vote:

 [ ] +1 Release this package as nifi-0.2.0-incubating
 [ ] +0 no opinion
 [ ] -1 Do not release this package because...

Re: [VOTE] Release Sentry incubating version 1.5.1 (rc0)

[Arvind Prabhakar]

+1 (binding, fwded from my vote on dev list)

Regards,
Arvind Prabhakar

On Thu, Jul 9, 2015 at 6:07 PM, Shen, Guoquan guoquan.s...@intel.com
wrote:

 Hello IPMC,
 We have passed the PPMC vote for Sentry incubator release 1.5.1(rc0) with
 3 +1  votes from
 Lenni Kuff, Prasad Mujumdar and Sravya Tirukkovalur.  We ask for your help
 to vote
 on this incubator release.

 This is the incubator release of Apache Sentry, version 1.5.1-incubating.
 It fixes the following issues: http://s.apache.org/hVw
 Source files :
 https://dist.apache.org/repos/dist/dev/incubator/sentry/1.5.1-incubating/
 Tag to be voted on
 (release-1.5.1/SHA:d9ee8ade724d7ecc7433517bfb769da2cd002b0b):
 https://git-wip-us.apache.org/repos/asf?p=incubator-sentry.git;a=commit;h=d9ee8ade724d7ecc7433517bfb769da2cd002b0b

 Sentry's KEYS containing the PGP key we used to sign the release:
 http://www.apache.org/dist/incubator/sentry/KEYS


 Note that this is a source only release and we are voting on the source:
 tag=release-1.5.1, SHA=d9ee8ade724d7ecc7433517bfb769da2cd002b0b

 Vote will be opened for 72 hours.

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

 Thank you for your prompt votes.

 Respectfully,

 Sentry 1.5.1 Release Manager (Guoquan Shen)

Re: [VOTE] Graduate Apache NiFi from the Incubator

[Arvind Prabhakar]

+1 (binding)

Regards,
Arvind Prabhakar

On Tue, Jun 16, 2015 at 9:05 PM, Joe Witt joe.w...@gmail.com wrote:

 Hello Apache Incubator

 This thread is to call a vote within the Incubator for the graduation
 of Apache NiFi.

 Status page:  http://incubator.apache.org/projects/nifi.html
 Incubator graduation discussion: http://s.apache.org/wmy
 NiFi community graduation vote: http://s.apache.org/GT9

 The discussion prompted Benson to join the PMC list to provide apache
 member experience and we clarified the scope language with discussion
 in the NiFi community.

 From the discussion thread Chris Mattmann offered his binding +1 vote.

 Since joining the Incubator in November, 2014 the NiFi community has:
  * Produced three IPMC approved releases.
  * Expanded the PPMC with 4 new members.
  * Grown the community.  Developed increased interoperability with
 other Apache projects.
  * Conducted a successful community vote to graduate with 22 +1 votes
 (5 IPMC binding).

 Please vote

 [  ] +1 Graduate Apache NiFi as a TLP
 [  ] +0
 [  ] -1 Do not graduate Apache NiFi as a TLP because…

 Voting will last 72 hours ending at 05:00 June 20, 2015 UTC.

 Thanks
 Joe

 === Board Resolution ===

 Establish the Apache NiFi 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 an automated and durable data broker
 between systems providing interactive command and control
 and detailed chain of custody for data.

 NOW, THEREFORE, BE IT RESOLVED, that a Project Management
 Committee (PMC), to be known as the Apache NiFi Project,
 be and hereby is established pursuant to Bylaws of the
 Foundation; and be it further

 RESOLVED, that the Apache NiFi Project be and hereby is
 responsible for the creation and maintenance of software
 related to an automated and durable data broker
 between systems providing interactive command and control
 and detailed chain of custody for data; and be it further

 RESOLVED, that the office of Vice President, Apache NiFi 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 NiFi Project, and to have primary responsibility
 for management of the projects within the scope of
 responsibility of the Apache NiFi 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 NiFi Project:
 * Brandon DeVries (devri...@apache.org)
 * Matt Gilman (mcgil...@apache.org)
 * Tony Kurc (tk...@apache.org)
 * Mark Payne (marka...@apache.org)
 * Aldrin Piri (ald...@apache.org)
 * Dan Bress (danbr...@apache.org)
 * Jennifer Barnabee (jbarna...@apache.org)
 * Joseph L. Witt (joew...@apache.org)
 * Jason Carey (jca...@apache.org)
 * Adam Taft (tafts...@apache.org)
 * Benson Margulies (bimargul...@apache.org)
 * Bryan Bende (bbe...@apache.org)

 NOW, THEREFORE, BE IT FURTHER RESOLVED, that
 Joseph L. Witt be appointed to the office of Vice President,
 Apache NiFi, 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 NiFi 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 NiFi Project; and be it further

 RESOLVED, that the Apache NiFi Project be and hereby
 is tasked with the migration and rationalization of the Apache
 Incubator NiFi podling; and be it further

 RESOLVED, that all responsibilities pertaining to the Apache
 Incubator NiFi podling encumbered upon the Apache Incubator
 Project are hereafter discharged.

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

Re: [VOTE] Accept Trafodion into Apache Incubator

[Arvind Prabhakar]

+1 (binding)

Regards,
Arvind Prabhakar

On Tue, May 19, 2015 at 2:27 PM, Stack st...@duboce.net wrote:

 Following the discussion earlier in the thread [1], I would like to call a
 VOTE to accept Trafodion as a new Apache Incubator project.

 The proposal is available on the wiki at [2] and is also attached to this
 mail.

 The VOTE is open for at least the next 72 hours:

  [ ] +1 accept Trafodion into the Apache Incubator
  [ ] ±0 Abstain
  [ ] -1 because...

 I am +1 (binding)

 Thank you,
 St.Ack

 1.

 http://mail-archives.apache.org/mod_mbox/incubator-general/201505.mbox/%3CCADcMMgG4NHtmFZ519iqgZLA8Lj-E7VmaQ%3Dr8C011LuS5pR0Vkw%40mail.gmail.com%3E
 2.  https://wiki.apache.org/incubator/TrafodionProposal
 https://wiki.apache.org/incubator/TrafodionProposal#preview



 Trafodion Apache Incubator Proposal

 Abstract

 Trafodion is a webscale SQL-on-Hadoop solution enabling transactional or
 operational workloads on Hadoop.

 Proposal

 Apache Trafodion builds on the scalability, elasticity, and flexibility of
 Hadoop. Trafodion extends Hadoop to provide guaranteed transactional
 integrity, enabling new kinds of big data applications to run on Hadoop.
 Key
 features of Apache Trafodion include:

 * Full-functioned ANSI SQL language support
 * JDBC/ODBC connectivity for Linux/Windows clients
 * Distributed ACID transaction protection across multiple statements,
 tables and rows
 * Performance improvements for OLTP workloads with compile-time and
 run-time optimizations
 * Support for large data sets using a parallel-aware query optimizer
 * ANSI SQL security and data integrity constraints including referential
 integrity

 Hewlett-Packard Company submits this proposal to donate its Apache License,
 Version 2.0 open source project known as Trafodion, its source code,
 documentation, and web site content to the Apache Software Foundation in
 order to build an open source community

 Background

 Trafodion is an open source project sponsored by HP, incubated at HP Labs
 and HP-IT, to develop an enterprise-class SQL-on-Hadoop solution targeting
 big data transactional or operational workloads. HP publically announced
 the open source project and uploaded the source code to GitHub in June
 2014.

 The SQL compiler, optimizer and executor components of Trafodion have a
 rich heritage. Under development since 1993, they were released as
 commercial closed source software in various flavors such as HP NonStop
 SQL/MX and HP Neoview. NonStop SQL/MX was designed for online transaction
 processing on HP’s NonStop (formerly Tandem) fault-tolerant servers and is
 known for its high availability, scalability, and performance. Hundreds of
 companies and thousands of servers are running mission-critical
 applications today on NonStop SQL/MX. In addition, much of these components
 today are running internal to HP as the core of its Enterprise Data
 Warehouse (EDW), managing over a PB of data.

 Starting in 2013, the software was modified to run on HBase and a new
 distributed transaction manager was written to run as an HBase
 co-processor.

 Unlike most NOSQL and other SQL-on-Hadoop open source projects, Trafodion
 provides comprehensive ANSI SQL language support including full-functioned
 data definition (DDL), data manipulation (DML), transaction control (TCL)
 and database utility support.

 Trafodion provides comprehensive and standard SQL data manipulation support
 including SELECT, INSERT, UPDATE, DELETE, and UPSERT/MERGE syntax with
 language options including join variants, unions, where predicates,
 aggregations (group by and having), sort ordering, sampling, correlated and
 nested sub-queries, cursors, and many SQL functions.

 Utilities are provided for updating table statistics used by the optimizer
 for costing (i.e. selectivity/cardinality estimates) plan alternatives, for
 displaying the chosen SQL execution plan, plan shaping, backup and
 restoring the database, data loading and unloading, and a command line
 utility for interfacing with the database engine.

 Explicit control statements are provided to allow applications to define
 transaction boundaries and to abort transactions when warranted, including
 BEGIN WORK, COMMIT WORK, ROLLBACK WORK and SET TRANSACTION.

 Trafodion supports ANSI’s grant/revoke semantics to define user and role
 privileges in terms of managing and accessing the database objects.

 Rationale

 The name “Trafodion” (the Welsh word for transactions, pronounced
 “Tra-vod-eee-on”) was chosen specifically to emphasize the differentiation
 that Trafodion provides in closing a critical gap in the Hadoop ecosystem.
 Trafodion builds on the scalability, elasticity, and flexibility of Hadoop.
 Trafodion extends Hadoop to provide guaranteed transactional integrity,
 enabling new kinds of big data applications to run on Hadoop.

 Current Status

 HP released the Trafodion code under the Apache License, Version 2, in June
 of 2014. Since that time, we have had one major release in January

Re: [VOTE] Accept Zeppelin into the Apache Incubator

[Arvind Prabhakar]

+1 (binding)

Regards,
Arvind Prabhakar

On Thu, Dec 18, 2014 at 9:29 PM, Roman Shaposhnik r...@apache.org wrote:

 Following the discussion earlier:
 http://s.apache.org/kTp

 I would like to call a VOTE for accepting
 Zeppelin as a new Incubator project.

 The proposal is available at:
 https://wiki.apache.org/incubator/ZeppelinProposal
 and is also attached to the end of this email.

 Vote is open until at least Sunday, 21th December 2014,
 23:59:00 PST

 [ ] +1 Accept Zeppelin into the Incubator
 [ ] ±0 Indifferent to the acceptance of Zeppelin
 [ ] -1 Do not accept Zeppelin because ...

 Thanks,
 Roman.

 == Abstract ==
 Zeppelin is a collaborative data analytics and visualization tool for
 distributed, general-purpose data processing systems such as Apache
 Spark, Apache Flink, etc.

 == Proposal ==
 Zeppelin is a modern web-based tool for the data scientists to
 collaborate over large-scale data exploration and visualization
 projects. It is a notebook style interpreter that enable collaborative
 analysis sessions sharing between users. Zeppelin is independent of
 the execution framework itself. Current version runs on top of Apache
 Spark but it has pluggable interpreter APIs to support other data
 processing systems. More execution frameworks could be added at a
 later date i.e Apache Flink, Crunch as well as SQL-like backends such
 as Hive, Tajo, MRQL.

 We have a strong preference for the project to be called Zeppelin. In
 case that may not be feasible, alternative names could be: “Mir”,
 “Yuga” or “Sora”.

 == Background ==
 Large scale data analysis workflow includes multiple steps like data
 acquisition, pre-processing, visualization, etc and may include
 inter-operation of multiple different tools and technologies. With the
 widespread of the open source general-purpose data processing systems
 like Spark there is a lack of open source, modern user-friendly tools
 that combine strengths of interpreted language for data analysis with
 new in-browser visualization libraries and collaborative capabilities.

 Zeppelin initially started as a GUI tool for diverse set of
 SQL-over-Hadoop systems like Hive, Presto, Shark, etc. It was open
 source since its inception in Sep 2013. Later, it became clear that
 there was a need for a greater web-based tool for data scientists to
 collaborate on data exploration over the large-scale projects, not
 limited to SQL. So Zeppelin integrated full support of Apache Spark
 while adding a collaborative environment with the ability to run and
 share interpreter sessions in-browser

 == Rationale ==
 There are no open source alternatives for a collaborative
 notebook-based interpreter with support of multiple distributed data
 processing systems.

 As a number of companies adopting and contributing back to Zeppelin is
 growing, we think that having a long-term home at Apache foundation
 would be a great fit for the project ensuring that processes and
 procedures are in place to keep project and community “healthy” and
 free of any commercial, political or legal faults.

 == Initial Goals ==
 The initial goals will be to move the existing codebase to Apache and
 integrate with the Apache development process. This includes moving
 all infrastructure that we currently maintain, such as: a website, a
 mailing list, an issues tracker and a Jenkins CI, as mentioned in
 “Required Resources” section of current proposal.
 Once this is accomplished, we plan for incremental development and
 releases that follow the Apache guidelines.
 To increase adoption the major goal for the project would be to
 provide integration with as much projects from Apache data ecosystem
 as possible, including new interpreters for Apache Hive, Apache Drill
 and adding Zeppelin distribution to Apache Bigtop.
 On the community building side the main goal is to attract a diverse
 set of contributors by promoting Zeppelin to wide variety of
 engineers, starting a Zeppelin user groups around the globe and by
 engaging with other existing Apache projects communities online.


 == Current Status ==
 Currently, Zeppelin has 4 released versions and is used in production
 at a number of companies across the globe mentioned in Affiliation
 section. Current implementation status is pre-release with public API
 not being finalized yet. Current main and default backend processing
 engine is Apache Spark with consistent support of SparkSQL.
 Zeppelin is distributed as a binary package which includes an embedded
 webserver, application itself, a set of libraries and startup/shutdown
 scripts. No platform-specific installation packages are provided yet
 but it is something we are looking to provide as part of Apache Bigtop
 integration.
 Project codebase is currently hosted at github.com, which will form
 the basis of the Apache git repository.

 === Meritocracy ===
 Zeppelin is an open source project that already leverages meritocracy
 principles.  It was started by a handfull of people and now it has

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

[Arvind Prabhakar]

+1 (binding)

Regards,
Arvind Prabhakar

On Thu, Nov 13, 2014 at 9:39 PM, Henry Saputra henry.sapu...@gmail.com
wrote:

 Hi All,

 The Apache MetaModel community has wrapped up the VOTE to propose for
 graduation from Apache incubator. The VOTE passed with result:
 9 binding +1s
 zero 0s
 zero -1s
 (http://bit.ly/1u8n8eo)

 Apache MetaModel came into ASF incubator on 2013 and since then have
 grown into small but active community.

 We have made several good releases with different release managers,
 and also add new PPMC/committers [1].
 The project also has good traffic on the dev mailing list [2].

 We would like to propose graduation of Apache MetaModel from ASF
 incubator to top level project.


 [ ] +1 Graduate Apache MetaModel from the Incubator.
 [ ] +0 Don't care.
 [ ] -1 Don't graduate Apache MetaModel from the Incubator because.. .


 The VOTE will open for 72 hours (11/17/2014)


 Here is the proposal for the board resolution for graduation:


 === Board Resolution ==

 Establish the Apache MetaModel 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 an implementation of a
 Platform-as-a-Service Framework.

 NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
 (PMC), to be known as the Apache MetaModel Project, be and hereby is
 established pursuant to Bylaws of the Foundation; and be it further

 RESOLVED, that the Apache MetaModel Project be and hereby is
 responsible for the creation and maintenance of software related to
 providing an implementation of a Platform-as-a-Service Framework; and
 be it further

 RESOLVED, that the office of Vice President, MetaModel 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 MetaModel
 Project, and to have primary responsibility for management of the
 projects within the scope of responsibility of the Apache MetaModel
 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 MetaModel
 Project:

 * Alberto Rodriguez ardlema at apache dot org
 * Ankit Kumar ankitkumar2711 at apache dot org
 * Arvind Prabhakar arvind at apache dot org
 * Henry Saputra hsaputra at apache dot org
 * Juan Jose van der Linden delostilos at apache dot org
 * Kasper Sørensen kaspersor at apache dot org
 * Matt Franklin mfanklin at apache dot org
 * Noah Slater nslater at apache dot org
 * Sameer Arora sarora at apache dot org
 * Tomasz Guzialek tomaszguzialek at apache dot org

 NOW, THEREFORE, BE IT FURTHER RESOLVED, that Kasper Sørensen be
 appointed to the office of Vice President, MetaModel, 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 MetaModel 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 MetaModel
 Project; and be it further

 RESOLVED, that the Apache MetaModel Project be and hereby is tasked
 with the migration and rationalization of the Apache Incubator
 MetaModel podling; and be it further

 RESOLVED, that all responsibilities pertaining to the Apache Incubator
 MetaModel podling encumbered upon the Apache Incubator Project are
 hereafter discharged.




 Thanks,

 Henry
 On behalf of Apache MetaModel incubating PPMCs

 [1] http://incubator.apache.org/projects/metamodel.html
 [2] http://mail-archives.apache.org/mod_mbox/metamodel-dev

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

Re: [VOTE] Accept HTrace into the Apache Incubator

[Arvind Prabhakar]

+1 (binding)

Regards,
Arvind Prabhakar

On Wed, Nov 5, 2014 at 11:36 AM, Roman Shaposhnik r...@apache.org wrote:

 On Wed, Nov 5, 2014 at 11:16 AM, Roman Shaposhnik r...@apache.org wrote:
  Following the discussion earlier in the thread:
 http://s.apache.org/Dk7
 
  I would like to call a VOTE for accepting HTrace
  as a new incubator project.
 
  The proposal is available at:
 
  https://wiki.apache.org/incubator/HTraceProposal
 (a full version of the proposal is attached)
 
  Vote is open until at least Sunday, 9th November 2014, 23:59:00 UTC
 
   [ ] +1 accept Lens in the Incubator
   [ ] ±0
   [ ] -1 because...

 Thanks,
 Roman.

 == Abstract ==
 HTrace is a tracing framework intended for use with distributed
 systems written in java.

 == Proposal ==
 HTrace is an aid for understanding system behavior and for reasoning
 about performance
 issues in distributed systems. HTrace is primarily a low impedance
 library that a java
 distributed system can incorporate to generate ‘breadcrumbs’ or
 ‘traces’ along the path
 of execution, even as it crosses processes and machines. HTrace also
 includes various
 tools and glue for collecting, processing and ‘visualizing’ captured
 execution traces
 for analysis ex post facto of where time was spent and what resources
 were consumed.

 == Background ==
 Distributed systems are made up of multiple software components
 running on multiple
 computers connected by networks. Debugging or profiling operations run
 over non-trivial
 distributed systems -- figuring execution paths and what services,
 machines, and
 libraries participated in the processing of a request -- can be involved.

 == Rationale ==
 Rather than have each distributed system build its own custom
 ‘tracing’ libraries,
 ideally all would use a single project that provides necessary
 primitives and saves
 each project building its own visualizations and processing tools anew.

 Google described “...[a] large-scale distributed systems tracing
 infrastructure”
 in Dapper, a Large-Scale Distributed Systems Tracing Infrastructure. The
 paper
 tells a compelling story of what is possible when disparate systems
 standardize
 on a single tracing library and cooperate, ‘passing the baton’, filling out
 trace context as executions cross systems.

 HTrace aims to provide a rough equivalent in open source of the described
 core
 Dapper tools and library.  As it is adopted by more projects, there will
 be a
 ‘network effect’ as HTrace will provide a more comprehensive view of
 activity
 on the cluster.  For example, as HDFS gets HTrace support, we can connect
 this
 with the HTrace support in HBase to follow HBase requests as they enter
 HDFS.

 Given the success of HTrace depends on its being integrated by many
 projects,
 HTrace should be perceived as unhampered, free of any commercial,
 political,
 or legal ‘taint’. Being an Apache project would help in this regard.

 == Initial Goals ==
 HTrace is a small project of narrow scope but with a grand vision:
   * Move the HTrace source and repository to Apache, a vendor-neutral
 location. Currently HTrace resides at a Cloudera-hosted repository.
   * Add past contributors as committers and institute Apache governance.
   * Evangelize and encourage HTrace diffusion. Initially we will
 continue a focus on the Hadoop space since that is where most of the
 initial contributors work and it is where HTrace has been initially
 deployed.
   * Building out the standalone visualization tool that ships with HTrace.
   * Build more community and add more committers

 == Current Status ==
 Currently HTrace has a viable Java trace library that can be interpolated
 to create ‘traces’.  The work that needs to be done on this library is
 mostly
 bug fixes, ease-of-use improvements, and performance tweaks.  In the
 future,
 we may add libraries for other languages besides Java.

 HTrace has means of dumping traces to the filesystem, Twitters’ Zipkin
 (a tracing
 sink and visualization system developed by Twitter
 https://github.com/twitter/zipkin),
 or Apache HBase.  Executions can be viewed either in Zipkin or in pygraph
 (https://code.google.com/p/python-graph/).

 Since the initial sprint in the summer of 2012 which saw HTrace patches
 proposed
 for Apache HDFS and committed to Apache HBase, development has been
 sporadic;
 mostly a single developer or two adding a feature or bug fixing. HTrace is
 currently undergoing a new “spurt” of development with the effort to get
 HTrace
 added to Apache HDFS revived and a new standalone viewing facility being
 added
 in to HTrace itself.

 HTrace has been integrated by Apache Phoenix.


 === Meritocracy ===
 HTrace, up to this, has been run by Apache committers and PMC members.
 We want to
 build out a diverse developer and user community and run the HTrace
 project in
 the Apache way.  Users and new contributors will be treated with respect
 and
 welcomed; they will earn merit in the project by tendering quality patches

Re: Please Review: IP Clearance for Sqoop Contribution

[Arvind Prabhakar]

(bumping up the thread for IPMC attention)


On Wed, Aug 13, 2014 at 8:38 AM, Arvind Prabhakar arv...@apache.org wrote:

 Dear IPMC:

 Recently Dell Software volunteered the donation of a sizable codebase that
 was built as an extension of Sqoop project. The Sqoop PMC decided in favor
 of including this codebase and the VOTE thread [1] and RESULT [2] are noted
 below for your reference. The work was performed over the next few months
 under the task SQOOP-1287 [3] and was completed on June 29, 2014.

 The Sqoop PMC did due diligence with respect to obtaining the necessary
 software grant and ensuring the ownership rights to the codebase etc, we at
 the time did not fill the IP clearance template as we went along. We now
 have that template filled out and ready for review at [4].

 Please take a moment to review [4] for completeness and accuracy and
 provide your feedback and suggestions as necessary.

 [1] http://s.apache.org/vEF
 [2] http://s.apache.org/Dws
 [3] https://issues.apache.org/jira/browse/SQOOP-1287
 [4]
 http://incubator.apache.org/ip-clearance/sqoop-quest-data-connector.html

 Regards,
 Arvind Prabhakar

 PS - Please note that this email is cross-posted to d...@sqoop.apache.org,
 so please reply-all to ensure that the Sqoop dev list is in the loop for
 this discussion.

Re: Please Review: IP Clearance for Sqoop Contribution

[Arvind Prabhakar]

John,

Thanks for looking through the document. The ticket was primarily filed to
track the development work necessary to merge the codebase. That said, I
understand how it could possibly be better in future to have an umbrella
ticket not only tracks the development part but also all the necessary
non-technical tasks that go with it.

Regards,
Arvind Prabhakar


On Sat, Aug 16, 2014 at 4:11 PM, John D. Ament john.d.am...@gmail.com
wrote:

 Arvind,

 IP clearance is typically by lazy consensus - see [1].  It appears that
 everything is order, assuming you've gone through all the necessary rigors.
  The only weird ting is that the software grant was sent over before the
 ticket was created in your JIRA.  Not saying it can't be, just a little
 odd.

 [1]: http://incubator.apache.org/ip-clearance/


 On Sat, Aug 16, 2014 at 6:19 PM, Arvind Prabhakar arv...@apache.org
 wrote:

  (bumping up the thread for IPMC attention)
 
 
  On Wed, Aug 13, 2014 at 8:38 AM, Arvind Prabhakar arv...@apache.org
  wrote:
 
   Dear IPMC:
  
   Recently Dell Software volunteered the donation of a sizable codebase
  that
   was built as an extension of Sqoop project. The Sqoop PMC decided in
  favor
   of including this codebase and the VOTE thread [1] and RESULT [2] are
  noted
   below for your reference. The work was performed over the next few
 months
   under the task SQOOP-1287 [3] and was completed on June 29, 2014.
  
   The Sqoop PMC did due diligence with respect to obtaining the necessary
   software grant and ensuring the ownership rights to the codebase etc,
 we
  at
   the time did not fill the IP clearance template as we went along. We
 now
   have that template filled out and ready for review at [4].
  
   Please take a moment to review [4] for completeness and accuracy and
   provide your feedback and suggestions as necessary.
  
   [1] http://s.apache.org/vEF
   [2] http://s.apache.org/Dws
   [3] https://issues.apache.org/jira/browse/SQOOP-1287
   [4]
  
 http://incubator.apache.org/ip-clearance/sqoop-quest-data-connector.html
  
   Regards,
   Arvind Prabhakar
  
   PS - Please note that this email is cross-posted to
 d...@sqoop.apache.org
  ,
   so please reply-all to ensure that the Sqoop dev list is in the loop
 for
   this discussion.
  
 

Re: [VOTE] Release Sentry incubating version 1.4.0 (rc0)

[Arvind Prabhakar]

+ 1 (binding)

* Signatures and checksums looks good
* Build OK
* Top-level files look good
* RAT check looks good

Regards,
Arvind Prabhakar


On Mon, Aug 11, 2014 at 11:48 AM, Tuong Tr. ira...@yahoo.com.invalid
wrote:

 Hello IPMC,

 We have passed the PPMC vote for Sentry incubator release 1.4.0-rc0 with 3
 +1  votes from Brock Noland, Jarek Jarcec Cecho, and Sravya Tirukkovalur.
 We ask for your help to vote on this incubator release.



 This is the incubator release of Apache Sentry, version 1.4.0-incubating.
 The list of fixed issues, added features and improvements can be found
 here:
 https://git-wip-us.apache.org/repos/asf?p=incubator-sentry.git;a=blob;f=CHANGELOG.txt;h=962ac73d6b091093ac9ee72b675a3de1b241d242;hb=branch-1.4.0

 Source files : http://people.apache.org/~sravya/sentry-1.4.0-rc0/

 Tag to be voted on is (release 1.4.0-rc0/SHA:
 5e6e34202b26d7d5bc1a41e3dd4ad0cacd123e3f):
 https://git-wip-us.apache.org/repos/asf/incubator-sentry/repo?p=incubator-sentry.git;a=log;h=refs/tags/release-1.4.0

 Sentry's KEYS containing the PGP key we used to sign the release:
 http://www.apache.org/dist/incubator/sentry/KEYS

 Note that this is a source only release and we are voting on the source
 (release 1.4.0-rc0/SHA: 5e6e34202b26d7d5bc1a41e3dd4ad0cacd123e3f).

 Vote will be open for 72 hours.

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


 Thank you for your prompt votes..

 Thanks to Sravya for all her help and guidance...

 Respectfully,

 Sentry 1.4.0 Release Manager (Tuong Truong)

Please Review: IP Clearance for Sqoop Contribution

[Arvind Prabhakar]

Dear IPMC:

Recently Dell Software volunteered the donation of a sizable codebase that
was built as an extension of Sqoop project. The Sqoop PMC decided in favor
of including this codebase and the VOTE thread [1] and RESULT [2] are noted
below for your reference. The work was performed over the next few months
under the task SQOOP-1287 [3] and was completed on June 29, 2014.

The Sqoop PMC did due diligence with respect to obtaining the necessary
software grant and ensuring the ownership rights to the codebase etc, we at
the time did not fill the IP clearance template as we went along. We now
have that template filled out and ready for review at [4].

Please take a moment to review [4] for completeness and accuracy and
provide your feedback and suggestions as necessary.

[1] http://s.apache.org/vEF
[2] http://s.apache.org/Dws
[3] https://issues.apache.org/jira/browse/SQOOP-1287
[4] http://incubator.apache.org/ip-clearance/sqoop-quest-data-connector.html

Regards,
Arvind Prabhakar

PS - Please note that this email is cross-posted to d...@sqoop.apache.org,
so please reply-all to ensure that the Sqoop dev list is in the loop for
this discussion.

Re: [VOTE] Release Apache Metamodel incubating 4.2.0

[Arvind Prabhakar]

+1 (binding, forward from dev vote)

Regards,
Arvind Prabhakar


On Sun, Jul 27, 2014 at 8:55 AM, Kasper Sørensen 
kasper.soren...@humaninference.com wrote:

 Hi All,

 Please vote on releasing the following artifacts as Apache MetaModel
 version 4.2.0-incubating.
 This will be the third incubator release for Metamodel in Apache.

 The Git tag to be voted on is v4.2.0-incubating:

 https://git-wip-us.apache.org/repos/asf?p=incubator-metamodel.git;a=tag;h=refs/tags/MetaModel-4.2.0-incubating

 The source artifact to be voted on is:

 http://repository.apache.org/content/repositories/orgapachemetamodel-1001/org/apache/metamodel/MetaModel/4.2.0-incubating/MetaModel-4.2.0-incubating-source-release.zip

 Parent directory (including MD5, SHA1 hashes etc.) of the source is:
 https://repository.apache.org/content/repositories/orgapachemetamodel-1001/org/apache/metamodel/MetaModel/4.2.0-incubating/

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

 Release engineer public key id: 1FE1C2F5

 Vote thread link from d...@metamodel.incubator.apache.org mailing list:
 http://markmail.org/thread/wmvcudxe6yhijzxb

 Result thread link from d...@metamodel.incubator.apache.org mailing list:
 http://markmail.org/message/bikigx33epufc76i

 Please vote on releasing this package as Apache MetaModel 4.2.0-incubating.

 The vote is open for 72 hours, or until we get the needed number of votes
 (3 +1).

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

 More information about the MetaModel project can be found at
 http://metamodel.incubator.apache.org/

 Thank you in advance for participating.

 Regards,
 Kasper Sørensen
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] fleece as new incubator project

[Arvind Prabhakar]

+1 (binding)

Regards,
Arvind Prabhakar


On Fri, Jun 6, 2014 at 12:31 AM, Romain Manni-Bucau rmannibu...@gmail.com
wrote:

 Following the discussion earlier, I'm calling a vote to accept Fleece as a
 new Incubator project.

  The proposal draft is available at:
 https://wiki.apache.org/incubator/Fleece, and is also included  below.

  Vote is open for at least 72h and closes at the earliest on 09 June 09:30
  GMT.

  [ ] +1 accept Fleece in the Incubator
  [ ] +/-0
  [ ] -1 because...

  Here's my +1.

 
 Apache Fleece Proposal

 Abstract

 Apache Fleece is an implementation of JSR-353 (JavaTM API for JSON
 Processing).

 Proposal

 Apache Fleece will consist of a number of modules. Mainly an implementation
 of JSR-353 but also a set of usefule modules to help with the usage of
 JSR-353 (surely a mapping module and a jaxrs provider module).

 Background

 JSon being more and more important JavaEE 7 specified an API to read and
 create JSon objects/arrays.

 Apache Fleece builds on this specification a potential base to do Json at
 Apache (hopefully it will be integrated with CXF for instance).

 Rationale

 There is not yet a Json related project at Apache but a lot of projects
 rely on some specific implementions (jettison, jackson, others...).
 Proposing a default would be great. The other point is a set of Apache
 projects related to JavaEE (CXF, TomEE, Geronimo, Axis2...) will need an
 implementation. Having one built at Apache is a really nice to have.

 Initial Goals

 The initial goal of the Apache Fleece project is to get a JSR-353 compliant
 implementation

 Current Status

 Initial codebase was developped on github but designed to be integrated in
 Apache.

 Meritocracy

 Initial community will be mainly composed of already Apache committers so
 meritocracy is already something well known.

 Community

 Initial community will be composed of TomEE community for sure, hopefully
 CXF and potentially all JSon users of Apache.

 Initial committers

- Romain Manni-Bucau (individual, ASF)
- Jean-Louis Monteiro (individual, ASF)
- Mark Struberg (individual, ASF member)
- Gerhard Petracek (individual, ASF member)
- David Blevins (individual, ASF member)
- Sagara Gunathunga (ASF)

 Alignment

 Several Apache project will need a JSR-353 implementation. Having a project
 which can be shared is better than having a sub project of a particular
 project. Moreover this project makes sense alone since users can
 integrate it without any other dependencies and use it to read/generate
 Json in their project so it makes sense to create a dedicated project.

 Known Risks

 Main risk is to get a not so active project since the specification is not
 that big.

 Documentation

 There is no documentation to import today but it will be created using
 standard ASF tools (ASF CMS mainly).

 Initial Source

 Initial sources are on this git repository:
 https://github.com/rmannibucau/json-impl.git

 Source and IP Submission Plan

 Initial sources are under Apache license v2.

 Side note: it was really developed to be integrated in this project
 (without waiting it to be created).

 Required Resources

 Mailing Lists

-

- d...@fleece.incubator.apache.org - comm...@fleece.incubator.apache.org
- priv...@fleece.incubator.apache.org

 Version Control

 It is proposed that the source code for the Apache Fleece project be hosted
 in the Apache Git repository, under the following directory:

- git.apache.org/incubator-fleece.git

 Issue Tracking

 The following JIRA project would be required to track issues for the Apache
 Fleece project:

- FLEECE

 Initial Committers

- Romain Manni-Bucau
- Jean-Louis Monteiro
- Mark Struberg
- Gerhard Petracek
- David Blevins

 Sponsors

 Champion

- Mark Struberg

 Nominated Mentors

- Justin Mclean
- Christian Grobmeier
- Daniel Kulp

 Project Name

 Seems *Fleece* is the name which satisfies most of people but we can still
 ask for a new name if we feel it needed before being graduated.
 

 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau

Re: Board Report Reminder

[Arvind Prabhakar]

The Sentry report is in now. In fact, it was ready yesterday but the PPMC
member writing it did not have edit access. We will remedy that going
forward.

Regards,
Arvind Prabhakar


On Sat, Jun 7, 2014 at 7:50 AM, John D. Ament john.d.am...@gmail.com
wrote:

 Hi all

 Don't forget, board reports were due on June 04.  Shepherd reports are
 due tomorrow.

 The following podlings are considered to not have reported this month,
 thus far:

 Brooklyn
 DeviceMap
 Drill
 Kalumet
 MRQL
 S4
 Sentry
 Tajo

 John

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

Re: [VOTE] Accept Parquet into the incubator

[Arvind Prabhakar]

+1 (binding)

Regards,
Arvind Prabhakar


On Sun, May 18, 2014 at 2:15 PM, Chris Aniszczyk caniszc...@gmail.comwrote:

 Based on the results of the discussion thread:

 http://mail-archives.apache.org/mod_mbox/incubator-general/201405.mbox/%3CCAJg1wMRGhLu4P7LeVQB%2B5K0C-fr-pw2448uj%3D6-3zHag4F1EbA%40mail.gmail.com%3E

 I would like to call a vote on accepting Parquet into the incubator.
 https://wiki.apache.org/incubator/ParquetProposal

 [ ] +1 Accept Parquet into the Incubator
 [ ] +0 Indifferent to the acceptance of Parquet
 [ ] -1 Do not accept Parquet because ...

 The vote will be open until Thursday May 22nd 18:00 UTC.

 = Parquet Proposal =

 == Abstract ==
 Parquet is a columnar storage format for Hadoop.

 == Proposal ==

 We created Parquet to make the advantages of compressed, efficient columnar
 data representation available to any project in the Hadoop ecosystem,
 regardless of the choice of data processing framework, data model, or
 programming language.

 == Background ==

 Parquet is built from the ground up with complex nested data structures in
 mind, and uses the repetition/definition level approach to encoding such
 data structures, as popularized by Google Dremel (
 https://blog.twitter.com/2013/dremel-made-simple-with-parquet). We believe
 this approach is superior to simple flattening of nested name spaces.

 Parquet is built to support very efficient compression and encoding
 schemes. Parquet allows compression schemes to be specified on a per-column
 level, and is future-proofed to allow adding more encodings as they are
 invented and implemented. We separate the concepts of encoding and
 compression, allowing parquet consumers to implement operators that work
 directly on encoded data without paying decompression and decoding penalty
 when possible.

 == Rationale ==

 Parquet is built to be used by anyone. We believe that an efficient,
 well-implemented columnar storage substrate should be useful to all
 frameworks without the cost of extensive and difficult to set up
 dependencies.

 Furthermore, the rapid growth of Parquet community is empowered by open
 source. We believe the Apache foundation is a great fit as the long-term
 home for Parquet, as it provides an established process for
 community-driven development and decision making by consensus. This is
 exactly the model we want for future Parquet development.

 == Initial Goals ==

  * Move the existing codebase to Apache
  * Integrate with the Apache development process
  * Ensure all dependencies are compliant with Apache License version 2.0
  * Incremental development and releases per Apache guidelines

 == Current Status ==

 Parquet has undergone 2 major releases:
 https://github.com/Parquet/parquet-format/releases of the core format and
 22 releases: https://github.com/Parquet/parquet-mr/releases of the
 supporting set of Java libraries.

 The Parquet source is currently hosted at GitHub, which will seed the
 Apache git repository.

 === Meritocracy ===

 We plan to invest in supporting a meritocracy. We will discuss the
 requirements in an open forum. Several companies have already expressed
 interest in this project, and we intend to invite additional developers to
 participate. We will encourage and monitor community participation so that
 privileges can be extended to those that contribute.

 === Community ===

 There is a large need for an advanced columnar storage format for Hadoop.
 Parquet is being used in production by many organizations (see
 https://github.com/Parquet/parquet-mr/blob/master/PoweredBy.md)

  * Cloudera: https://twitter.com/HenryR/statuses/324222874011451392
  * Criteo: https://twitter.com/julsimon/statuses/312114074911666177
  * Salesforce: https://twitter.com/TwitterOSS/statuses/392734610116726784
  * Stripe: https://twitter.com/avibryant/statuses/391339949250715648
  * Twitter: https://twitter.com/J_/statuses/315844725611581441

 By bringing Parquet into Apache, we believe that the community will grow
 even bigger.

 === Core Developers ===

 Parquet was initially developed as a collaboration between Twitter,
 Cloudera and Criteo.

 See

 https://blog.twitter.com/2013/announcing-parquet-10-columnar-storage-for-hadoop

 === Alignment ===

 We believe that having Parquet at Apache will help further the growth of
 the big-data community, as it will encourage cooperation within the greater
 ecosystem of projects spawned by Apache Hadoop. The alignment is also
 beneficial to other Apache communities (such as Hadoop, Hive, Avro).

 == Known Risks ==

 === Orphaned Products ===

 The risk of the Parquet project being abandoned is minimal. There are many
 organizations using Parquet in production, including Twitter, Cloudera,
 Stripe, and Salesforce (
 http://blog.cloudera.com/blog/2013/10/parquet-at-salesforce-com/).

 === Inexperience with Open Source ===

 Parquet has existed as a healthy open source for one year. During that
 time, we have curated an open-source community successfully

Re: [VOTE] Release Apache Metamodel incubating 4.1.0-RC1

[Arvind Prabhakar]

+1 (binding)

* Signatures and checksums look good
* Build successfully
* Rat check looks good
 * Top level files look good

Regards,
Arvind Prabhakar


On Sat, May 3, 2014 at 9:53 AM, Kasper Sørensen 
kasper.soren...@humaninference.com wrote:

 Hi All,

 Please vote on releasing the following candidate as Apache MetaModel
 version 4.1.0-RC1-incubating.
 This will be the second incubator release for Metamodel in Apache.

 The Git tag to be voted on is v4.1.0-RC1-incubating:

 https://git-wip-us.apache.org/repos/asf?p=incubator-metamodel.git;a=tag;h=refs/tags/MetaModel-4.1.0-RC1-incubating

 Source zip file can be found here:

 http://repository.apache.org/content/repositories/releases/org/apache/metamodel/MetaModel/4.1.0-RC1-incubating/MetaModel-4.1.0-RC1-incubating-source-release.zip
 (Note: You may notice that the file(s) are in the 'releases' repository
 and not in a staging repo. By mistake the staging directory was prematurely
 released in Nexus. This was a mixup in the release procedure by the new
 Release Engineer (me) - very sorry about that mistake).

 MD5 hash of the source zip file: ca79678bb109e96e057d5d9e49225088
 SHA1 hash of the source zip file: d3ecb896cf6683fd3245896a830eac6ac6cc9591

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

 Release engineer public key id: 1FE1C2F5

 Vote thread link from d...@metamodel.incubator.apache.org mailing list:
 http://markmail.org/message/ttthjjl4lpfsghil

 Result thread link from d...@metamodel.incubator.apache.org mailing list:
 http://markmail.org/message/rxj75uc5h3ump2kw

 Please vote on releasing this package as Apache MetaModel
 4.1.0-RC1-incubating.

 The vote is open for 72 hours, or until we get the needed number of votes
 (3 +1).

 [ ] +1 Release this package as Apache MetaModel 4.1.0-RC1-incubating
 [ ] -1 Do not release this package because...

 More information about the MetaModel project can be found at
 http://metamodel.incubator.apache.org/

 Thank you in advance for participating.

 Regards,
 Kasper Sørensen
 -
 To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
 For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Sentry incubating version 1.3.0-rc3

[Arvind Prabhakar]

+1 (binding)

Signatures and builds look good. Top level files seem OK.

Regards,
Arvind Prabhakar


On Thu, May 1, 2014 at 11:12 PM, Ramachandran, Karthik 
kramachand...@iqt.org wrote:

 This is a release of Apache Sentry, version 1.3.0-incubating.

 It fixes the following issues:  http://s.apache.org/iCB

 Source files : http://people.apache.org/~kramachandran/sentry-1.3.0-rc3/

 Tag to be voted on (release-1.3.0-rc3 / SHA
 31c8aca46c060685bd5a01f7706e2adab78a20d8):
 https://git-wip-us.apache.org/repos/asf/incubator-sentry/repo?p=incubator-s
 entry.git;a=log;h=refs/tags/release-1.3.0-rc3

 The dev list thread for the passing vote (4 +1s with 1 IPMC vote) can be
 Found at:
 http://mail-archives.apache.org/mod_mbox/incubator-sentry-dev/201405.mbox/%
 3CCF887D8B.14633%25kramachandran%40iqt.org%3E

 Sentry's KEYS containing the PGP key we used to sign the
 release:https://people.apache.org/keys/group/sentry.asc

 Note that this is a source only release and we are voting on the
 source (release-1.3.0-rc3 / SHA: 31c8aca46c060685bd5a01f7706e2adab78a20d8).


 Vote will be open for 72 hours.

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


 Thanks,
 Karthik Ramachandran





 This e-mail, and any attachments hereto, may contain information that is
 privileged, proprietary, confidential and/or exempt from disclosure under
 law and are intended only for the designated addressee(s). If you are not
 the intended recipient of this message, or a person authorized to receive
 it on behalf of the intended recipient, you are hereby notified that you
 must not use, disseminate, copy in any form, or take any action based upon
 the email or information contained therein. If you have received this email
 in error, please permanently and immediately delete it and any copies of
 it, including any attachments, and promptly notify the sender at In-Q-Tel
 by reply e-mail, fax: 703-248-3001, or phone: 703-248-3000. Thank you for
 your cooperation.

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

Re: [VOTE] Accept DataFu into the Incubator

[Arvind Prabhakar]

+1 (binding)

Regards,
Arvind Prabhakar


On Tue, Dec 31, 2013 at 12:39 PM, Jakob Homan jgho...@gmail.com wrote:

 Incubator-

 Following the discussion earlier, I'm calling a vote to accept DataFu as a
 new Incubator project.

 The proposal draft is available at:
 https://wiki.apache.org/incubator/DataFuProposal, and is also included
 below.

 Vote is open for at least 96h and closes at the earliest on 4 Jan 13:00
 PDT.  I'm letting the vote run an extra day as we're in the holiday season.

 [ ] +1 accept DataFu in the Incubator
 [ ] +/-0
 [ ] -1 because...

 Here's my binding +1.
 -Jakob

 ---
 Abstract

 DataFu makes it easier to solve data problems using Hadoop and higher level
 languages based on it.

 Proposal

 DataFu provides a collection of Hadoop MapReduce jobs and functions in
 higher level languages based on it to perform data analysis. It provides
 functions for common statistics tasks (e.g. quantiles, sampling), PageRank,
 stream sessionization, and set and bag operations. DataFu also provides
 Hadoop jobs for incremental data processing in MapReduce.

 Background

 DataFu began two years ago as set of UDFs developed internally at LinkedIn,
 coming from our desire to solve common problems with reusable components.
 Recognizing that the community could benefit from such a library, we added
 documentation, an extensive suite of unit tests, and open sourced the code.
 Since then there have been steady contributions to DataFu as we encountered
 common problems not yet solved by it. Others outside LinkedIn have
 contributed as well. More recently we recognized the challenges with
 efficient incremental processing of data in Hadoop and have contributed a
 set of Hadoop MapReduce jobs as a solution.

 DataFu began as a project at LinkedIn, but it has shown itself to be useful
 to other organizations and developers as well as they have faced similar
 problems. We would like to share DataFu with the ASF and begin developing a
 community of developers and users within Apache.

 Rationale

 There is a strong need for well tested libraries that help developers solve
 common data problems in Hadoop and higher level languages such as Pig,
 Hive, Crunch, Scalding, etc.

 Current Status

 Meritocracy

 Our intent with this incubator proposal is to start building a diverse
 developer community around DataFu following the Apache meritocracy model.
 Since DataFu was initially open sourced in 2011, it has received
 contributions from both within and outside LinkedIn. We plan to continue
 support for new contributors and work with those who contribute
 significantly to the project to make them committers.

 Community

 DataFu has been building a community of developers for two years. It began
 with contributors from LinkedIn and has received contributions from
 developers at Cloudera since very early on. It has been included included
 in Cloudera’s Hadoop Distribution and Apache Bigtop. We hope to extend our
 contributor base significantly and invite all those who are interested in
 solving large-scale data processing problems to participate.

 Core Developers

 DataFu has a strong base of developers at LinkedIn. Matthew Hayes initiated
 the project in 2011, and aside from continued contributions to DataFu has
 also contributed the sub-project Hourglass for incremental MapReduce
 processing. Separate from DataFu he has also open sourced the White
 Elephant project. Sam Shah contributed a significant portion of the
 original code and continues to contribute to the project. William Vaughan
 has been contributing regularly to DataFu for the past two years. Evion Kim
 has been contributing to DataFu for the past year. Xiangrui Meng recently
 contributed implementations of scalable sampling algorithms based on
 research from a paper he published. Chris Lloyd has provided some important
 bug fixes and unit tests. Mitul Tiwari has also contributed to DataFu.
 Mathieu Bastian has been developing MapReduce jobs that we hope to include
 in DataFu. In addition he also leads the open source Gephi project.

 Alignment

 The ASF is the natural choice to host the DataFu project as its goal of
 encouraging community-driven open-source projects fits with our vision for
 DataFu. Additionally, other projects DataFu integrates with, such as Apache
 Pig and Apache Hadoop, and in the future Apache Hive and Apache Crunch, are
 hosted by the ASF and we will benefit and provide benefit by close
 proximity to them.

 Known Risks

 Orphaned Products

 The core developers have been contributing to DataFu for the past two
 years. There is very little risk of DataFu being abandoned given its
 widespread use within LinkedIn.

 Inexperience with Open Source

 DataFu was started as an open source project in 2011 and has remained so
 for two years. Matt initiated the project, and additionally is the creator
 of the open source White Elephant project. He has also contributed patches
 to Apache Pig. Most recently he has

Re: [VOTE] Accept Twill for Incubation

[Arvind Prabhakar]

+1 (binding)

Regards,
Arvind Prabhakar


On Thu, Nov 7, 2013 at 1:04 PM, Andreas Neumann a...@apache.org wrote:

 The discussion about the Weave proposal has calmed. As the outcome of the
 discussion, we have chosen a new name for the project, Twill. I would like
 to call a vote for Twill to become an incubated project.

 The proposal is pasted below, and also available at:
 https://wiki.apache.org/incubator/TwillProposal

 Let's keep this vote open for three business days, closing the voting on
 Tuesday 11/12.

 [ ] +1 Accept Twill into the Incubator
 [ ] +0 Don't care.
 [ ] -1 Don't accept Twill because...

 -Andreas.

 = Abstract =

 Twill is an abstraction over Apache Hadoop® YARN that reduces the
 complexity of developing distributed applications, allowing developers to
 focus more on their business logic.

 = Proposal =

 Twill is a set of libraries that reduces the complexity of developing
 distributed applications. It exposes the distributed capabilities of Apache
 Hadoop® YARN via a simple and intuitive programming model similar to Java
 threads. Twill also has built-in capabilities required by many distributed
 applications, such as real-time application logs and metrics collection,
 application lifecycle management, and network service discovery.

 = Background =

 Hadoop YARN is a generic cluster resource manager that supports any type of
 distributed application. However, YARN’s interfaces are too low level for
 rapid application development. It requires a great deal of boilerplate code
 even for a simple application, creating a high ramp up cost that can turn
 developers away.

 Twill is designed to improve this situation with a programming model that
 makes running distributed applications as easy as running Java threads.
 With the abstraction provided by Twill, applications can be executed in
 process threads during development and unit testing and then be deployed to
 a YARN cluster without any modifications.

 Twill also has built-in support for real-time application logs and metrics
 collection, delegation token renewal, application lifecycle management, and
 network service discovery. This greatly reduces the pain that developers
 face when developing, debugging, deploying and monitoring distributed
 applications.

 Twill is not a replacement for YARN, it’s a framework that operates on top
 of YARN.

 = Rationale =

 Developers who write YARN applications typically find themselves
 implementing the same (or similar) boilerplate code over and over again
 for every application. It makes sense to distill this common code into a
 reusable set of libraries that is perpetually maintained and improved by a
 diverse community of developers.

 Twill’s simple thread-like programming model will enable many Java
 programmers to develop distributed applications. We believe that this
 simplicity will attract developers who would otherwise be discouraged by
 complexity, and many new use cases will emerge for the usage of YARN.

 Incubating Twill as an Apache project makes sense because Twill is a
 framework built on top of YARN, and Twill uses Apache Zookeeper, HDFS,
 Kafka, and other Apache software (see the External Dependencies section).

 = Current Status =

 Twill was initially developed at Continuuity under the name of Weave. The
 Weave codebase is currently hosted in a public repository at github.com,
 which will seed the Apache git repository after renaming to Twill.

 == Meritocracy ==

 Our intent with this incubator proposal is to start building a diverse
 developer community around Twill following the Apache meritocracy model.
 Since Twill was initially developed in early 2013, we have had fast
 adoption and contributions within Continuuity. We are looking forward to
 new contributors. We wish to build a community based on Apache's
 meritocracy principles, working with those who contribute significantly to
 the project and welcoming them to be committers both during the incubation
 process and beyond.

 == Community ==

 Twill is currently being used internally at Continuuity and is at the core
 of our products. We hope to extend our contributor base significantly and
 we will invite all who are interested in simplifying the development of
 distributed applications to participate.

 == Core Developers ==

 Twill is currently being developed by five engineers at Continuuity:
 Terence Yim, Andreas Neumann, Gary Helmling, Poorna Chandra and Albert
 Shau.
 Terence Yim is an Apache committer for Helix, Andreas is an Apache
 committer and PMC member for Oozie, and Gary Helmling is an Apache
 committer and PMC member for HBase. Poorna Chandra and Albert Shau have
 made many contributions to Twill.

 == Alignment ==

 The ASF is the natural choice to host the Twill project as its goal of
 encouraging community-driven open source projects fits with our vision for
 Twill.

 Additionally, many other projects with which we are familiar and expect
 Twill to integrate with, such as ZooKeeper, YARN

Re: [VOTE] Accept Storm into the Incubator

[Arvind Prabhakar]

[X] +1 Accept Storm into the Incubator

Regards,
Arvind Prabhakar


On Thu, Sep 12, 2013 at 12:19 PM, Doug Cutting cutt...@apache.org wrote:

 Discussion about the Storm proposal has subsided, issues raised now
 seemingly resolved.

 I'd like to call a vote to accept Storm as a new Incubator podling.

 The proposal is included below and is also at:

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

 Let's keep the vote open for four working days, until 18 September.

 [ ] +1 Accept Storm into the Incubator
 [ ] +0 Don't care.
 [ ] -1 Don't accept Storm because...

 Doug


 = Storm Proposal =

 == Abstract ==

 Storm is a distributed, fault-tolerant, and high-performance realtime
 computation system that provides strong guarantees on the processing
 of data.

 == Proposal ==

 Storm is a distributed real-time computation system. Similar to how
 Hadoop provides a set of general primitives for doing batch
 processing, Storm provides a set of general primitives for doing
 real-time computation. Its use cases span stream processing,
 distributed RPC, continuous computation, and more. Storm has become a
 preferred technology for near-realtime big-data processing by many
 organizations worldwide (see a partial list at
 https://github.com/nathanmarz/storm/wiki/Powered-By). As an open
 source project, Storm’s developer community has grown rapidly to 46
 members.

 == Background ==

 The past decade has seen a revolution in data processing. MapReduce,
 Hadoop, and related technologies have made it possible to store and
 process data at scales previously unthinkable. Unfortunately, these
 data processing technologies are not realtime systems, nor are they
 meant to be. The lack of a Hadoop of realtime has become the biggest
 hole in the data processing ecosystem. Storm fills that hole.

 Storm was initially developed and deployed at BackType in 2011. After
 7 months of development BackType was acquired by Twitter in July 2011.
 Storm was open sourced in September 2011.

 Storm has been under continuous development on its Github repository
 since being open-sourced. It has undergone four major releases (0.5,
 0.6, 0.7, 0.8) and many minor ones.


 == Rationale ==

 Storm is a general platform for low-latency big-data processing. It is
 complementary to the existing Apache projects, such as Hadoop. Many
 applications are actually exploring using both Hadoop and Storm for
 big-data processing. Bringing Storm into Apache is very beneficial to
 both Apache community and Storm community.

 The rapid growth of Storm community is empowered by open source. We
 believe the Apache foundation is a great fit as the long-term home for
 Storm, as it provides an established process for community-driven
 development and decision making by consensus. This is exactly the
 model we want for future Storm development.

 == Initial Goals ==

* Move the existing codebase to Apache
* Integrate with the Apache development process
* Ensure all dependencies are compliant with Apache License version 2.0
* Incremental development and releases per Apache guidelines

 == Current Status ==

 Storm has undergone four major releases (0.5, 0.6, 0.7, 0.8) and many
 minor ones. Storm 0.9 is about to be released. Storm is being used in
 production by over 50 organizations. Storm codebase is currently
 hosted at github.com, which will seed the Apache git repository.

 === Meritocracy ===

 We plan to invest in supporting a meritocracy. We will discuss the
 requirements in an open forum. Several companies have already
 expressed interest in this project, and we intend to invite additional
 developers to participate. We will encourage and monitor community
 participation so that privileges can be extended to those that
 contribute.

 === Community ===

 The need for a low-latency big-data processing platform in the open
 source is tremendous. Storm is currently being used by at least 50
 organizations worldwide (see
 https://github.com/nathanmarz/storm/wiki/Powered-By), and is the most
 starred Java project on Github. By bringing Storm into Apache, we
 believe that the community will grow even bigger.

 === Core Developers ===

 Storm was started by Nathan Marz at BackType, and now has developers
 from Yahoo!, Microsoft, Alibaba, Infochimps, and many other companies.

 === Alignment ===

 In the big-data processing ecosystem, Storm is a very popular
 low-latency platform, while Hadoop is the primary platform for batch
 processing. We believe that it will help the further growth of
 big-data community by having Hadoop and Storm aligned within Apache
 foundation. The alignment is also beneficial to other Apache
 communities (such as Zookeeper, Thrift, Mesos). We could include
 additional sub-projects, Storm-on-YARN and Storm-on-Mesos, in the near
 future.

 == Known Risks ==

 === Orphaned Products ===

 The risk of the Storm project being abandoned is minimal. There are at
 least 50 organizations (Twitter, Yahoo!, Microsoft, Groupon, Baidu

Re: [PROPOSAL] Storm for Apache Incubator

[Arvind Prabhakar]

+1 (binding)

Note that I fixed a minor typo in my name on the Wiki.

Regards,
Arvind Prabhakar


On Wed, Sep 4, 2013 at 1:07 AM, Nathan Marz nat...@nathanmarz.com wrote:

 Hi everyone,

 I'd like to propose Storm to be an Apache Incubator project. After much
 thought I believe this is the right next step for the project, and I look
 forward to hearing everyone's thoughts and feedback!

 Here's a link to the proposal:
 https://wiki.apache.org/incubator/StormProposal

 The proposal is also pasted below.

 -Nathan


 = Storm Proposal =

 == Abstract ==

 Storm is a distributed, fault-tolerant, and high-performance realtime
 computation system that provides strong guarantees on the processing of
 data.

 == Proposal ==

 Storm is a distributed real-time computation system. Similar to how Hadoop
 provides a set of general primitives for doing batch processing, Storm
 provides a set of general primitives for doing real-time computation. Its
 use cases span stream processing, distributed RPC, continuous computation,
 and more. Storm has become a preferred technology for near-realtime
 big-data processing by many organizations worldwide (see a partial list at
 https://github.com/nathanmarz/storm/wiki/Powered-By). As an open source
 project, Storm’s developer community has grown rapidly to 46 members.

 == Background ==

 The past decade has seen a revolution in data processing. MapReduce,
 Hadoop, and related technologies have made it possible to store and process
 data at scales previously unthinkable. Unfortunately, these data processing
 technologies are not realtime systems, nor are they meant to be. The lack
 of a Hadoop of realtime has become the biggest hole in the data
 processing ecosystem. Storm fills that hole.

 Storm was initially developed and deployed at BackType in 2011. After 7
 months of development BackType was acquired by Twitter in July 2011. Storm
 was open sourced in September 2011.

 Storm has been under continuous development on its Github repository since
 being open-sourced. It has undergone four major releases (0.5, 0.6, 0.7,
 0.8) and many minor ones.

 == Rationale ==

 Storm is a general platform for low-latency big-data processing. It is
 complementary to the existing Apache projects, such as Hadoop. Many
 applications are actually exploring using both Hadoop and Storm for
 big-data processing. Bringing Storm into Apache is very beneficial to both
 Apache community and Storm community.

 The rapid growth of Storm community is empowered by open source. We believe
 the Apache foundation is a great fit as the long-term home for Storm, as it
 provides an established process for community-driven development and
 decision making by consensus. This is exactly the model we want for future
 Storm development.

 == Initial Goals ==

   * Move the existing codebase to Apache
   * Integrate with the Apache development process
   * Ensure all dependencies are compliant with Apache License version 2.0
   * Incremental development and releases per Apache guidelines

 == Current Status ==

 Storm has undergone four major releases (0.5, 0.6, 0.7, 0.8) and many minor
 ones. Storm 0.9 is about to be released. Storm is being used in production
 by over 50 organizations. Storm codebase is currently hosted at github.com
 ,
 which will seed the Apache git repository.

 === Meritocracy ===

 We plan to invest in supporting a meritocracy. We will discuss the
 requirements in an open forum. Several companies have already expressed
 interest in this project, and we intend to invite additional developers to
 participate. We will encourage and monitor community participation so that
 privileges can be extended to those that contribute.

 === Community ===

 The need for a low-latency big-data processing platform in the open source
 is tremendous. Storm is currently being used by at least 50 organizations
 worldwide (see https://github.com/nathanmarz/storm/wiki/Powered-By), and
 is
 the most starred Java project on Github. By bringing Storm into Apache, we
 believe that the community will grow even bigger.

 === Core Developers ===

 Storm was started by Nathan Marz at BackType, and now has developers from
 Yahoo!, Microsoft, Alibaba, Infochimps, and many other companies.

 === Alignment ===

 In the big-data processing ecosystem, Storm is a very popular low-latency
 platform, while Hadoop is the primary platform for batch processing. We
 believe that it will help the further growth of big-data community by
 having Hadoop and Storm aligned within Apache foundation. The alignment is
 also beneficial to other Apache communities (such as Zookeeper, Thrift,
 Mesos). We could include additional sub-projects, Storm-on-YARN and
 Storm-on-Mesos, in the near future.

 == Known Risks ==

 === Orphaned Products ===

 The risk of the Storm project being abandoned is minimal. There are at
 least 50 organizations (Twitter, Yahoo!, Microsoft, Groupon, Baidu,
 Alibaba, Alipay, Taobao, PARC, RocketFuel etc) are highly

Re: [VOTE] Graduate Apache Curator as an Apache Top Level Project

[Arvind Prabhakar]

+1 (binding)

Regards,
Arvind Prabhakar




On Wed, Aug 28, 2013 at 10:44 AM, Jordan Zimmerman 
jor...@jordanzimmerman.com wrote:

 This message is opening a VOTE to graduate the Apache Curator podling from
 the Apache Incubator as an Apache Top Level Project.

 Apache Curator entered the Incubator in April of 2013. We have made
 significant progress with the project since moving to Apache. We currently
 have 4 committers listed on our status page [1] including 2 who were
 accepted after the podling was formed.  A VOTE was held on the curator-dev
 group with 8 binding +1 and 2 non-binding +1 votes for graduation [2]. A
 VOTE was also held to adopt the graduation resolution (below) with 7 +1
 votes for acceptance [3]. According to Ohloh, Curator has a large, active
 development team [4].

 During incubation, Curator:
 * Produced 4 releases
 * Added 2 new Committer/PPMC members and showed constant community
 activities
 * Cleared IP on code
 * Developed roadmap(s) for major and minor releases in a community process
 [5]
 * Established that Apache Curator is a suitable name [6]
 * Showed that its community is active, healthy, and growing and has
 demonstrated the ability to self-govern using accepted Apache practices

 Please cast your vote:
 [ ] +1 Graduate the Apache Curator podling from Apache Incubator as a TLP
 [ ] +0 Indifferent to the graduation status of Apache Curator podling
 [ ] -1 Reject graduation of Apache Curator podling from Apache Incubator
 because ...

 We'll run the vote for at least 72 hours.

 [1] http://curator.incubator.apache.org/team-list.html#Contributors
 [2]
 http://mail-archives.apache.org/mod_mbox/incubator-curator-dev/201308.mbox/%3C44CD80F8-10B1-4FBA-A9D9-6DDEA7280FA5%40jordanzimmerman.com%3E
 [3]
 http://mail-archives.apache.org/mod_mbox/incubator-curator-dev/201308.mbox/%3C3859DF43-460C-406E-B816-DD9F4049B4DC%40jordanzimmerman.com%3E
 [4] http://www.ohloh.net/p/apache-curator/factoids#FactoidTeamSizeLarge
 [5]
 https://issues.apache.org/jira/browse/CURATOR#selectedTab=com.atlassian.jira.plugin.system.project%3Aroadmap-panel
 [6] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-28

 Sincerely,

 The Apache Curator Team

 Resolution:

 X. Establish the Apache Curator 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 library and tools for working with
Apache ZooKeeper.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the Apache Curator Project,
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further

RESOLVED, that the Apache Curator Project be and hereby is
responsible for the creation and maintenance of software
related to a library and tools for working with Apache ZooKeeper;
and be it further

RESOLVED, that the office of Vice President, Apache Curator 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 Curator Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache Curator 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 Curator Project:

  * Jordan Zimmerman (randgalt)
  * Jay Zarfoss (zarfide)
  * Eric Tschetter (cheddar)
  * Ioannis Canellos (iocanel)
  * Patrick Hunt (phunt)
  * Mahadev Konar (mahadev)
  * Luciano Resende (lresende)
  * Enis Söztutar (enis)

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Jordan Zimmerman
be appointed to the office of Vice President, Apache Curator, 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 Curator 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 Curator Project; and be it further

RESOLVED, that the Apache Curator Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator Curator podling; and be it further

RESOLVED, that all responsibilities pertaining to the Apache
Incubator Curator podling encumbered upon the Apache Incubator

Re: [VOTE] Accept Apache MetaModel into the Apache incubator

[Arvind Prabhakar]

[X] +1 Accept MetaModel into the Apache incubator (binding)

Regards,
Arvind Prabhakar

On Thu, Jun 6, 2013 at 3:30 PM, Henry Saputra henry.sapu...@gmail.comwrote:

 Hi All,

 I'd like to call a VOTE for acceptance of MetaModel into the Apache
 incubator.
 The vote will close on June 12, 2013 at 6:00 PM (PST).

 [] +1 Accept MetaModel into the Apache incubator
 [] +0 Don't care.
 [] -1 Don't accept MetaModel into the incubator because...

 Full proposal is pasted at the bottom on this email, and the corresponding
 wiki
 is:
 http://wiki.apache.org/incubator/MetaModelProposal.

 Only VOTEs from Incubator PMC members are binding, but all are welcome to
 express their thoughts.

 Thanks,

 Henry Saputra
 Champion for Apache MetaModel


 P.S. Here's my +1 (binding)


 -

 = MetaModel – uniform data access across datastores =

 Proposal for Apache Incubator

 == Abstract ==

 MetaModel is a data access framework, providing a common interface for
 exploration and querying of different types of datastores.

 == Proposal ==

 MetaModel provides a uniform meta-model for exploring and querying the
 structure of datastores, covering but not limited to relational databases,
 various data file formats, NoSQL databases, Salesforce.com, SugarCRM and
 more. The scope of the project is to stay domain-agnostic, so the
 meta-model will be concerned with schemas, tables, columns, rows,
 relationships etc.

 On top of this meta-model a rich querying API is provided which resembles
 SQL, but built using compiler-checked Java language constructs. For
 datastores that do not have a native SQL-compatible query engine, the
 MetaModel project also includes an abstract Java-based query engine
 implementation which individual datastore-modules can adapt to fit the
 concrete datastore.

 === Background ===

 The MetaModel project was initially developed by eobject.dk to service the
 DataCleaner application (http://datacleaner.org). The main requirement was
 to perform data querying and modification operations on a wide range of
 quite different datastores. Furthermore a programmatic query model was
 needed in order to allow different components to influence the query plan.

 In 2009, Human Inference acquired the eobjects projects including
 MetaModel. Since then MetaModel has been put to extensive use in the Human
 Inference products. The open source nature of the project was reinforced,
 leading to a significant growth in the community.

 MetaModel has successfully been used in a number of other open source
 projects as well as mission critical commercial software from Human
 Inference. Currently MetaModel is hosted at http://metamodel.eobjects.org.

 === Rationale ===

 Different types of datastores have different characteristics, which always
 lead to the interfaces for these being different from one another.
 Standards like JDBC and the SQL language attempt to standardize data
 access, but for some datastore types like flat files, spreadsheets, NoSQL
 databases and more, such standards are not even implementable.

 Specialization in interfaces obviously has merit for optimized usage, but
 for integration tools, batch applications and or generic data modification
 tools, this myriad of specialized interfaces is a big pain. Furthermore,
 being able to query every datastore with a basic set of SQL-like features
 can be a great productivity boost for a wide range of applications.

 === Initial goals ===

 MetaModel is already a stable project, so initial goals are more oriented
 towards an adaption to the Apache ecosystem than about functional changes.

 We are constantly adding more datastore types to the portfolio, but the
 core modules have not had drastic changes for some time.

 Our focus will be on making ties with other Apache projects (such as POI,
 Gora, HBase and CouchDB) and potentially renaming the ‘MetaModel’ project
 to something more rememberable.
 This includes comply with Apache Software Foundation license for third
 party dependencies.

 == Current status ==

 === Meritocracy ===

 We intend to do everything we can to encourage a meritocracy in the
 development of MetaModel. Currently most important development and design
 decisions have been made at Human Inference, but with an open window for
 anyone to participate on mailing lists and discussion forums. We believe
 that the approach going forward should be more encouraging by sharing all
 the design ideas and discussions in the open, not only just the topics that
 have been “dragged” into the open by third parties.  We believe that
 meritocracy will be further stimulated by granting the control of the
 project to an independent committee.

 === Community ===

 The community around MetaModel already exists, but we believe it will grow
 substantially by becoming an Apache project. With MetaModel used in a wide
 range of both open and closed source application, both at Human Inference
 (HIquality MDM), it’s open source

Re: [PROPOSAL] MetaModel for the Apache Incubator

[Arvind Prabhakar]

Henry,

Thank you for submitting this proposal. I am very glad to be a mentor for
this project and look forward to working with you and the broader
community. I have a couple of comments with regards to the stated proposal -

First - as noted in the proposal MetaModel has been an open source project
with contributions coming from various corners of the world. Given this
development model, do the individual contributors hold copyright over their
contributed code? If so, you will likely need their consent in order to
provide this code to the Incubator for the purposes of starting this
project.

Second - I noticed that the proposal calls out the LGPL dependency that
will be removed before sourcing the initial drop. Along the same lines, I
urge you to go through the the legal FAQ [1] to make sure that there are no
other dependencies that merit removal or special handling.

[1] http://www.apache.org/legal/resolved.html

Regards,
Arvind Prabhakar


On Tue, May 28, 2013 at 11:20 AM, Henry Saputra henry.sapu...@gmail.comwrote:

 Dear ASF members,

 We would like to propose MetaModel for the incubator.

 Matt Franklin will be the Champion for this project and the proposal draft
 is available at:

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

 Looking forward to all of your suggestions and feedback.

 Thanks,

 Henry Saputra



 -

 = MetaModel – uniform data access across datastores =

 Proposal for Apache Incubator

 == Abstract ==

 MetaModel is a data access framework, providing a common interface for
 exploration and querying of different types of datastores.

 == Proposal ==

 MetaModel provides a uniform meta-model for exploring and querying the
 structure of datastores, covering but not limited to relational databases,
 various data file formats, NoSQL databases, Salesforce.com, SugarCRM and
 more. The scope of the project is to stay domain-agnostic, so the
 meta-model will be concerned with schemas, tables, columns, rows,
 relationships etc.

 On top of this meta-model a rich querying API is provided which resembles
 SQL, but built using compiler-checked Java language constructs. For
 datastores that do not have a native SQL-compatible query engine, the
 MetaModel project also includes an abstract Java-based query engine
 implementation which individual datastore-modules can adapt to fit the
 concrete datastore.

 === Background ===

 The MetaModel project was initially developed by eobject.dk to service the
 DataCleaner application (http://datacleaner.org). The main requirement was
 to perform data querying and modification operations on a wide range of
 quite different datastores. Furthermore a programmatic query model was
 needed in order to allow different components to influence the query plan.

 In 2009, Human Inference acquired the eobjects projects including
 MetaModel. Since then MetaModel has been put to extensive use in the Human
 Inference products. The open source nature of the project was reinforced,
 leading to a significant growth in the community.

 MetaModel has successfully been used in a number of other open source
 projects as well as mission critical commercial software from Human
 Inference. Currently MetaModel is hosted at http://metamodel.eobjects.org.

 === Rationale ===

 Different types of datastores have different characteristics, which always
 lead to the interfaces for these being different from one another.
 Standards like JDBC and the SQL language attempt to standardize data
 access, but for some datastore types like flat files, spreadsheets, NoSQL
 databases and more, such standards are not even implementable.

 Specialization in interfaces obviously has merit for optimized usage, but
 for integration tools, batch applications and or generic data modification
 tools, this myriad of specialized interfaces is a big pain. Furthermore,
 being able to query every datastore with a basic set of SQL-like features
 can be a great productivity boost for a wide range of applications.

 === Initial goals ===

 MetaModel is already a stable project, so initial goals are more oriented
 towards an adaption to the Apache ecosystem than about functional changes.

 We are constantly adding more datastore types to the portfolio, but the
 core modules have not had drastic changes for some time.

 Our focus will be on making ties with other Apache projects (such as POI,
 Gora, HBase and CouchDB) and potentially renaming the ‘MetaModel’ project
 to something more rememberable.
 This includes comply with Apache Software Foundation license for third
 party dependencies.

 == Current status ==

 === Meritocracy ===

 We intend to do everything we can to encourage a meritocracy in the
 development of MetaModel. Currently most important development and design
 decisions have been made at Human Inference, but with an open window for
 anyone to participate on mailing lists and discussion forums. We believe
 that the approach going forward should

Re: [REQUEST FOR MENTORS] Request for mentors to help bring MetaModel into ASF incubator

[Arvind Prabhakar]

Done - added my name to the mentor list on the proposal.

Question for the broader IPMC: are there any specific concerns about this
proposal that is making it less attractive for other mentors to step up? If
so, it will be great if you could bring them up for discussion to help
educate the project team and maybe even find a way to address them.

Regards,
Arvind

On Thu, Apr 11, 2013 at 11:23 PM, Henry Saputra henry.sapu...@gmail.comwrote:

 Thanks Arvind, really appreciate it. Your help is greatly appreciate it.

 Please do add your name to the MetaModel proposal wiki page.

 - Henry


 On Thu, Apr 11, 2013 at 4:03 PM, Arvind Prabhakar arv...@apache.org
 wrote:

  Hi Henry and Kasper,
 
  I have seen the request for soliciting mentors for MetaModel come up a
 few
  times on the general list and apologize for not stepping up earlier. Part
  of my hesitation is that I have not been a mentor to other projects
 before
  and hence am not sure if I can do justice to this request. That said, I
 am
  happy to volunteer myself as a mentor if you don't mind bearing the cost
 of
  my learning curve.
 
  It would be great if more experienced mentors out there can find sometime
  to help guide this project to successful incorporation within Apache.
 
  Regards,
  Arvind Prabhakar
 
  On Thu, Apr 11, 2013 at 12:21 AM, Kasper Sørensen 
  kasper.soren...@humaninference.com wrote:
 
   Hi Ross,
  
   I think MetaModel could potentially have an oData module as well,
 making
   it possible to use an oData source just like any other data source. I
  think
   the main difference between oData and MetaModel, if you look at it
 from a
   helicopter view, is that oData attempts to standardize the server side
 of
   things by building a uniform protocol. MetaModel attempts to
 standardize
   the client side of things, by having a common abstraction layer. Thus,
   MetaModel does not have any specific protocol, just an API. There's
 pros
   and cons of that of course, but in deed both client side and server
 side
   standardization is attractive to have. So a MetaModel-oData module
 would
  be
   cool, making it possible to work with your sharepoint or netflix
 systems,
   just like you would work with your JDBC database or CSV file :)
  
   Kasper Sørensen
  
  
   -Original Message-
   From: Ross Gardler [mailto:rgard...@opendirective.com]
   Sent: 11. april 2013 09:09
   To: general
   Subject: Re: [REQUEST FOR MENTORS] Request for mentors to help bring
   MetaModel into ASF incubator
  
   MetaModel looks to overlap somewhat with the oData initiative [1]. Is a
   relationship worth exploring?
  
   Ross
  
   [1] http://www.odata.org
  
   Sent from a mobile device, please excuse mistakes and brevity On 10 Apr
   2013 22:35, Henry Saputra henry.sapu...@gmail.com wrote:
  
Hi All,
   
I am soliciting for help from ASF IPMCs to mentor and/or champion the
proposed MetaModel incubator project:
http://wiki.apache.org/incubator/MetaModelProposal
   
We are still working on the proposal but would like to get help from
experienced IPMC to drive this project during incubation.
   
Any IPMC that are interested and have bandwidth to help is greatly
appreciated.
   
   
Thanks,
   
- Henry
   
  
   -
   To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
   For additional commands, e-mail: general-h...@incubator.apache.org
  
  
 

Re: [REQUEST FOR MENTORS] Request for mentors to help bring MetaModel into ASF incubator

[Arvind Prabhakar]

Hi Henry and Kasper,

I have seen the request for soliciting mentors for MetaModel come up a few
times on the general list and apologize for not stepping up earlier. Part
of my hesitation is that I have not been a mentor to other projects before
and hence am not sure if I can do justice to this request. That said, I am
happy to volunteer myself as a mentor if you don't mind bearing the cost of
my learning curve.

It would be great if more experienced mentors out there can find sometime
to help guide this project to successful incorporation within Apache.

Regards,
Arvind Prabhakar

On Thu, Apr 11, 2013 at 12:21 AM, Kasper Sørensen 
kasper.soren...@humaninference.com wrote:

 Hi Ross,

 I think MetaModel could potentially have an oData module as well, making
 it possible to use an oData source just like any other data source. I think
 the main difference between oData and MetaModel, if you look at it from a
 helicopter view, is that oData attempts to standardize the server side of
 things by building a uniform protocol. MetaModel attempts to standardize
 the client side of things, by having a common abstraction layer. Thus,
 MetaModel does not have any specific protocol, just an API. There's pros
 and cons of that of course, but in deed both client side and server side
 standardization is attractive to have. So a MetaModel-oData module would be
 cool, making it possible to work with your sharepoint or netflix systems,
 just like you would work with your JDBC database or CSV file :)

 Kasper Sørensen


 -Original Message-
 From: Ross Gardler [mailto:rgard...@opendirective.com]
 Sent: 11. april 2013 09:09
 To: general
 Subject: Re: [REQUEST FOR MENTORS] Request for mentors to help bring
 MetaModel into ASF incubator

 MetaModel looks to overlap somewhat with the oData initiative [1]. Is a
 relationship worth exploring?

 Ross

 [1] http://www.odata.org

 Sent from a mobile device, please excuse mistakes and brevity On 10 Apr
 2013 22:35, Henry Saputra henry.sapu...@gmail.com wrote:

  Hi All,
 
  I am soliciting for help from ASF IPMCs to mentor and/or champion the
  proposed MetaModel incubator project:
  http://wiki.apache.org/incubator/MetaModelProposal
 
  We are still working on the proposal but would like to get help from
  experienced IPMC to drive this project during incubation.
 
  Any IPMC that are interested and have bandwidth to help is greatly
  appreciated.
 
 
  Thanks,
 
  - Henry
 

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

Re: [VOTE] Graduate Apache Crunch Podling from the Incubator

[Arvind Prabhakar]

[X] +1 Graduate Apache Crunch from Apache Incubator (binding)

Regards,
Arvind Prabhakar

On Mon, Feb 4, 2013 at 11:41 AM, Josh Wills jwi...@apache.org wrote:

 This is a call to graduate the Apache Crunch podling from Apache Incubator.

 Apache Crunch entered the Incubator in May of 2012. We have made
 significant progress with the project since moving over to Apache. We have
 ten committers listed on our status page at [1] including three accepted
 after the podling was formed, and we have verified that Apache Crunch is a
 suitable name. [2]

 We completed two releases (Apache Crunch 0.3.0-incubating and Apache Crunch
 0.4.0-incubating) and are currently preparing for a third.

 The community of Apache Crunch is active, healthy, and growing and has
 demonstrated the ability to self-govern using accepted Apache practices.

 The Apache Crunch community voted overwhelmingly to graduate [3],
 collecting three binding votes from our mentors and IPMC members Arun
 Murthy, Tom White, and Patrick Hunt. You can view the discussion at [4] and
 [5].

 Our charter is below and on our wiki. [6]

 Please cast your votes:

 [ ] +1 Graduate Apache Crunch from Apache Incubator
 [ ] +0 Indifferent to graduation status of Apache Crunch
 [ ] -1 Reject graduation of Apache Crunch from Apache Incubator because...

 We'll run the vote for at least 72 hours (closing at the earliest at 8PM
 GMT on February 7th.)

 [1] http://incubator.apache.org/projects/crunch.html
 [2] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-18
 [3] http://markmail.org/message/7mplf2wyzqhs2gts
 [4] http://markmail.org/message/3zu5wszwpaqegxic
 [5] http://markmail.org/message/wbz43fpnta7r2w4e
 [6]
 https://cwiki.apache.org/confluence/display/CRUNCH/Graduation+Resolution

 X. Establish the Apache Crunch 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 the development of Java libraries for writing, testing, and
 running MapReduce pipelines.

 NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
 (PMC), to be known as the Apache Crunch Project, be and hereby is
 established pursuant to Bylaws of the Foundation; and be it further

 RESOLVED, that the Apache Crunch Project be and hereby is responsible
 for the creation and maintenance of software related to development of
 Java libraries for writing, testing, and running MapReduce pipelines; and
 be it further

 RESOLVED, that the office of Vice President, Apache Crunch 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 Crunch Project, and to
 have primary responsibility for management of the projects within the scope
 of responsibility of the Apache Crunch 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 Crunch Project:

 * Brock Noland br...@apache.org
 * Christian Tzolov tzo...@apache.org
 * Gabriel Reid gr...@apache.org
 * Josh Wills jwi...@apache.org
 * Kiyan Ahmadizadeh ki...@apache.org
 * Matthias Friedrich m...@apache.org
 * Rahul Sharma rsha...@apache.org
 * Robert Chu robert...@apache.org
 * Tom White tomwh...@apache.org
 * Vinod Kumar Vavilapalli vino...@apache.org

 NOW, THEREFORE, BE IT FURTHER RESOLVED, that Josh Wills be appointed to the
 office of Vice President, Apache Crunch, 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 Crunch 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 Crunch Project; and be it further

 RESOLVED, that the Apache Crunch Project be and hereby is tasked with
 the migration and rationalization of the Apache Incubator Crunch podling;
 and be it further

 RESOLVED, that all responsibilities pertaining to the Apache
 Incubator Crunch podling encumbered upon the Apache Incubator Project are
 hereafter discharged.

Re: [VOTE] Graduate Bigtop podling from Apache Incubator

[Arvind Prabhakar]

[X] +1 Graduate Bigtop podling from Apache Incubator

Regards,
Arvind Prabhakar

On Wed, Sep 12, 2012 at 4:34 PM, Roman Shaposhnik r...@apache.org wrote:

 On Wed, Sep 12, 2012 at 3:04 PM, sebb seb...@gmail.com wrote:
  X. Establish the Apache Bigtop 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 related to a system for integration,
 packaging, deployment and validation of a big data management
 software distribution based on Apache Hadoop
 for distribution at no charge to the public.
 
  That last phrase belongs earlier; see recent update to Incubator docs.

 Thanks. Attached is the updated version. Given the triviality of the change
 I suggest we don't restart the vote. If anybody wants it to be restarted
 nonetheless -- please let me know ASAP.

 Thanks,
 Roman.

 X. Establish the Apache Bigtop 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 system for integration,
packaging, deployment and validation of a big data management
software distribution based on Apache Hadoop.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the Apache Bigtop Project,
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further

RESOLVED, that the Apache Bigtop Project be and hereby is
responsible for the creation and maintenance of software
related to a system for integration, packaging, deployment and
validation of a big data management software distribution based
on Apache Hadoop; and be it further

RESOLVED, that the office of Vice President, Apache Bigtop 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 Bigtop Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache Bigtop 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 Bigtop Project:

 * Alan Gatesga...@apache.org
 * Patrick Hunt  ph...@apache.org
 * Steve Loughranste...@apache.org
 * Tom White tomwh...@apache.org

 * Alejandro Abdelnurt...@apache.org
 * Andrew Bayer  aba...@apache.org
 * Konstantin Boudnikc...@apache.org
 * Stephen Chu   s...@apache.org
 * Bruno Mahébm...@apache.org
 * Peter Linnell plinn...@apache.org
 * James Pagejamesp...@apache.org
 * Patrick Taylor Ramsey p...@apache.org
 * Roman Shaposhnik  r...@apache.org
 * Michael Stack st...@apache.org
 * Andrei Savu   as...@apache.org
 * Edward J. Yoonedwardy...@apache.org

 * Andre Arcilla arci...@apache.org
 * Eli Collins   e...@apache.org
 * Travis Crawford   traviscrawf...@apache.org
 * John Sichij...@apache.org
 * Owen O'Malley omal...@apache.org

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Roman Shaposhnik
be appointed to the office of Vice President, Apache Bigtop,
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 Bigtop 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 Bigtop Project; and be it further

RESOLVED, that the Apache Bigtop Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator Bigtop podling; and be it further

RESOLVED, that all responsibilities pertaining to the Apache
Incubator Bigtop podling encumbered upon the Apache Incubator
Project are hereafter discharged.

 -
 To unsubscribe

Re: [VOTE] Graduate Oozie podling from Apache Incubator

[Arvind Prabhakar]

[X] +1 Graduate Oozie podling from Apache Incubator

(binding)

Regards,
Arvind Prabhakar

On Mon, Aug 20, 2012 at 10:25 AM, Alejandro Abdelnur t...@cloudera.comwrote:

 This is the second call for vote to graduate Oozie podling from Apache
 Incubator, comments and suggestions received during the first call have
 been addressed.

 Oozie entered the Incubator in July of 2011. Since then it has added
 two new committers and made two significant releases following the ASF
 policies and guidelines. The community of Oozie is active, healthy and
 growing and has demonstrated the ability to self-govern using accepted
 Apache practices. Oozie community has voted to proceed with graduation
 [1] and the result can be found at [2].

 Please cast your votes:

 [  ] +1 Graduate Oozie podling from Apache Incubator
 [  ] +0 Indifferent to the graduation status of Oozie podling
 [  ] -1 Reject graduation of Oozie podling from Apache Incubator

 This vote will be open for at least 72 hours. Please find the proposed
 board resolution below.

 [1] http://s.apache.org/WDb
 [2] http://s.apache.org/AB2

 Regards,
 Alejandro Abdelnur

 -

 X. Establish the Apache Oozie 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 related to a system for managing and
scheduling workflows that run different types of Hadoop
jobs (such as MapReduce, Pig, Hive and Sqoop) as well as
system specific jobs (such as Java programs and shell
scripts) for distribution at no charge to the public.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the Apache Oozie Project,
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further

RESOLVED, that the Apache Oozie Project be and hereby is
responsible for the creation and maintenance of software
related to a system for managing and scheduling workflows
that run different types of Hadoop jobs (such as MapReduce,
Pig, Hive and Sqoop) as well as system specific jobs (such
as Java programs and shell scripts); and be it further

RESOLVED, that the office of Vice President, Apache Oozie 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 Oozie Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache Oozie 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 Oozie Project:

 * Alan Gatesga...@apache.org
 * Alejandro Abdelnurt...@apache.org
 * Andreas Neumann   a...@apache.org
 * Angelo Huang  ange...@apache.org
 * Chao Wang broo...@apache.org
 * Chris Douglas cdoug...@apache.org
 * Devaraj Das   d...@apache.org
 * Harsh Chouraria   ha...@apache.org
 * Mayank Bansal may...@apache.org
 * Mohammad Islamkam...@apache.org
 * Virag Kothari vi...@apache.org

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Alejandro Abdelnur
be appointed to the office of Vice President, Apache Oozie,
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 Oozie 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 Oozie Project; and be it further

RESOLVED, that the Apache Oozie Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator Oozie podling; and be it further

RESOLVED, that all responsibilities pertaining to the Apache
Incubator Oozie podling encumbered upon the Apache Incubator
Project are hereafter discharged.

Re: [VOTE] Graduate Oozie podling from Apache Incubator

[Arvind Prabhakar]

+1 (binding)

Regards,
Arvind Prabhakar

On Fri, Aug 10, 2012 at 4:12 PM, Alejandro Abdelnur t...@cloudera.comwrote:

 This is a call for vote to graduate Oozie podling from Apache Incubator.

 Oozie entered the Incubator in July of 2011. Since then it has added
 two new committers and made two significant releases following the ASF
 policies and guidelines. The community of Oozie is active, healthy and
 growing and has demonstrated the ability to self-govern using accepted
 Apache practices. Oozie community has voted to proceed with graduation
 [1] and the result can be found at [2].

 Please cast your votes:

 [  ] +1 Graduate Oozie podling from Apache Incubator
 [  ] +0 Indifferent to the graduation status of Oozie podling
 [  ] -1 Reject graduation of Oozie podling from Apache Incubator

 This vote will be open for at least 72 hours. Please find the proposed
 board resolution below.

 [1] http://s.apache.org/WDb
 [2] http://s.apache.org/AB2

 Regards,
 Alejandro Abdelnur


 X. Establish the Apache Oozie 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 related to a system for managing
and scheduling workflows that run Apache Hadoop Map Reduce
jobs, Apache Pig jobs, Apache Hive jobs and Apache Sqoop jobs
for distribution at no charge to the public.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the Apache Oozie Project,
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further

RESOLVED, that the Apache Oozie Project be and hereby is
responsible for the creation and maintenance of software
related to a system for managing
and scheduling workflows that run Apache Hadoop Map Reduce
jobs, Apache Pig jobs, Apache Hive jobs and Apache Sqoop jobs;
and be it further

RESOLVED, that the office of Vice President, Apache Oozie 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 Oozie Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache Oozie 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 Oozie Project:

 * Alejandro Abdelnurt...@apache.org
 * Andreas Neumann   a...@apache.org
 * Angelo Huang  ange...@apache.org
 * Chao Wang broo...@apache.org
 * Harsh Chouraria   qwertyman...@apache.org
 * Mayank Bansal may...@apache.org
 * Mohammad Islamkam...@apache.org
 * Virag Kothari vi...@apache.org

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Alejandro Abdelnur
be appointed to the office of Vice President, Apache Oozie,
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 Oozie 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 Oozie Project; and be it further

RESOLVED, that the Apache Oozie Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator Oozie podling; and be it further

RESOLVED, that all responsibilities pertaining to the Apache
Incubator Oozie podling encumbered upon the Apache Incubator
Project are hereafter discharged.

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

Re: [VOTE] Graduate Flume podling from Apache Incubator

[Arvind Prabhakar]

With 72 hours passed, this VOTE is now closed. I will be sending the RESULT
mail shortly.

Thanks to all who voted and participated in the discussion.

Regards,
Arvind Prabhakar

On Tue, Jun 5, 2012 at 1:17 AM, Arvind Prabhakar arv...@apache.org wrote:

 This is a call for vote to graduate Flume podling from Apache Incubator.

 Flume entered the Incubator in June of 2011. Since then it has added nine
 new committers and made two signifiant releases following the ASF policies
 and guidelines. The community of Flume is active, healthy and growing and
 has demonstrated the ability to self-govern using accepted
 Apache practices. Flume community has voted to proceed with graduation [1]
 and the result can be found at [2].

 Please cast your votes:

 [  ] +1 Graduate Flume podling from Apache Incubator
 [  ] +0 Indifferent to the graduation status of Flume podling
 [  ] -1 Reject graduation of Flume podling from Apache Incubator

 This vote will be open for 72 hours. Please find the proposed board
 resolution below.

 [1] http://s.apache.org/Ckq
 [2] http://s.apache.org/DBv

 Regards,
 Arvind Prabhakar


 X. Establish the Apache Flume 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 related to a system for aggregating
large amounts of log data on Apache Hadoop's HDFS and
other scalable storage systems for distribution at no
charge to the public.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the Apache Flume Project,
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further

RESOLVED, that the Apache Flume Project be and hereby is
responsible for the creation and maintenance of software
related to  a system for aggregating large amounts of log
data on Apache Hadoop's HDFS and other scalable storage
systems; and be it further

RESOLVED, that the office of Vice President, Apache Flume 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 Flume Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache Flume 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 Flume Project:

  * Aaron Kimball  kimba...@apache.org
  * Andrew Bayer   aba...@apache.org
  * Ahmed Radwan   ah...@apache.org
  * Arvind Prabhakar   arv...@apache.org
  * Brock Noland   br...@apache.org
  * Bruce Mitchenerbru...@apache.org
  * Derek Deeter   ddee...@apache.org
  * Eric Sammeresam...@apache.org
  * Hari Shreedharan   hshreedha...@apache.org
  * Henry Robinson he...@apache.org
  * Jaroslav Cecho jar...@apache.org
  * Jonathan Hsieh jmhs...@apache.org
  * Juhani Connollyjuha...@apache.org
  * Mike Percy mpe...@apache.org
  * Mingjie Laim...@apache.org
  * Nick Verbeck   nerdyn...@apache.org
  * Patrick Hunt   ph...@apache.org
  * Prasad Mujumdarpras...@apache.org
  * Ralph Goersrgo...@apache.org
  * Will McQueen   w...@apache.org

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Arvind Prabhakar
be appointed to the office of Vice President, Apache Flume, 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 Flume 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 Flume Project; and be it further

RESOLVED, that the Apache Flume Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator Flume podling; and be it further

RESOLVED, that all responsibilities pertaining to the Apache
Incubator Flume podling encumbered upon the Apache Incubator
Project are hereafter discharged.

[VOTE][RESULT] Graduate Flume podling from Apache Incubator

[Arvind Prabhakar]

The VOTE by Apache Incubator to graduate Flume podling has passed. Tally of
votes is as follows:

16 +1 votes (9 binding, 7 non-binding)
0 +0 votes
0 -1 votes

Binding +1 votes:
Ralph Goers
Tommaso Teofili
Jukka Zitting
Alan D. Cabrera
Patrick Hunt
Arvind Prabhakar
Marvin Humphrey
Jean-Baptise Onofrè
Niall Pemberton


Non-binding +1 votes:
Jarek Jarcec Cecho
Brock Noland
Mike Percy
Hari Shreedharan
Roman Shaposhnik
Eric Sammer
Juhani Connolly

The VOTE thread for this can be found at [1].

[1] http://s.apache.org/5Am

Regards,
Arvind Prabhakar

Re: [VOTE] Graduate Flume podling from Apache Incubator

[Arvind Prabhakar]

[X] +1 Graduate Flume podling from Apache Incubator

Regards,
Arvind Prabhakar

On Tue, Jun 5, 2012 at 1:17 AM, Arvind Prabhakar arv...@apache.org wrote:

 This is a call for vote to graduate Flume podling from Apache Incubator.

 Flume entered the Incubator in June of 2011. Since then it has added nine
 new committers and made two signifiant releases following the ASF policies
 and guidelines. The community of Flume is active, healthy and growing and
 has demonstrated the ability to self-govern using accepted
 Apache practices. Flume community has voted to proceed with graduation [1]
 and the result can be found at [2].

 Please cast your votes:

 [  ] +1 Graduate Flume podling from Apache Incubator
 [  ] +0 Indifferent to the graduation status of Flume podling
 [  ] -1 Reject graduation of Flume podling from Apache Incubator

 This vote will be open for 72 hours. Please find the proposed board
 resolution below.

 [1] http://s.apache.org/Ckq
 [2] http://s.apache.org/DBv

 Regards,
 Arvind Prabhakar


 X. Establish the Apache Flume 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 related to a system for aggregating
large amounts of log data on Apache Hadoop's HDFS and
other scalable storage systems for distribution at no
charge to the public.

NOW, THEREFORE, BE IT RESOLVED, that a Project Management
Committee (PMC), to be known as the Apache Flume Project,
be and hereby is established pursuant to Bylaws of the
Foundation; and be it further

RESOLVED, that the Apache Flume Project be and hereby is
responsible for the creation and maintenance of software
related to  a system for aggregating large amounts of log
data on Apache Hadoop's HDFS and other scalable storage
systems; and be it further

RESOLVED, that the office of Vice President, Apache Flume 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 Flume Project, and to have primary responsibility
for management of the projects within the scope of
responsibility of the Apache Flume 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 Flume Project:

  * Aaron Kimball  kimba...@apache.org
  * Andrew Bayer   aba...@apache.org
  * Ahmed Radwan   ah...@apache.org
  * Arvind Prabhakar   arv...@apache.org
  * Brock Noland   br...@apache.org
  * Bruce Mitchenerbru...@apache.org
  * Derek Deeter   ddee...@apache.org
  * Eric Sammeresam...@apache.org
  * Hari Shreedharan   hshreedha...@apache.org
  * Henry Robinson he...@apache.org
  * Jaroslav Cecho jar...@apache.org
  * Jonathan Hsieh jmhs...@apache.org
  * Juhani Connollyjuha...@apache.org
  * Mike Percy mpe...@apache.org
  * Mingjie Laim...@apache.org
  * Nick Verbeck   nerdyn...@apache.org
  * Patrick Hunt   ph...@apache.org
  * Prasad Mujumdarpras...@apache.org
  * Ralph Goersrgo...@apache.org
  * Will McQueen   w...@apache.org

NOW, THEREFORE, BE IT FURTHER RESOLVED, that Arvind Prabhakar
be appointed to the office of Vice President, Apache Flume, 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 Flume 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 Flume Project; and be it further

RESOLVED, that the Apache Flume Project be and hereby
is tasked with the migration and rationalization of the Apache
Incubator Flume podling; and be it further

RESOLVED, that all responsibilities pertaining to the Apache
Incubator Flume podling encumbered upon the Apache Incubator
Project are hereafter discharged.

[VOTE] Graduate Flume podling from Apache Incubator

[Arvind Prabhakar]

This is a call for vote to graduate Flume podling from Apache Incubator.

Flume entered the Incubator in June of 2011. Since then it has added nine
new committers and made two signifiant releases following the ASF policies
and guidelines. The community of Flume is active, healthy and growing and
has demonstrated the ability to self-govern using accepted
Apache practices. Flume community has voted to proceed with graduation [1]
and the result can be found at [2].

Please cast your votes:

[  ] +1 Graduate Flume podling from Apache Incubator
[  ] +0 Indifferent to the graduation status of Flume podling
[  ] -1 Reject graduation of Flume podling from Apache Incubator

This vote will be open for 72 hours. Please find the proposed board
resolution below.

[1] http://s.apache.org/Ckq
[2] http://s.apache.org/DBv

Regards,
Arvind Prabhakar


X. Establish the Apache Flume 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 related to a system for aggregating
   large amounts of log data on Apache Hadoop's HDFS and
   other scalable storage systems for distribution at no
   charge to the public.

   NOW, THEREFORE, BE IT RESOLVED, that a Project Management
   Committee (PMC), to be known as the Apache Flume Project,
   be and hereby is established pursuant to Bylaws of the
   Foundation; and be it further

   RESOLVED, that the Apache Flume Project be and hereby is
   responsible for the creation and maintenance of software
   related to  a system for aggregating large amounts of log
   data on Apache Hadoop's HDFS and other scalable storage
   systems; and be it further

   RESOLVED, that the office of Vice President, Apache Flume 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 Flume Project, and to have primary responsibility
   for management of the projects within the scope of
   responsibility of the Apache Flume 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 Flume Project:

 * Aaron Kimball  kimba...@apache.org
 * Andrew Bayer   aba...@apache.org
 * Ahmed Radwan   ah...@apache.org
 * Arvind Prabhakar   arv...@apache.org
 * Brock Noland   br...@apache.org
 * Bruce Mitchenerbru...@apache.org
 * Derek Deeter   ddee...@apache.org
 * Eric Sammeresam...@apache.org
 * Hari Shreedharan   hshreedha...@apache.org
 * Henry Robinson he...@apache.org
 * Jaroslav Cecho jar...@apache.org
 * Jonathan Hsieh jmhs...@apache.org
 * Juhani Connollyjuha...@apache.org
 * Mike Percy mpe...@apache.org
 * Mingjie Laim...@apache.org
 * Nick Verbeck   nerdyn...@apache.org
 * Patrick Hunt   ph...@apache.org
 * Prasad Mujumdarpras...@apache.org
 * Ralph Goersrgo...@apache.org
 * Will McQueen   w...@apache.org

   NOW, THEREFORE, BE IT FURTHER RESOLVED, that Arvind Prabhakar
   be appointed to the office of Vice President, Apache Flume, 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 Flume 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 Flume Project; and be it further

   RESOLVED, that the Apache Flume Project be and hereby
   is tasked with the migration and rationalization of the Apache
   Incubator Flume podling; and be it further

   RESOLVED, that all responsibilities pertaining to the Apache
   Incubator Flume podling encumbered upon the Apache Incubator
   Project are hereafter discharged.

Re: Flume Graduation (was Re: June reports in two weeks)

[Arvind Prabhakar]

Closing the loop on this thread: The Flume PPMC has discussed the diversity
issue and have concluded to put all current committers as PMC when drafting
the resolution.

Also, the wiki has been updated with details on how to contribute and
commit.

https://cwiki.apache.org/confluence/display/FLUME/How+to+Contribute
https://cwiki.apache.org/confluence/display/FLUME/How+to+Commit

Thanks,
Arvind Prabhakar

On Sun, May 27, 2012 at 3:21 AM, Arvind Prabhakar arv...@apache.org wrote:

 Thanks Jukka for your suggestions.

 1. Regarding wiki - I have taken a note of that and will update it soon.

 2. Regarding doing away with the difference between PPMC and committers, I
 am told that other projects do this during graduation. I.e., they promote
 all existing committers to PMC status during graduation. If we do that, the
 diversity concern will be addressed and we can then debate the bylaws once
 the PMC is formed.

 Thanks,
 Arvind Prabhakar


 On Sun, May 27, 2012 at 2:40 AM, Jukka Zitting jukka.zitt...@gmail.comwrote:

 Hi,

 On Sun, May 27, 2012 at 6:29 AM, Arvind Prabhakar arv...@apache.org
 wrote:
  As you noted in your comments above - the Flume project tends to follow
 RTC
  with the reviewer committing the code. I happen to have taken up the
 role
  of the reviewer for the most part and hence you see the skewed commit
  counts.

 It might be useful if you for example expanded the How to Commit
 wiki page [1] with a better description of what a reviewer should take
 in to account when committing reviewed changes. Things that might be
 obvious to you and others who've been around for longer, but not
 necessarily for newcomers. The more people you have committing code,
 the less the project is dependent on the silent knowledge of any
 single contributor.

  On Sat, May 26, 2012 at 4:43 PM, Jukka Zitting jukka.zitt...@gmail.com
 wrote:
  Do you think this is a problem for the community? If yes, how do you
  plan to fix it? If not, why?
 
  I don't think this is a problem because while most Cloudera committers
 have
  the luxury of working on the project during regular working hours,
 others
  do that during their off hours. Hence the majority of contributions
 coming
  from Cloudera.

 OK, fair enough.

 Such a scenario exists or has existed also in other Apache projects
 like Jackrabbit that I'm most familiar with. It can be a tricky
 balance to maintain a level playing field in such cases, for example
 by making sure that all relevant project discussions happen out in the
 open and that some committers don't feel like junior partners with
 less ability to influence the project.

 It sounds like you have a reasonably good handle on that, so I'm not
 too worried, but my instinct suggests that the strict RTC model and
 distinction between committers and (P)PMC members may be structural
 factors that could easily end up tripping that balance. Are these
 really essential tools for the project or could you live without them?
 Other solutions to the RTC model include separate maintenance branches
 with stricter review and testing requirements, and the only cases
 where I really see a need for the committer/(P)PMC separation is with
 umbrella projects or special cases like GSoC students or co-operation
 across project boundaries.

 I know you have good arguments for the way things work in Flume now,
 and ultimately you're the ones to decide how you want to work. So take
 the above just as friendly suggestions for things you may want to
 consider. Whatever the outcome, it would be good for Flume to document
 such decisions and the rationale behind them as a set of project
 bylaws. This is what the bylaws section of the graduation resolution
 is about:

   RESOLVED, that the initial Apache $project 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 $foo Project; and be it further

 [1] https://cwiki.apache.org/confluence/display/FLUME/How+to+Commit

 BR,

 Jukka Zitting

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

Re: Flume Graduation (was Re: June reports in two weeks)

[Arvind Prabhakar]

Thanks Jukka for your suggestions.

1. Regarding wiki - I have taken a note of that and will update it soon.

2. Regarding doing away with the difference between PPMC and committers, I
am told that other projects do this during graduation. I.e., they promote
all existing committers to PMC status during graduation. If we do that, the
diversity concern will be addressed and we can then debate the bylaws once
the PMC is formed.

Thanks,
Arvind Prabhakar

On Sun, May 27, 2012 at 2:40 AM, Jukka Zitting jukka.zitt...@gmail.comwrote:

 Hi,

 On Sun, May 27, 2012 at 6:29 AM, Arvind Prabhakar arv...@apache.org
 wrote:
  As you noted in your comments above - the Flume project tends to follow
 RTC
  with the reviewer committing the code. I happen to have taken up the role
  of the reviewer for the most part and hence you see the skewed commit
  counts.

 It might be useful if you for example expanded the How to Commit
 wiki page [1] with a better description of what a reviewer should take
 in to account when committing reviewed changes. Things that might be
 obvious to you and others who've been around for longer, but not
 necessarily for newcomers. The more people you have committing code,
 the less the project is dependent on the silent knowledge of any
 single contributor.

  On Sat, May 26, 2012 at 4:43 PM, Jukka Zitting jukka.zitt...@gmail.com
 wrote:
  Do you think this is a problem for the community? If yes, how do you
  plan to fix it? If not, why?
 
  I don't think this is a problem because while most Cloudera committers
 have
  the luxury of working on the project during regular working hours, others
  do that during their off hours. Hence the majority of contributions
 coming
  from Cloudera.

 OK, fair enough.

 Such a scenario exists or has existed also in other Apache projects
 like Jackrabbit that I'm most familiar with. It can be a tricky
 balance to maintain a level playing field in such cases, for example
 by making sure that all relevant project discussions happen out in the
 open and that some committers don't feel like junior partners with
 less ability to influence the project.

 It sounds like you have a reasonably good handle on that, so I'm not
 too worried, but my instinct suggests that the strict RTC model and
 distinction between committers and (P)PMC members may be structural
 factors that could easily end up tripping that balance. Are these
 really essential tools for the project or could you live without them?
 Other solutions to the RTC model include separate maintenance branches
 with stricter review and testing requirements, and the only cases
 where I really see a need for the committer/(P)PMC separation is with
 umbrella projects or special cases like GSoC students or co-operation
 across project boundaries.

 I know you have good arguments for the way things work in Flume now,
 and ultimately you're the ones to decide how you want to work. So take
 the above just as friendly suggestions for things you may want to
 consider. Whatever the outcome, it would be good for Flume to document
 such decisions and the rationale behind them as a set of project
 bylaws. This is what the bylaws section of the graduation resolution
 is about:

   RESOLVED, that the initial Apache $project 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 $foo Project; and be it further

 [1] https://cwiki.apache.org/confluence/display/FLUME/How+to+Commit

 BR,

 Jukka Zitting

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

Re: Flume Graduation (was Re: June reports in two weeks)

[Arvind Prabhakar]

On Fri, May 25, 2012 at 12:29 PM, Ralph Goers ralph.go...@dslextreme.comwrote:

 At this point my recommendations are:
 1. Since the PPMC voted to separate being a committer and being a PMC
 member I would wait a couple of months and then add the new non-Cloudera
 committers to the PPMC if it is warranted.
 2. Of course, add any new committers who have earned it.
 3. Send an email to the entire PPMC asking them to confirm that they want
 to remain on the PMC after graduation.
 4. Based on that we will know what the making of the post-graduation PMC
 will look like.
 5. Raise the topic of graduation as a discussion item either on the PMC or
 dev list after the above 4 are completed.



What purpose will these recommendations serve?
* We have established that there is sufficient diversity in the committers
list.
* Without counting you, there are two other non-Cloudera PPMC who have
expressed their commitment to the project.
* The VOTE thread has overwhelmingly established what the community wants.
* We, the active PPMC have demonstrated self-governance using accepted
Apache practices and are committed to growing and diversifying the project
further.

If at this stage you insist on postponing the graduation, I am inclined to
think that perhaps your own preferences outweigh that of the project and
community. Please don't get me wrong - I am not accusing you of anything,
just requesting you to please consider revoking your -1 vote.

Arvind Prabhakar




 Ralph



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

Re: Flume Graduation (was Re: June reports in two weeks)

[Arvind Prabhakar]

Hi Jukka,

On Sat, May 26, 2012 at 4:43 PM, Jukka Zitting jukka.zitt...@gmail.comwrote:

 Hi,

 On Sat, May 26, 2012 at 7:11 PM, Arvind Prabhakar arv...@apache.org
 wrote:
  * We have established that there is sufficient diversity in the
 committers
  list.

 I tend to look more at actual commit activity than the committers list
 when evaluating the diversity of a project. There are people on the
 Flume committers list who've never committed anything.

 Combining information from svn statistics [1] and committer
 affiliations [2] I get the following list of Flume commit activity so
 far this year:

arvind  - 116 commits - Cloudera
prasadm -  22 commits - Cloudera
brock   -  16 commits - Cloudera
esammer -   4 commits - Cloudera
jarcec  -   1 commit  - AVG Technologies
juhanic -   1 commit  - CyberAgent

 The only two non-Cloudera commits were pretty trivial changes (a
 plugin version upgrade [3] and a spelling fix [4]). My earlier
 classification of Flume as ready to graduate [5] was partially based
 on these new committers from outside Cloudera, but the above data
 suggests that they haven't been as active as I would have hoped.

 IIUC Flume operates under an RTC model where people are not supposed
 to commit their own changes, which obviously makes the above data less
 relevant for evaluating the true diversity of the community. However,
 seeing only a single trivial commit by both jarcec and juhanic even
 though they became committers already over three months ago does seem
 to suggest that they may not be as comfortable in their committer role
 as people from Cloudera are.


As you noted in your comments above - the Flume project tends to follow RTC
with the reviewer committing the code. I happen to have taken up the role
of the reviewer for the most part and hence you see the skewed commit
counts. If you want to see the actual contribution, I would suggest looking
at fixed JIRA issues by assignees. A quick report yields the following:

aprabhkar - 26 - Cloudera [6]
brocknoland - 19 - Cloudera [7]
esammer - 56 - Cloudera [8]
hshreedharan - 34 - Cloudera [9]
jarcec - 6 - AVG Technologies [10]
jmhsieh - 8 - Cloudera [11]
juhanic - 9 - CyberAgent [12]
mpercy - 34 - Cloudera [13]
m...@apache.org - 1 - Trend Micro [14]
prasadm - 34 - Cloudera [15]
t...@cloudera.com - 3 - Cloudera [16]
w...@cloudera.com - 3 - Cloudera [17]

Looking at this, the average number of issues resolved by Cloudera
committers (not counting Tom who is a mentor) is 26, and that for
non-Cloudera committers is 5. Note that this number does not include other
committer work such as the number of code reviews they have done, the
number of design discussions they have participated in, something that is
very valuable to the project.



 Do you think this is a problem for the community? If yes, how do you
 plan to fix it? If not, why?


I don't think this is a problem because while most Cloudera committers have
the luxury of working on the project during regular working hours, others
do that during their off hours. Hence the majority of contributions coming
from Cloudera.

If all committers were to be non-Cloudera, I am sure the averages will be
low and comparable to what the non-Cloudera contribution rate is at the
moment. In other words, the project growth will definitely slow down, but
the community will remain healthy. This is also indicated by the following
statistics:

User List:
  Messages in May: 171, April: 119
  Number of Subscribers: 102

Dev List:
  Messages in May: 642, April 1024
  Number of Subscribers: 245

[6] http://s.apache.org/2hi
[7] http://s.apache.org/kw
[8] http://s.apache.org/nl
[9] http://s.apache.org/SGe
[10] http://s.apache.org/tR
[11] http://s.apache.org/UvH
[12] http://s.apache.org/A8V
[13] http://s.apache.org/f8M
[14] http://s.apache.org/TIK
[15] http://s.apache.org/wO
[16] http://s.apache.org/Fxb
[17] http://s.apache.org/rw

Thanks,
Arvind Prabhakar



 [1]
 http://svnsearch.org/svnsearch/repos/ASF/search?from=20120101to=20121231path=%2Fincubator%2Fflume
 [2] http://incubator.apache.org/flume/team-list.html
 [3] http://svn.apache.org/viewvc?view=revisionrevision=1305478
 [4] http://svn.apache.org/viewvc?view=revisionrevision=1342066
 [5] http://markmail.org/message/kq5ixay6z3erw3pc

 BR,

 Jukka Zitting

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

Re: Flume Graduation (was Re: June reports in two weeks)

[Arvind Prabhakar]

Hi,

On Thu, May 24, 2012 at 12:06 PM, Dave Fisher dave2w...@comcast.net wrote:


 I started reading some of the Flume website and I think that when you go
 to the main Wiki page:

 https://cwiki.apache.org/confluence/display/FLUME/Index

 When you click on the Flume Cookbook the resource is at cloudera.org.

 http://archive.cloudera.com/cdh/3/flume/Cookbook/

 This page lists flume-...@cloudera.org and is a file with a revision
 dated May 7, 2012.


Thanks. These have been removed.



 You can make you own conclusions, but it looks like podling resources need
 to be migrated to the ASF.


These were kept to facilitate the transitoin over to Flume 0.9.5 which
never happened. We instead went straight to 1.0.0. Other than that all
resources have been migrated.

Thanks,
Arvind Prabhakar



 Regards,
 Dave

 
 
 
 
 
 
  In any case - I'm not insisting that the way the project is run needs
 to
  change. I'm simply saying I cannot support graduation with the current
  makeup of the committers and PMC. I don't have a hard and fast ratio -
  gaining 10 new unaffiliated committers who don't do much isn't nearly
 as
  good as 2 or 3 who are very active.  Ultimately the project needs to
 figure
  out how to solve this.
 
 
  Stating that some committers who don't do much isn't nearly as good as
 2
  or 3 who are very active is an unfair characterization. This is more
  unfair for those who are part of the project but have not been active
  lately due to whatever reasons, but have played a foundational role in
  getting the project to a point where it is today. I think they are as
  important as any other committer who may be very active at the moment.
  Merit once earned, never expires [1].
 
  [1] http://www.apache.org/dev/committers.html#committer-set-term
 
  I think you misunderstood my point or I didn't state it very well.
  Diversity isn't achieved simply by having bodies.  IOW I am not suggesting
 offering commit rights to people who haven't earned it just to meet some
 ratio.  However, I am not suggesting the project has ever even considered
 doing that.
 
  Ralph
 
 
 
  -
  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: Flume Graduation (was Re: June reports in two weeks)

[Arvind Prabhakar]

On Thu, May 24, 2012 at 11:49 AM, Ralph Goers ralph.go...@dslextreme.comwrote:


 On May 24, 2012, at 10:40 AM, Arvind Prabhakar wrote:
 
  There are four companies represented in this list: AVG Technologies,
  Cloudera, CyberAgent and Trend Micro. Compared to other projects that
 have
  successfully graduated from Incubator in the past, this meets the
 diversity
  requirements very well.

 I was mistaken and the list above is indeed correct.  For some reason I
 thought a couple of them had become Cloudera employees.

 However, none of those three are currently on the PPMC.  When you look at
 the PPMC list you should also include a few more Cloudera people who do
 participate in release votes and PPMC issues. Most, if not all, of the
 non-Cloudera PMC members don't.


Back in October of 2011 the PPMC discussed and decided to use the process
where new committers are not automatically added to PPMC. We have since
followed this process and added one committer to the PPMC recently.

The current PPMC consists of:

* Andrew Bayer (Cloudera)
* Ahmed Radwan (Cloudera)
* Arvind Prabhakar(Cloudera)
* Bruce Mitchener (Independent)
* Derek Deeter (Intuit)
* Eric Sammer (Cloudera)
* Henry Robinson (Cloudera)
* Jonathan Hsieh (Cloudera)
* Aaron Kimball (Odiago)
* Ralph Goers (Intuit)

There is a representation of at least four companies in this list. This,
plus the the fact that we have demonstrated our commitment to the policies
that we set forth, give me the confidence that we are on the right track.
Diversity is a priority and will continue to be post graduation.

Arvind





 
 
 
  In any case - I'm not insisting that the way the project is run needs to
  change. I'm simply saying I cannot support graduation with the current
  makeup of the committers and PMC. I don't have a hard and fast ratio -
  gaining 10 new unaffiliated committers who don't do much isn't nearly as
  good as 2 or 3 who are very active.  Ultimately the project needs to
 figure
  out how to solve this.
 
 
  Stating that some committers who don't do much isn't nearly as good as 2
  or 3 who are very active is an unfair characterization. This is more
  unfair for those who are part of the project but have not been active
  lately due to whatever reasons, but have played a foundational role in
  getting the project to a point where it is today. I think they are as
  important as any other committer who may be very active at the moment.
  Merit once earned, never expires [1].
 
  [1] http://www.apache.org/dev/committers.html#committer-set-term

 I think you misunderstood my point or I didn't state it very well.
  Diversity isn't achieved simply by having bodies.  IOW I am not suggesting
 offering commit rights to people who haven't earned it just to meet some
 ratio.  However, I am not suggesting the project has ever even considered
 doing that.

 Ralph



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

Re: Flume Graduation (was Re: June reports in two weeks)

[Arvind Prabhakar]

On Fri, May 25, 2012 at 8:03 AM, Ralph Goers ralph.go...@dslextreme.comwrote:


 On May 25, 2012, at 2:46 AM, Arvind Prabhakar wrote:

  On Thu, May 24, 2012 at 11:49 AM, Ralph Goers 
 ralph.go...@dslextreme.comwrote:
 
 
  On May 24, 2012, at 10:40 AM, Arvind Prabhakar wrote:
  The current PPMC consists of:
 
  * Andrew Bayer (Cloudera)
  * Ahmed Radwan (Cloudera)
  * Arvind Prabhakar(Cloudera)
  * Bruce Mitchener (Independent)
  * Derek Deeter (Intuit)
  * Eric Sammer (Cloudera)
  * Henry Robinson (Cloudera)
  * Jonathan Hsieh (Cloudera)
  * Aaron Kimball (Odiago)
  * Ralph Goers (Intuit)
 
  There is a representation of at least four companies in this list. This,
  plus the the fact that we have demonstrated our commitment to the
 policies
  that we set forth, give me the confidence that we are on the right track.
  Diversity is a priority and will continue to be post graduation.

 Are you really going to resort to distortion of the truth to try to claim
 diversity?  I work with Derek and know that he has never participated in
 Flume since its inception. I also can't recall Bruce or Aaron participating
 after the podling started. All of them appear to have just signed the
 initial wiki page to get on the PPMC.


It is unfortunate that you think this way. Bruce and Aaron have played a
foundational role in Flume and they deserve to be seated on the PPMC unless
they explicitly request to be removed. I welcome their contribution anytime
and hope that they chose to remain on the project.



 I'm not sure why you left Tom White and Patrick Hunt off as they are both
 mentors and are PPMC members and both have participated in PMC discussions.


Because I counted them as mentors and not PPMC. I am happy to include them
if they want to be counted as PPMC. Pardon me if I should not have made
this distinction. The one person who was left out inadvertently was Prasad
who recently got elected to PPMC.




 That leaves just me as the only non-Cloudera PPMC member who actively
 participates and I don't commit code and I've been on the PPMC primarily as
 a mentor.  If you somehow believe that this constitutes diversity than my
 job as a mentor has a long way to go.


You were counted because three months ago you announced that you would like
to stay with the project post graduation. I don't remember seeing any
communication from you stating your change of mind. That said, I respect
your choice either way.



 Ralph


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

Re: Flume Graduation (was Re: June reports in two weeks)

[Arvind Prabhakar]

Hi,

On Thu, May 24, 2012 at 12:19 AM, Ralph Goers ralph.go...@dslextreme.comwrote:

 The ONLY issue I see for Flume to graduate is diversity.  No one will
 convince me that the current makeup constitutes diversity of any kind.

 Perhaps I shouldn't have brought up the mailing list issues as that was
 only meant in the spirit of trying to offer some advice on how more
 diversity could be achieved.  Flume is really the only community I
 participate in that contains Cloudera employees so I do find myself
 wondering if the way the project is run is because that is the way all
 projects with a large number of Cloudera employees are run.  That might
 make all of those participants comfortable but might create a barrier to
 others.


Here are the committers who have been active in the past three months:

* Brock Noland (Cloudera)
* Hari Shreedharan  (Cloudera)
* Jarek Jarcec Cecho (AVG Technologies)
* Juhani Connolly   (CyberAgent)
* Mike Percy (Cloudera)
* Mingjie Lai (Trend Micro)
* Prasad Mujumdar (Cloudera)
* Will McQueen (Cloudera)
* Arvind Prabhakar (Cloudera)

There are four companies represented in this list: AVG Technologies,
Cloudera, CyberAgent and Trend Micro. Compared to other projects that have
successfully graduated from Incubator in the past, this meets the diversity
requirements very well.



 In any case - I'm not insisting that the way the project is run needs to
 change. I'm simply saying I cannot support graduation with the current
 makeup of the committers and PMC. I don't have a hard and fast ratio -
 gaining 10 new unaffiliated committers who don't do much isn't nearly as
 good as 2 or 3 who are very active.  Ultimately the project needs to figure
 out how to solve this.


Stating that some committers who don't do much isn't nearly as good as 2
or 3 who are very active is an unfair characterization. This is more
unfair for those who are part of the project but have not been active
lately due to whatever reasons, but have played a foundational role in
getting the project to a point where it is today. I think they are as
important as any other committer who may be very active at the moment.
Merit once earned, never expires [1].

[1] http://www.apache.org/dev/committers.html#committer-set-term

Arvind



 Ralph


 On May 23, 2012, at 11:48 PM, Eric Sammer wrote:

  I appreciate your position Ralph and I don't want anyone to feel like
 they
  can't contribute. As we've talked about before, we've been quick to
 nurture
  new contributors to committer status successfully in a few cases. It's
 true
  that some of the more active committers are from Cloudera, but it's not
 to
  the exclusion of anyone. Others aren't from Cloudera. Those of us that
 work
  together are also very strict about abiding to the if it's not on the
  mailing list, it didn't happen rule (where mailing list can mean JIRA
 or
  other ASF infrastructure as well).
 
  I'm happy to take your guidance as a mentor, but you also need to
  understand that some of the ways the Flume project has elected to operate
  are just a matter of taste. They were proposed, discussed, voted on (and
  not as a block by Cloudera employees, IIRC - pretty sure I was -0), and
 put
  in place and do not violate the Apache Way (like RTC vs. CTR). They
 aren't
  unheard of and they do not work to the exclusion of contributors (RTC,
 for
  instance, only impacts committers). I think the vote that was started was
  only to gauge community opinion as a first step (although I'm not
  completely well versed in the graduation process, to be honest).
 
  If there are concrete things we can do to improve diversity, in your
  opinion, I am extremely open to hearing them. We already do many of the
  (excellent) things listed earlier in the thread. JIRA noise withstanding
  (again, it's a matter of taste - I use the email frequently as I find
  trolling through JIRA slow) I'm definitely open to ideas. Of course, if
  Flume simply needs to remain in the incubator until we develop greater
  diversity, that's fine too. If we're not ready, we're just not ready.
 
  On Wed, May 23, 2012 at 11:18 PM, Ralph Goers 
 ralph.go...@dslextreme.comwrote:
 
 
  On May 23, 2012, at 10:48 PM, Patrick Hunt wrote:
 
  On Wed, May 23, 2012 at 10:36 PM, Ralph Goers
  ralph.go...@dslextreme.com wrote:
 
  On May 23, 2012, at 10:15 PM, Benson Margulies wrote:
 
  On Wed, May 23, 2012 at 10:09 PM, Ralph Goers
  ralph.go...@dslextreme.com wrote:
  Right after I read Jukka's email that started this thread and I
  posted my reply and discovered to my shock that they had started a
  graduation vote.  I am shocked because I have pointed out repeatedly the
  project's complete lack of diversity.  Virtually all the active PMC
 members
  and committers work for the same employer.  I have told them several
 times
  that I would actually like to participate in the project but the way the
  project works is very different then every other project I am involved
 with
  at the ASF and the barriers

Re: [VOTE] Accept Crunch into the Apache Incubator

[Arvind Prabhakar]

[X] +1, bring Crunch into Incubator (non-binding)

Thanks,
Arvind Prabhakar

On Wed, May 23, 2012 at 11:45 AM, Josh Wills jwi...@cloudera.com wrote:

 I would like to call a vote for accepting Apache Crunch for
 incubation in the Apache Incubator. The full proposal is available
 below.  We ask the Incubator PMC to sponsor it, with phunt as
 Champion, and phunt, tomwhite, and acmurthy volunteering to be
 Mentors.

 Please cast your vote:

 [ ] +1, bring Crunch into Incubator
 [ ] +0, I don't care either way,
 [ ] -1, do not bring Crunch into Incubator, because...

 This vote will be open for 72 hours and only votes from the Incubator
 PMC are binding.

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

 Proposal text from the wiki:

 --
 = Crunch - Easy, Efficient MapReduce Pipelines in Java and Scala =

 == Abstract ==

 Crunch is a Java library for writing, testing, and running pipelines
 of !MapReduce jobs on Apache Hadoop.

 == Proposal ==

 Crunch is a Java library for writing, testing, and running pipelines
 of !MapReduce jobs on Apache Hadoop. Its main goal is to provide a
 high-level API for writing and testing complex !MapReduce jobs that
 require multiple processing stages.  It has a simple, flexible, and
 extensible data model that makes it ideal for processing data that
 does not naturally fit into a relational structure, such as time
 series and serialized object formats like JSON and Avro. It supports
 running pipelines either as a series of !MapReduce jobs on an Apache
 Hadoop cluster or in memory on a single machine for fast testing and
 debugging.

 == Background ==

 Crunch was initially developed by Cloudera to simplify the process of
 creating sequences of dependent !MapReduce jobs, especially jobs that
 processed non-relational data like time series. Its design was based
 on a paper Google published about a Java library they developed called
 !FlumeJava that was created in order to solve a similar class of
 problems. Crunch was open-sourced by Cloudera on !GitHub as an Apache
 2.0 licensed project in October 2011. During this time Crunch has been
 formally released twice, as versions 0.1.0 (October 2010) and 0.2.0
 (February 2012), with an incremental update to version 0.2.1 (March
 2012) .  These releases are also distributed by Cloudera as source and
 binaries from Cloudera's Maven repository.

 == Rationale ==

 Most of the interesting analytical and data processing tasks that are
 run on an Apache Hadoop cluster require a series of !MapReduce jobs to
 be executed in sequence. Developers who are creating these pipelines
 today need to manually assign the sequence of tasks to perform in a
 dependent chain of !MapReduce jobs, even though there are a number of
 well-known patterns for fusing dependent computations together into a
 single !MapReduce stage and for performing common types of joins and
 aggregations. This results in !MapReduce pipelines that are more
 difficult to test, maintain, and extend to support new functionality.

 Furthermore, the type of data that is being stored and processed using
 Apache Hadoop is evolving. Although Hadoop was originally used for
 storing large volumes of structured text in the form of webpages and
 log files, it is now common for Hadoop to store complex, structured
 data formats such as JSON, Apache Avro, and Apache Thrift. These
 formats allow developers to work with serialized objects in
 programming languages like Java, C++, and Python, and allow for new
 types of analysis to be performed on complex data types. Hadoop has
 also been adopted by the scientific research community, who are using
 Hadoop to process time series data, structured binary files in the
 HDF5 format, and large medical and satellite images.

 Crunch addresses these challenges by providing a lightweight and
 extensible Java API for defining the stages of a data processing
 pipeline, which can then be run on an Apache Hadoop cluster as a
 sequence of dependent !MapReduce jobs, or in-memory on a single
 machine to facilitate fast testing and debugging. Crunch relies on a
 small set of primitive abstractions that represent immutable,
 distributed collections of objects. Developers define functions that
 are applied to those objects in order to generate new immutable,
 distributed collections of objects. Crunch also provides a library of
 common !MapReduce patterns for performing efficient joins and
 aggregation operations over these distributed collections that
 developers may integrate into their own pipelines. Crunch also
 provides native support for processing structured binary data formats
 like JSON, Apache Avro, and Apache Thrift, and is designed to be
 extensible to support working with any kind of data format that Java
 supports in its native form.

 == Initial Goals ==

 Crunch is currently in its first major release with a considerable
 number

Re: [VOTE][RESULT] Release Apache Flume version 1.1.0-incubating (rc1)

[Arvind Prabhakar]

With 13 +1 votes, 0 +0 votes and 0 -1 votes, this release candidate is
promoted to a release.

Tally of votes is as follows:

+1 Votes: 13 total including 4 IPMC and 3 PPMC votes
  Andrew Bayer (PPMC)
  Mike Percy
  Jarek Jarcec Cecho
  Hari Shreedharan
  Brock Noland
  Patrick Hunt (IPMC)
  Arvind Prabhakar (PPMC)
  Tom White (IPMC)
  Eric Sammer (PPMC)
  Alexander Lorenz
  Prasad Mujumdar
  Matt Hogstrom (IPMC)
  Doug Cutting (IPMC)

+0 Votes: None

-1 Votes: None

Thanks to all who voted.

Thanks,
Arvind Prabhakar


On Mon, Mar 19, 2012 at 5:46 PM, Arvind Prabhakar arv...@apache.org wrote:
 This is the second incubator release for Apache Flume, version
 1.1.0-incubating. We are now voting on release candidate rc1.

 *** Please cast your vote within the next 72 hours ***

 The list of fixed issues:
 https://svn.apache.org/repos/asf/incubator/flume/tags/flume-1.1.0-incubating-rc1/CHANGELOG

 The tarball (*.tar.gz), signature (*.asc), checksum (*.md5sum,
 *.sha1sum) for the source and binary can be found at:
 http://people.apache.org/~arvind/flume/110rc1/

 The tag to be voted upon:
 https://svn.apache.org/repos/asf/incubator/flume/tags/flume-1.1.0-incubating-rc1/

 The KEYS file:
 http://www.apache.org/dist/incubator/flume/KEYS

 Changes since last build:
 * FLUME-1032. Fix Flume NG build for binary distribution
 * Updated change log and release notes.

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

[VOTE] Release Flume version 1.1.0-incubating

[Arvind Prabhakar]

This is the second incubator release for Apache Sqoop, version 1.1.0-incubating.

*** Please cast your vote within the next 72 hours ***

The list of fixed issues:
https://svn.apache.org/repos/asf/incubator/flume/tags/flume-1.1.0-incubating-rc0/CHANGELOG

The tarball (*.tar.gz), signature (*.asc), checksum (*.md5sum,
*.sha1sum) for the source and binary can be found at:

http://people.apache.org/~arvind/flume/110rc0/

The tag to be voted upon:
https://svn.apache.org/repos/asf/incubator/flume/tags/flume-1.1.0-incubating-rc0/

The KEYS file:
http://www.apache.org/dist/incubator/flume/KEYS

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

Re: [VOTE] Release Flume version 1.1.0-incubating

[Arvind Prabhakar]

Please disregard this mail due to a typo in the text. Will be sending
out a new vote email shortly.

Apologies for the inconvenience.

Thanks,
Arvind Prabhakar

On Mon, Mar 19, 2012 at 1:40 AM, Arvind Prabhakar arv...@apache.org wrote:
 This is the second incubator release for Apache Sqoop, version 
 1.1.0-incubating.

 *** Please cast your vote within the next 72 hours ***

 The list of fixed issues:
 https://svn.apache.org/repos/asf/incubator/flume/tags/flume-1.1.0-incubating-rc0/CHANGELOG

 The tarball (*.tar.gz), signature (*.asc), checksum (*.md5sum,
 *.sha1sum) for the source and binary can be found at:

 http://people.apache.org/~arvind/flume/110rc0/

 The tag to be voted upon:
 https://svn.apache.org/repos/asf/incubator/flume/tags/flume-1.1.0-incubating-rc0/

 The KEYS file:
 http://www.apache.org/dist/incubator/flume/KEYS

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

[VOTE] Release Flume version 1.1.0-incubating

[Arvind Prabhakar]

This is the second incubator release for Apache Flume, version 1.1.0-incubating.

*** Please cast your vote within the next 72 hours ***

The list of fixed issues:
https://svn.apache.org/repos/asf/incubator/flume/tags/flume-1.1.0-incubating-rc0/CHANGELOG

The tarball (*.tar.gz), signature (*.asc), checksum (*.md5sum,
*.sha1sum) for the source and binary can be found at:

http://people.apache.org/~arvind/flume/110rc0/

The tag to be voted upon:
https://svn.apache.org/repos/asf/incubator/flume/tags/flume-1.1.0-incubating-rc0/

The KEYS file:
http://www.apache.org/dist/incubator/flume/KEYS

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

Re: [VOTE] Release Flume version 1.1.0-incubating

[Arvind Prabhakar]

Thanks for the feedback Andrew. I will spin another candidate and call
a vote on that.

Thanks,
Arvind

On Mon, Mar 19, 2012 at 12:51 PM, Andrew Bayer andrew.ba...@gmail.com wrote:
 fwiw, I really think
 https://issues.apache.org/jira/browse/FLUME-1032should be addressed
 before 1.1.0 is released. The binary artifact, while
 just a convenience artifact, is rather incorrect.

 A.

 On Mon, Mar 19, 2012 at 7:48 AM, Ralph Goers 
 ralph.go...@dslextreme.comwrote:

 Just to be clear, although the version number doesn't indicate this the
 Flume community considers this to be a beta release.

 Ralph

 On Mar 19, 2012, at 1:45 AM, Arvind Prabhakar wrote:

  This is the second incubator release for Apache Flume, version
 1.1.0-incubating.
 
  *** Please cast your vote within the next 72 hours ***
 
  The list of fixed issues:
 
 https://svn.apache.org/repos/asf/incubator/flume/tags/flume-1.1.0-incubating-rc0/CHANGELOG
 
  The tarball (*.tar.gz), signature (*.asc), checksum (*.md5sum,
  *.sha1sum) for the source and binary can be found at:
 
  http://people.apache.org/~arvind/flume/110rc0/
 
  The tag to be voted upon:
 
 https://svn.apache.org/repos/asf/incubator/flume/tags/flume-1.1.0-incubating-rc0/
 
  The KEYS file:
  http://www.apache.org/dist/incubator/flume/KEYS


 -
 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

[VOTE] Release Apache Flume version 1.1.0-incubating (rc1)

[Arvind Prabhakar]

This is the second incubator release for Apache Flume, version
1.1.0-incubating. We are now voting on release candidate rc1.

*** Please cast your vote within the next 72 hours ***

The list of fixed issues:
https://svn.apache.org/repos/asf/incubator/flume/tags/flume-1.1.0-incubating-rc1/CHANGELOG

The tarball (*.tar.gz), signature (*.asc), checksum (*.md5sum,
*.sha1sum) for the source and binary can be found at:
http://people.apache.org/~arvind/flume/110rc1/

The tag to be voted upon:
https://svn.apache.org/repos/asf/incubator/flume/tags/flume-1.1.0-incubating-rc1/

The KEYS file:
http://www.apache.org/dist/incubator/flume/KEYS

Changes since last build:
* FLUME-1032. Fix Flume NG build for binary distribution
* Updated change log and release notes.

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

Re: Flume status (Was: [Incubator Wiki] Update of March2012 by ArvindPrabhakar)

[Arvind Prabhakar]

Hi Jukka,

On Mon, Mar 12, 2012 at 12:41 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
 +  * Release a version from the trunk.

 Since you've already made one incubating release, this is not a
 requirement for graduation.

 So based on your recent progress it seems to me like you're ready to
 start preparing for graduation. Looking at flume-dev@ I notice you've
 already been discussing this a bit, and prefer to avoid rushing
 things. That sounds good to me, and I'm looking forward to seeing
 Flume graduate as soon as you believe you're ready.

The main reason why we feel it is necessary for us to release from the
trunk is because up until now, our trunk contained sources in
com.cloudera.flume namespace which are not deprecated or transitioned
over to the new namespace. Very recently, we migrated our active
development branch (flume-728) to the trunk, moving the old trunk to
it's own dedicated branch (branch-0.9.5). Since then, the trunk
now contains sources in org.apache.flume namespace and we would
like to do a release from these sources.

Unless you mandate that we prioritize graduation over this
release, we would prefer to go with the release first.

Thanks,
Arvind Prabhakar


 BR,

 Jukka Zitting

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


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

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Arvind Prabhakar]

Hi Arun,

On Wed, Feb 29, 2012 at 11:11 AM, Arun C Murthy a...@hortonworks.com wrote:

 On Feb 29, 2012, at 11:10 AM, Arun C Murthy wrote:

 Arvind,

 (Sorry, I missed this discussion.)

 On Feb 28, 2012, at 10:53 AM, Arvind Prabhakar wrote:

 Please see [1] for details on why the code is like this. The short
 summary is that binary compatibility requires us to respect all
 extension points within the code.

 [1] https://cwiki.apache.org/confluence/display/SQOOP/Namespace+Migration


 This might be prior to your involvement with Sqoop, but it was initially 
 part of Apache Hadoop MapReduce as a contrib module prior to being moved out 
 to github.
 https://issues.apache.org/jira/browse/HADOOP-5815
 http://svn.apache.org/viewvc/hadoop/common/branches/branch-0.21-old/mapreduce/src/contrib/sqoop/

 Thus, does the Sqoop community also plan to maintain back-compat with 
 org.apache.hadoop.sqoop namespace for older users too?

 I can't seem to place whether we ever made Apache Hadoop releases which 
 included Sqoop before it got moved out...

 Uh, hit 'send' too soon...

 Never mind - I was looking at the wrong project in ASF jira (HADOOP and not 
 MAPREDUCE).

 Sqoop was removed via https://issues.apache.org/jira/browse/MAPREDUCE-1644

 Turns out we never released Sqoop via Apache Hadoop - so my question is moot. 
 Sorry for the noise.

Correct. This was disclosed at the time the project entered Incubator.
Please see the background section in the original proposal below:

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

Thanks,
Arvind Prabhakar



 Arun



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

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Arvind Prabhakar]

Thanks Greg. The vote was closed Feb 27, 2012. The tally of votes was
sent out shortly thereafter and can be found at:

http://markmail.org/message/vnti4j7kailm4hxb

Since consensus on graduation of Sqoop from Apache Incubator has been
reached, I will proceed to the next step of submitting the resolution proposal
we have voted on for consideration by the board.

Thanks to every one who voted and participated in the discussion.

Thanks,
Arvind Prabhakar


On Wed, Feb 29, 2012 at 12:41 PM, Greg Stein gst...@gmail.com wrote:
 The vote closed a day or two ago, passing with all +1's. (fyi)
 On Feb 29, 2012 2:48 PM, Benson Margulies bimargul...@gmail.com wrote:

 +1

 On Wed, Feb 29, 2012 at 2:39 PM, Niall Pemberton
 niall.pember...@gmail.com wrote:
  +1
 
  Niall
 
  On Fri, Feb 24, 2012 at 9:34 PM, Arvind Prabhakar arv...@apache.org
 wrote:
  This is a call for vote to graduate Sqoop podling from Apache Incubator.
 
  Sqoop entered Incubator in June of 2011. Since then it has added three
  new committers from diverse organizations, added two new PPMC members,
  and made two releases following the ASF policies and guidelines. The
  community of Sqoop is active, healthy and growing and has demonstrated
  the ability to self-govern using accepted Apache practices. Sqoop
  community has voted to proceed with graduation [1] and the result can
  be found at [2].
 
  Please cast your votes:
 
  [  ] +1 Graduate Sqoop podling from Apache Incubator
  [  ] +0 Indifferent to the graduation status of Sqoop podling
  [  ] -1 Reject graduation of Sqoop podling from Apache Incubator
 
  This vote will be open for 72 hours. Please find the proposed board
  resolution below.
 
  [1] http://markmail.org/thread/xwhjtkik7pgrmypi
  [2] http://s.apache.org/sqoop
 
  Thanks,
  Arvind Prabhakar
 
  X. Establish the Apache Sqoop 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 related to efficiently transferring
        bulk data between Apache Hadoop and structured datastores
        for distribution at no charge to the public.
 
        NOW, THEREFORE, BE IT RESOLVED, that a Project Management
        Committee (PMC), to be known as the Apache Sqoop Project,
        be and hereby is established pursuant to Bylaws of the
        Foundation; and be it further
 
        RESOLVED, that the Apache Sqoop Project be and hereby is
        responsible for the creation and maintenance of software
        related to efficiently transferring bulk data between Apache
        Hadoop and structured datastores; and be it further
 
        RESOLVED, that the office of Vice President, Apache Sqoop 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 Sqoop Project, and to have primary responsibility
        for management of the projects within the scope of
        responsibility of the Apache Sqoop 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 Sqoop Project:
 
          * Aaron Kimball             kimba...@apache.org
          * Andrew Bayer              aba...@apache.org
          * Ahmed Radwan              ah...@apache.org
          * Arvind Prabhakar          arv...@apache.org
          * Bilung Lee                b...@apache.org
          * Greg Cottman              gcott...@apache.org
          * Guy le Mar                guyle...@apache.org
          * Jaroslav Cecho            jar...@apache.org
          * Jonathan Hsieh            jmhs...@apache.org
          * Olivier Lamy              ol...@apache.org
          * Paul Zimdars              pzimd...@apache.org
          * Roman Shaposhnik          r...@apache.org
 
        NOW, THEREFORE, BE IT FURTHER RESOLVED, that Arvind Prabhakar
        be appointed to the office of Vice President, Apache Sqoop, 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 Sqoop 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 Sqoop Project; and be it further
 
        RESOLVED, that the Apache Sqoop Project be and hereby
        is tasked with the migration and rationalization of the Apache
        Incubator Sqoop podling; and be it further
 
        RESOLVED, that all responsibilities pertaining to the Apache
        Incubator Sqoop podling encumbered upon

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Arvind Prabhakar]

Alex, Alan,

Thanks for your feedback. Please take a look at SQOOP-369:

https://issues.apache.org/jira/browse/SQOOP-369

All of the source code for Sqoop that exists in com.cloudera namespace
is deprecated and the actual implementation of the product has been
moved under org.apache namespace.

The only reason com.cloudera namespace exists is in order to provide
backward compatibility with third party code.

Thanks,
Arvind Prabhakar




On Tue, Feb 28, 2012 at 12:39 AM, Alex Karasulu akaras...@apache.org wrote:
 On Mon, Feb 27, 2012 at 10:10 PM, Alan Gates ga...@hortonworks.com wrote:

 The source code in Sqoop still exists in both com.cloudera.sqoop and
 org.apache.sqoop packages and most of the code appears to include the
 com.cloudera packages and not the org.apache packages.  While in the
 incubator this seems fine.  Are we ok with this in a TLP?  I couldn't find
 any policy statements on it in the Apache pages.


 Good catch Alan. You are right we are not OK with this situation. It needs
 to be corrected then another vote can be taken.

 Thanks,
 Alex



 On Feb 24, 2012, at 1:34 PM, Arvind Prabhakar wrote:

  This is a call for vote to graduate Sqoop podling from Apache Incubator.
 
  Sqoop entered Incubator in June of 2011. Since then it has added three
  new committers from diverse organizations, added two new PPMC members,
  and made two releases following the ASF policies and guidelines. The
  community of Sqoop is active, healthy and growing and has demonstrated
  the ability to self-govern using accepted Apache practices. Sqoop
  community has voted to proceed with graduation [1] and the result can
  be found at [2].
 
  Please cast your votes:
 
  [  ] +1 Graduate Sqoop podling from Apache Incubator
  [  ] +0 Indifferent to the graduation status of Sqoop podling
  [  ] -1 Reject graduation of Sqoop podling from Apache Incubator
 
  This vote will be open for 72 hours. Please find the proposed board
  resolution below.
 
  [1] http://markmail.org/thread/xwhjtkik7pgrmypi
  [2] http://s.apache.org/sqoop
 
  Thanks,
  Arvind Prabhakar
 
  X. Establish the Apache Sqoop 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 related to efficiently transferring
        bulk data between Apache Hadoop and structured datastores
        for distribution at no charge to the public.
 
        NOW, THEREFORE, BE IT RESOLVED, that a Project Management
        Committee (PMC), to be known as the Apache Sqoop Project,
        be and hereby is established pursuant to Bylaws of the
        Foundation; and be it further
 
        RESOLVED, that the Apache Sqoop Project be and hereby is
        responsible for the creation and maintenance of software
        related to efficiently transferring bulk data between Apache
        Hadoop and structured datastores; and be it further
 
        RESOLVED, that the office of Vice President, Apache Sqoop 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 Sqoop Project, and to have primary responsibility
        for management of the projects within the scope of
        responsibility of the Apache Sqoop 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 Sqoop Project:
 
          * Aaron Kimball             kimba...@apache.org
          * Andrew Bayer              aba...@apache.org
          * Ahmed Radwan              ah...@apache.org
          * Arvind Prabhakar          arv...@apache.org
          * Bilung Lee                b...@apache.org
          * Greg Cottman              gcott...@apache.org
          * Guy le Mar                guyle...@apache.org
          * Jaroslav Cecho            jar...@apache.org
          * Jonathan Hsieh            jmhs...@apache.org
          * Olivier Lamy              ol...@apache.org
          * Paul Zimdars              pzimd...@apache.org
          * Roman Shaposhnik          r...@apache.org
 
        NOW, THEREFORE, BE IT FURTHER RESOLVED, that Arvind Prabhakar
        be appointed to the office of Vice President, Apache Sqoop, 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 Sqoop 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 Sqoop Project; and be it further
 
        RESOLVED

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Arvind Prabhakar]

On Tue, Feb 28, 2012 at 10:39 AM, Alan D. Cabrera l...@toolazydogs.com wrote:

 On Feb 28, 2012, at 10:13 AM, Patrick Hunt wrote:

 On Tue, Feb 28, 2012 at 9:57 AM, Alan D. Cabrera l...@toolazydogs.com 
 wrote:
 On Feb 28, 2012, at 9:16 AM, Patrick Hunt wrote:
 On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting jukka.zitt...@gmail.com 
 wrote:
 On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org 
 wrote:
 I'm not sure that JSR specs are the same as old Cloudera code.  JMHO.

 How about phrasing it as old Sqoop code instead. :-)

 Really it's about respect for existing users and others migrating to
 Apache. It's also about respect for the people doing the work. That's
 my understanding from discussions with the team at least.

 I don't see the technical requirement that this code needs to stay at 
 Apache and not Cloudera.

 I agree that this potentially could be an issue, but whether it's a
 technical requirement is up to the team who's doing the work. If
 Apache feels that there is a requirement that no project releases
 code/document/etc... under any package other than org.apache.* then
 that should be clearly defined and communicated. At this point my
 understanding is there is no such requirement.


 public class MySQLManager
    extends org.apache.sqoop.manager.MySQLManager {

  public MySQLManager(final SqoopOptions opts) {
    super(opts);
  }

 }

 If all the code is like this it is absolutely ridiculous to have this at 
 Apache and not Cloudera.

Please see [1] for details on why the code is like this. The short
summary is that binary compatibility requires us to respect all
extension points within the code.

[1] https://cwiki.apache.org/confluence/display/SQOOP/Namespace+Migration



 Regards,
 Alan



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

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Arvind Prabhakar]

On Tue, Feb 28, 2012 at 11:19 AM, Alan D. Cabrera l...@toolazydogs.com wrote:

 On Feb 28, 2012, at 10:53 AM, Arvind Prabhakar wrote:

 On Tue, Feb 28, 2012 at 10:39 AM, Alan D. Cabrera l...@toolazydogs.com 
 wrote:

 On Feb 28, 2012, at 10:13 AM, Patrick Hunt wrote:

 On Tue, Feb 28, 2012 at 9:57 AM, Alan D. Cabrera l...@toolazydogs.com 
 wrote:
 On Feb 28, 2012, at 9:16 AM, Patrick Hunt wrote:
 On Tue, Feb 28, 2012 at 1:06 AM, Jukka Zitting jukka.zitt...@gmail.com 
 wrote:
 On Tue, Feb 28, 2012 at 9:59 AM, Alex Karasulu akaras...@apache.org 
 wrote:
 I'm not sure that JSR specs are the same as old Cloudera code.  JMHO.

 How about phrasing it as old Sqoop code instead. :-)

 Really it's about respect for existing users and others migrating to
 Apache. It's also about respect for the people doing the work. That's
 my understanding from discussions with the team at least.

 I don't see the technical requirement that this code needs to stay at 
 Apache and not Cloudera.

 I agree that this potentially could be an issue, but whether it's a
 technical requirement is up to the team who's doing the work. If
 Apache feels that there is a requirement that no project releases
 code/document/etc... under any package other than org.apache.* then
 that should be clearly defined and communicated. At this point my
 understanding is there is no such requirement.


 public class MySQLManager
    extends org.apache.sqoop.manager.MySQLManager {

  public MySQLManager(final SqoopOptions opts) {
    super(opts);
  }

 }

 If all the code is like this it is absolutely ridiculous to have this at 
 Apache and not Cloudera.

 Please see [1] for details on why the code is like this. The short
 summary is that binary compatibility requires us to respect all
 extension points within the code.

 [1] https://cwiki.apache.org/confluence/display/SQOOP/Namespace+Migration

 IIUC, this document merely outlines how the move should be performed.  This 
 has been completed and what's left are bindings for those who wish to use the 
 old bindings from the old project.  There's no technical reason why those 
 bindings for the old project must be housed here at Apache.

You are right that it outlines how the move should be performed. Along
with that it also describes the motivation and specific technical
requirements to be fulfilled. Following are the relevant quotes from
the document:

[From Overview - Motivation]
Considering that there is a lot of third party code that is developed
on top of/to work with Sqoop, this migration is particularly risky for
backward compatibility and thus requires careful handling. This
document outlines the steps that seem reasonable for such migration.

[From Migration-General Approach - Technical Requirement]
When migrating a class from its previous namespace to the new, the key
requirement to address is that any code written to the old class
should still work at binary compatibility level. This also implies
that such code should be able to recompile with the migrated code base
without any modifications. In order to enable this, the general
approach is as follows:

* Any old public/protected/default access level API should be
preserved as is, but marked deprecated.
* Any logic that exists in this API should be migrated to the new namespace.

Note that API is not just method signatures but includes all aspects
of implementation such as class hierarchies, type compatibility,
static and non-static state etc.

Thanks,
Arvind Prabhakar



 Regards,
 Alan


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


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

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Arvind Prabhakar]

On Tue, Feb 28, 2012 at 12:51 PM, Patrick Hunt ph...@apache.org wrote:
 Note that API is not just method signatures but includes all aspects
 of implementation such as class hierarchies, type compatibility,
 static and non-static state etc.

 I think that it's good to have binary compatibility with Cloudera's old 
 bindings.   I still don't see why it's a requirement for Apache to house 
 code whose sole use is to provide backward compatible bindings for 
 Cloudera's old bindings.

 The Sqoop community moved from github where it was ASL licensed to
 Apache. There is now a Sqoop community at Apache that continues
 using/developing this code and they felt that having backward
 compatibility was useful. There is no stated restriction from Apache
 against doing such. I don't know the cost of just dropping the
 com.cloudera migration aids, but I suspect it would have been easier
 to just drop it than spend the time worrying about it and trying to
 provide a solution. I'm primarily acting as a mentor, Arvind would be
 in better position to provide insight into that background and why the
 community felt it was important to carry this forward.

Thanks Patrick. You are absolutely right in stating that it would have
been easier for us to drop any backward compatibility requirements and
get releases out quickly. The reason we chose to invest a lot in
preserving backward compatibility is for our community. Sqoop has an
active community that we care deeply about and we have done our best
to make sure continues to use Sqoop effectively. It is this thriving
community that was the primary reason for Sqoop to have come into the
incubator in the first place.

One thing I want to clarify is that any insinuation that
com.cloudera.* packages exist in Sqoop is to somehow help Cloudera and
it's customers couldn't be farther from the truth. The fact is that
Cloudera will continue to provide support for Sqoop with backward
compatibility regardless of whether the com.cloudera.* namespace is
retained or removed from Sqoop. If we decided to remove these
packages, it is the community that will suffer, not Cloudera.

I do believe that if this is only an Incubator policy and not an
Apache policy, it will be tantamount to discrimination against the
Sqoop community more than anything else. To say that JSR specs are not
the same as old Cloudera code, gives me the impression that some
communities have more power on how Apache implements its policies for
larger communities than on smaller communities. If that is indeed the
case, it will help to state that explicitly.

Thanks,
Arvind Prabhakar


 Patrick

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


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

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Arvind Prabhakar]

On Tue, Feb 28, 2012 at 1:25 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
 Hi,

 On Tue, Feb 28, 2012 at 9:53 PM, Patrick Hunt ph...@apache.org wrote:
 On Tue, Feb 28, 2012 at 12:24 PM, Alan D. Cabrera a...@toolazydogs.com 
 wrote:
 Opps, I didn't see that Arvind concluded the vote.  I still stand by my 
 opinion that there
 are some things that are not solely up to the people that are doing the 
 work.  Complete
 migration to the the org.apache.* package space is one of them.

 No worries. I respect your opinion and if Apache feels that this is
 important enough to make explicit then certainly Sqoop should make the
 changes. Short of that I don't see why we should hold Sqoop to a
 higher standard than is expected of other Apache projects. (that's
 _my_ opinion ;-) )

 Right.

 Basically the graduation vote by the IPMC is about determining whether
 the PPMC is capable of conducting itself according to the Apache Way
 and Apache policies on it's own. I didn't have time to look deeper
 into Sqoop yet, but all the +1s in this vote suggest that the Sqoop
 PPMC is ready to take on that responsibility. Along with that
 responsibility comes the right to make value judgements on topics like
 this where existing policies aren't clearly spelled out.

Thanks Jukka. In fact, Sqoop already has a plan in place to completely
remove com.cloudera.* namespace from its contents via the next major
revision of the product. The work for that has already started and
currently exists under the branch sqoop2 [3], tracked by SQOOP-365
[4]. We hope that in a few months time, we will have feature parity in
this branch with the trunk, which is when we will promote it to the
trunk.

[3] https://svn.apache.org/repos/asf/incubator/sqoop/branches/sqoop2/
[4] https://issues.apache.org/jira/browse/SQOOP-365


 Personally I think we should let the vote result stand with guidance
 to the new Sqoop PMC to discuss the matter with the branding team at
 trademarks@ to seek Apache-wide consensus. I encourage anyone who
 feels strongly about this (the point being made clearly has some
 merit) make their case to trademarks@ as it's IMHO not really the task
 of the Incubator to be forming new policy on this, especially with all
 the recent talk about scaling down the ambitions of the IPMC.

This sounds like a great solution that addresses the concern and does
not unduly penalize the Sqoop project. On behalf of Sqoop PMC, I will
be happy to take this up with the branding team and trademarks@ to
drive a definitive resolution. I also volunteer personally to discuss
and seek Apache-wide consensus on this issue for not only the benefit
of Sqoop, but for other projects who may be in this state inside or
outside of the Incubator.

Thanks,
Arvind Prabhakar


 BR,

 Jukka Zitting

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


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

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Arvind Prabhakar]

On Tue, Feb 28, 2012 at 2:50 PM, Alex Karasulu akaras...@apache.org wrote:
 On Tue, Feb 28, 2012 at 11:39 PM, Arvind Prabhakar arv...@apache.orgwrote:

 On Tue, Feb 28, 2012 at 1:25 PM, Jukka Zitting jukka.zitt...@gmail.com
 wrote:
  Hi,
 
  On Tue, Feb 28, 2012 at 9:53 PM, Patrick Hunt ph...@apache.org wrote:
  On Tue, Feb 28, 2012 at 12:24 PM, Alan D. Cabrera a...@toolazydogs.com
 wrote:
  Opps, I didn't see that Arvind concluded the vote.  I still stand by
 my opinion that there
  are some things that are not solely up to the people that are doing
 the work.  Complete
  migration to the the org.apache.* package space is one of them.
 
  No worries. I respect your opinion and if Apache feels that this is
  important enough to make explicit then certainly Sqoop should make the
  changes. Short of that I don't see why we should hold Sqoop to a
  higher standard than is expected of other Apache projects. (that's
  _my_ opinion ;-) )
 
  Right.
 
  Basically the graduation vote by the IPMC is about determining whether
  the PPMC is capable of conducting itself according to the Apache Way
  and Apache policies on it's own. I didn't have time to look deeper
  into Sqoop yet, but all the +1s in this vote suggest that the Sqoop
  PPMC is ready to take on that responsibility. Along with that
  responsibility comes the right to make value judgements on topics like
  this where existing policies aren't clearly spelled out.

 Thanks Jukka. In fact, Sqoop already has a plan in place to completely
 remove com.cloudera.* namespace from its contents via the next major
 revision of the product. The work for that has already started and
 currently exists under the branch sqoop2 [3], tracked by SQOOP-365
 [4]. We hope that in a few months time, we will have feature parity in
 this branch with the trunk, which is when we will promote it to the
 trunk.

 [3] https://svn.apache.org/repos/asf/incubator/sqoop/branches/sqoop2/
 [4] https://issues.apache.org/jira/browse/SQOOP-365

 
  Personally I think we should let the vote result stand with guidance
  to the new Sqoop PMC to discuss the matter with the branding team at
  trademarks@ to seek Apache-wide consensus. I encourage anyone who
  feels strongly about this (the point being made clearly has some
  merit) make their case to trademarks@ as it's IMHO not really the task
  of the Incubator to be forming new policy on this, especially with all
  the recent talk about scaling down the ambitions of the IPMC.

 This sounds like a great solution that addresses the concern and does
 not unduly penalize the Sqoop project.


 You really should not be seeing this as being penalized. It's not about
 that.

The penalty I reference is for the Sqoop community which will be
impacted by incompatible changes you are suggesting.

I appreciate your feedback, and request that you keep the discussion
relavant to the issue at hand without making references like Cloudera
people come out of the woodwork. Please understand that we interact
with Apache as individual contributors and committers. Such references
undermine our efforts and are honestly insulting to everyone who has
spent hours on delivering the product.

Thanks,
Arvind Prabhakar



 Alex

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

Re: [VOTE] Graduate Sqoop podling from Apache Incubator

[Arvind Prabhakar]

The VOTE is now closed. I will be sending a RESULT mail separately.

Thanks to all who voted.

Thanks,
Arvind Prabhakar

On Mon, Feb 27, 2012 at 5:03 PM, Joey Echeverria j...@cloudera.com wrote:
 +1 (non-binding)

 On Mon, Feb 27, 2012 at 7:36 PM, Patrick Hunt ph...@apache.org wrote:
 +1 (binding)

 On Sun, Feb 26, 2012 at 3:24 AM, Tommaso Teofili
 tommaso.teof...@gmail.com wrote:
 +1 (binding)
 Tommaso

 2012/2/24 Arvind Prabhakar arv...@apache.org

 This is a call for vote to graduate Sqoop podling from Apache Incubator.

 Sqoop entered Incubator in June of 2011. Since then it has added three
 new committers from diverse organizations, added two new PPMC members,
 and made two releases following the ASF policies and guidelines. The
 community of Sqoop is active, healthy and growing and has demonstrated
 the ability to self-govern using accepted Apache practices. Sqoop
 community has voted to proceed with graduation [1] and the result can
 be found at [2].

 Please cast your votes:

 [  ] +1 Graduate Sqoop podling from Apache Incubator
 [  ] +0 Indifferent to the graduation status of Sqoop podling
 [  ] -1 Reject graduation of Sqoop podling from Apache Incubator

 This vote will be open for 72 hours. Please find the proposed board
 resolution below.

 [1] http://markmail.org/thread/xwhjtkik7pgrmypi
 [2] http://s.apache.org/sqoop

 Thanks,
 Arvind Prabhakar

 X. Establish the Apache Sqoop 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 related to efficiently transferring
       bulk data between Apache Hadoop and structured datastores
       for distribution at no charge to the public.

       NOW, THEREFORE, BE IT RESOLVED, that a Project Management
       Committee (PMC), to be known as the Apache Sqoop Project,
       be and hereby is established pursuant to Bylaws of the
       Foundation; and be it further

       RESOLVED, that the Apache Sqoop Project be and hereby is
       responsible for the creation and maintenance of software
       related to efficiently transferring bulk data between Apache
       Hadoop and structured datastores; and be it further

       RESOLVED, that the office of Vice President, Apache Sqoop 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 Sqoop Project, and to have primary responsibility
       for management of the projects within the scope of
       responsibility of the Apache Sqoop 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 Sqoop Project:

         * Aaron Kimball             kimba...@apache.org
         * Andrew Bayer              aba...@apache.org
         * Ahmed Radwan              ah...@apache.org
         * Arvind Prabhakar          arv...@apache.org
         * Bilung Lee                b...@apache.org
         * Greg Cottman              gcott...@apache.org
         * Guy le Mar                guyle...@apache.org
         * Jaroslav Cecho            jar...@apache.org
         * Jonathan Hsieh            jmhs...@apache.org
         * Olivier Lamy              ol...@apache.org
         * Paul Zimdars              pzimd...@apache.org
         * Roman Shaposhnik          r...@apache.org

       NOW, THEREFORE, BE IT FURTHER RESOLVED, that Arvind Prabhakar
       be appointed to the office of Vice President, Apache Sqoop, 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 Sqoop 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 Sqoop Project; and be it further

       RESOLVED, that the Apache Sqoop Project be and hereby
       is tasked with the migration and rationalization of the Apache
       Incubator Sqoop podling; and be it further

       RESOLVED, that all responsibilities pertaining to the Apache
       Incubator Sqoop podling encumbered upon the Apache Incubator
       Project are hereafter discharged.

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



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

[VOTE][RESULT] Graduate Sqoop podling from Apache Incubator

[Arvind Prabhakar]

The vote by Apache Incubator to graduate Sqoop podling has passed.
Tally of votes is as follows:

8 +1 votes (6 binding, 2 non-binding)
0 +0 votes
0 -1 votes

Binding +1 votes:
Chris A Mattmann
Ralph Goers
Olivier Lamy
Mark Struberg
Tommaso Teofili
Patrick Hunt

Non-binding +1 votes:
Joey Echeverria
Jarek Jarcec Cecho

The VOTE thread for this can be found at [1].

[1] http://markmail.org/thread/uxvda2j6mkxleehk

Thanks,
Arvind Prabhakar

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

[VOTE] Graduate Sqoop podling from Apache Incubator

[Arvind Prabhakar]

This is a call for vote to graduate Sqoop podling from Apache Incubator.

Sqoop entered Incubator in June of 2011. Since then it has added three
new committers from diverse organizations, added two new PPMC members,
and made two releases following the ASF policies and guidelines. The
community of Sqoop is active, healthy and growing and has demonstrated
the ability to self-govern using accepted Apache practices. Sqoop
community has voted to proceed with graduation [1] and the result can
be found at [2].

Please cast your votes:

[  ] +1 Graduate Sqoop podling from Apache Incubator
[  ] +0 Indifferent to the graduation status of Sqoop podling
[  ] -1 Reject graduation of Sqoop podling from Apache Incubator

This vote will be open for 72 hours. Please find the proposed board
resolution below.

[1] http://markmail.org/thread/xwhjtkik7pgrmypi
[2] http://s.apache.org/sqoop

Thanks,
Arvind Prabhakar

X. Establish the Apache Sqoop 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 related to efficiently transferring
   bulk data between Apache Hadoop and structured datastores
   for distribution at no charge to the public.

   NOW, THEREFORE, BE IT RESOLVED, that a Project Management
   Committee (PMC), to be known as the Apache Sqoop Project,
   be and hereby is established pursuant to Bylaws of the
   Foundation; and be it further

   RESOLVED, that the Apache Sqoop Project be and hereby is
   responsible for the creation and maintenance of software
   related to efficiently transferring bulk data between Apache
   Hadoop and structured datastores; and be it further

   RESOLVED, that the office of Vice President, Apache Sqoop 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 Sqoop Project, and to have primary responsibility
   for management of the projects within the scope of
   responsibility of the Apache Sqoop 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 Sqoop Project:

 * Aaron Kimball kimba...@apache.org
 * Andrew Bayer  aba...@apache.org
 * Ahmed Radwan  ah...@apache.org
 * Arvind Prabhakar  arv...@apache.org
 * Bilung Leeb...@apache.org
 * Greg Cottman  gcott...@apache.org
 * Guy le Marguyle...@apache.org
 * Jaroslav Cechojar...@apache.org
 * Jonathan Hsiehjmhs...@apache.org
 * Olivier Lamy  ol...@apache.org
 * Paul Zimdars  pzimd...@apache.org
 * Roman Shaposhnik  r...@apache.org

   NOW, THEREFORE, BE IT FURTHER RESOLVED, that Arvind Prabhakar
   be appointed to the office of Vice President, Apache Sqoop, 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 Sqoop 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 Sqoop Project; and be it further

   RESOLVED, that the Apache Sqoop Project be and hereby
   is tasked with the migration and rationalization of the Apache
   Incubator Sqoop podling; and be it further

   RESOLVED, that all responsibilities pertaining to the Apache
   Incubator Sqoop podling encumbered upon the Apache Incubator
   Project are hereafter discharged.

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

Re: [VOTE] Graduate Sqoop from Apache Incubator

[Arvind Prabhakar]

The VOTE is now closed. I will be sending a RESULT mail separately.

Thanks to all who voted.

Thanks,
Arvind Prabhakar

On Sun, Feb 19, 2012 at 9:22 AM, Arvind Prabhakar arv...@apache.org wrote:

 The Apache Sqoop project entered incubator in June of 2011. Since then we
 have added three new committers from diverse organizations and added two
 new PPMC members. The codebase of our product has steadily grown and we
 have made two releases following the ASF policies and guidelines. Thanks to
 the excellent mentorship we have received through this period, we have
 learnt to self-govern and grow our community using accepted Apache
 practices. Sqoop continues to attract interest from contributors and users
 from all across the world.

 Given these milestones, I strongly feel that Sqoop is ready to graduate
 from Incubator.

 The first step towards graduation is to vote as a community that Sqoop is
 ready to graduate. If the vote is successful, we will draft a board
 resolution proposal and call it to vote on the general Incubator list. The
 complete graduation process is described [1].

 Please cast your votes:

 [  ]  +1 Graduate Sqoop from Incubator
 [  ]  +0 Indifferent to graduation status of Sqoop
 [  ]  -1 Reject graduation of Sqoop from Incubator

 This vote will remain open for at least 72 hours from now.

 [1] http://incubator.apache.org/guides/graduation.html

 Thanks,
 Arvind Prabhakar

Re: [VOTE] Graduate Sqoop from Apache

[Arvind Prabhakar]

The VOTE is now closed. I will be sending a RESULT mail separately.

Thanks to all who voted.

Thanks,
Arvind Prabhakar

On Sun, Feb 19, 2012 at 9:22 AM, Arvind Prabhakar arv...@apache.org wrote:

 The Apache Sqoop project entered incubator in June of 2011. Since then we
 have added three new committers from diverse organizations and added two
 new PPMC members. The codebase of our product has steadily grown and we
 have made two releases following the ASF policies and guidelines. Thanks to
 the excellent mentorship we have received through this period, we have
 learnt to self-govern and grow our community using accepted Apache
 practices. Sqoop continues to attract interest from contributors and users
 from all across the world.

 Given these milestones, I strongly feel that Sqoop is ready to graduate
 from Incubator.

 The first step towards graduation is to vote as a community that Sqoop is
 ready to graduate. If the vote is successful, we will draft a board
 resolution proposal and call it to vote on the general Incubator list. The
 complete graduation process is described [1].

 Please cast your votes:

 [  ]  +1 Graduate Sqoop from Incubator
 [  ]  +0 Indifferent to graduation status of Sqoop
 [  ]  -1 Reject graduation of Sqoop from Incubator

 This vote will remain open for at least 72 hours from now.

 [1] http://incubator.apache.org/guides/graduation.html

 Thanks,
 Arvind Prabhakar

[VOTE][RESULT] Graduate Sqoop from Apache

[Arvind Prabhakar]

The community vote to graduate Sqoop from Apache Incubator has passed.
Tally of votes is as follows:

13 +1 votes (4 IPMC, 6 committers, 3 contributors)
  0 +0 votes
  0 -1  votes

IPMC +1 votes:
Olivier Lamy (olamy)
Tom White (tomwhite)
Mohammad Nour El-Din (mnour)
Patrick Hunt (phunt)

Committer +1 votes:
Jaroslav Cecho (jarcec)
Alex Newman (posix4e)
Paul Zimdars (pzimdars)
Ahmed Radwan (ahmed)
Bilung Lee (blee)
Arvind Prabhakar (arvind)

Contributor +1 votes:
Brock Noland
Joey Echeverria
Kathleen Ting

The VOTE thread for this can be found at [1]

[1] http://markmail.org/thread/xwhjtkik7pgrmypi

We will now proceed to draft a board resolution proposal and call it to
vote on the general Incubator list.

Thanks,
Arvind Prabhakar

[VOTE] Graduate Sqoop from Apache Incubator

[Arvind Prabhakar]

The Apache Sqoop project entered incubator in June of 2011. Since then we
have added three new committers from diverse organizations and added two
new PPMC members. The codebase of our product has steadily grown and we
have made two releases following the ASF policies and guidelines. Thanks to
the excellent mentorship we have received through this period, we have
learnt to self-govern and grow our community using accepted Apache
practices. Sqoop continues to attract interest from contributors and users
from all across the world.

Given these milestones, I strongly feel that Sqoop is ready to graduate
from Incubator.

The first step towards graduation is to vote as a community that Sqoop is
ready to graduate. If the vote is successful, we will draft a board
resolution proposal and call it to vote on the general Incubator list. The
complete graduation process is described [1].

Please cast your votes:

[  ]  +1 Graduate Sqoop from Incubator
[  ]  +0 Indifferent to graduation status of Sqoop
[  ]  +1 Reject graduation of Sqoop from Incubator

This vote will remain open for at least 72 hours from now.

[1] http://incubator.apache.org/guides/graduation.html

Thanks,
Arvind Prabhakar

Re: [VOTE] Graduate Sqoop from Apache Incubator

[Arvind Prabhakar]

Hi,

I will have to cancel this vote thread due to a typo in the vote options in
my original mail below. Specifically, the option to reject the vote
is mentioned as +1 when it should be -1 instead. In order to make sure that
there is absolutely no ambiguity in the vote, I will send out a new vote
thread in a few minutes. My sincere apologies for the inconvenience.

Thanks,
Arvind Prabhakar

On Sun, Feb 19, 2012 at 1:00 AM, Arvind Prabhakar arv...@apache.org wrote:

 The Apache Sqoop project entered incubator in June of 2011. Since then we
 have added three new committers from diverse organizations and added two
 new PPMC members. The codebase of our product has steadily grown and we
 have made two releases following the ASF policies and guidelines. Thanks to
 the excellent mentorship we have received through this period, we have
 learnt to self-govern and grow our community using accepted Apache
 practices. Sqoop continues to attract interest from contributors and users
 from all across the world.

 Given these milestones, I strongly feel that Sqoop is ready to graduate
 from Incubator.

 The first step towards graduation is to vote as a community that Sqoop is
 ready to graduate. If the vote is successful, we will draft a board
 resolution proposal and call it to vote on the general Incubator list. The
 complete graduation process is described [1].

 Please cast your votes:

 [  ]  +1 Graduate Sqoop from Incubator
 [  ]  +0 Indifferent to graduation status of Sqoop
 [  ]  +1 Reject graduation of Sqoop from Incubator

 This vote will remain open for at least 72 hours from now.

 [1] http://incubator.apache.org/guides/graduation.html

 Thanks,
 Arvind Prabhakar

[VOTE] Graduate Sqoop from Apache

[Arvind Prabhakar]

The Apache Sqoop project entered incubator in June of 2011. Since then we
have added three new committers from diverse organizations and added two
new PPMC members. The codebase of our product has steadily grown and we
have made two releases following the ASF policies and guidelines. Thanks to
the excellent mentorship we have received through this period, we have
learnt to self-govern and grow our community using accepted Apache
practices. Sqoop continues to attract interest from contributors and users
from all across the world.

Given these milestones, I strongly feel that Sqoop is ready to graduate
from Incubator.

The first step towards graduation is to vote as a community that Sqoop is
ready to graduate. If the vote is successful, we will draft a board
resolution proposal and call it to vote on the general Incubator list. The
complete graduation process is described [1].

Please cast your votes:

[  ]  +1 Graduate Sqoop from Incubator
[  ]  +0 Indifferent to graduation status of Sqoop
[  ]  -1 Reject graduation of Sqoop from Incubator

This vote will remain open for at least 72 hours from now.

[1] http://incubator.apache.org/guides/graduation.html

Thanks,
Arvind Prabhakar

Re: [VOTE] Graduate Sqoop from Apache Incubator

[Arvind Prabhakar]

Thanks Chris for your feedback. Yes, this vote is only intended to be held
in the Sqoop community. However, according to the guide on graduation [2],
the guidance on community graduation vote explicitly suggests copying the
Incubator general list when the vote is proposed. Hence, I added the
general list in the cc of the vote mail.

Also, I do state explicitly in the vote mail that if this community vote is
successful, we will draft a board resolution proposal and call it to vote
on the general Incubator list. When we do draft the board resolution
proposal it will have details about initial PMC.

[2] http://incubator.apache.org/guides/graduation.html#tlp-community-vote

Thanks,
Arvind Prabhakar

On Sun, Feb 19, 2012 at 9:24 AM, Mattmann, Chris A (388J) 
chris.a.mattm...@jpl.nasa.gov wrote:

 Hi Arvind,

 I would encourage removing another ambiguity that I saw -- I think you
 meant
 to only hold this on sqoop-dev, right? That's because by the time it gets
 to the
 IPMC, at least one thing I'm interested in is the proposed PMC, if there
 are
 3 ASF members or not, etc., and that would be part of the resolution that
 you guys haven't drafted yet.

 If you hold this on general@, then before VOTE'ing I would like to see the
 proposed graduation resolution. There's a bunch of templates, here's the
 one
 that Lucy just used:

 http://wiki.apache.org/lucy/LucyCharter

 Thanks!

 Cheers,
 Chris

 On Feb 19, 2012, at 9:19 AM, Arvind Prabhakar wrote:

  Hi,
 
  I will have to cancel this vote thread due to a typo in the vote options
 in
  my original mail below. Specifically, the option to reject the vote
  is mentioned as +1 when it should be -1 instead. In order to make sure
 that
  there is absolutely no ambiguity in the vote, I will send out a new vote
  thread in a few minutes. My sincere apologies for the inconvenience.
 
  Thanks,
  Arvind Prabhakar
 
  On Sun, Feb 19, 2012 at 1:00 AM, Arvind Prabhakar arv...@apache.org
 wrote:
 
  The Apache Sqoop project entered incubator in June of 2011. Since then
 we
  have added three new committers from diverse organizations and added two
  new PPMC members. The codebase of our product has steadily grown and we
  have made two releases following the ASF policies and guidelines.
 Thanks to
  the excellent mentorship we have received through this period, we have
  learnt to self-govern and grow our community using accepted Apache
  practices. Sqoop continues to attract interest from contributors and
 users
  from all across the world.
 
  Given these milestones, I strongly feel that Sqoop is ready to graduate
  from Incubator.
 
  The first step towards graduation is to vote as a community that Sqoop
 is
  ready to graduate. If the vote is successful, we will draft a board
  resolution proposal and call it to vote on the general Incubator list.
 The
  complete graduation process is described [1].
 
  Please cast your votes:
 
  [  ]  +1 Graduate Sqoop from Incubator
  [  ]  +0 Indifferent to graduation status of Sqoop
  [  ]  +1 Reject graduation of Sqoop from Incubator
 
  This vote will remain open for at least 72 hours from now.
 
  [1] http://incubator.apache.org/guides/graduation.html
 
  Thanks,
  Arvind Prabhakar
 


 ++
 Chris Mattmann, Ph.D.
 Senior Computer Scientist
 NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
 Office: 171-266B, Mailstop: 171-246
 Email: chris.a.mattm...@nasa.gov
 WWW:   http://sunset.usc.edu/~mattmann/
 ++
 Adjunct Assistant Professor, Computer Science Department
 University of Southern California, Los Angeles, CA 90089 USA
 ++


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

Re: [VOTE] Release Oozie 3.1.3-incubating (RC2)

[Arvind Prabhakar]

Very happy to see this release candiate going out. I played around with a
bit and here is what I found:

Good Stuff:
* Verified md5 sum and signature

Possible Issues:
* The NOTICE.txt file has a dated copyright header (2011)
* Not sure if this is an issue but the readme.txt file is named in lower
case. I have only seen upper case names.
* See the following test failure when I run mvn install:

testUnpauseBundleAndCoordinator(org.apache.oozie.service.TestPauseTransitService)

* When I run rat however, it flags the following files as unapproved
licenses:
  oozie-3.1.3-incubating/core/src/test/resources/PigMain.txt
  oozie-3.1.3-incubating/core/src/test/resources/test-ioutils.txt
  oozie-3.1.3-incubating/docs/src/site/twiki/AG_Install.twiki
  oozie-3.1.3-incubating/docs/src/site/twiki/AG_Monitoring.twiki
  oozie-3.1.3-incubating/docs/src/site/twiki/BundleFunctionalSpec.twiki
  oozie-3.1.3-incubating/docs/src/site/twiki/CoordinatorFunctionalSpec.twiki
  oozie-3.1.3-incubating/docs/src/site/twiki/DG_CommandLineTool.twiki
  oozie-3.1.3-incubating/docs/src/site/twiki/DG_CoordinatorRerun.twiki
  oozie-3.1.3-incubating/docs/src/site/twiki/DG_CustomActionExecutor.twiki
  oozie-3.1.3-incubating/docs/src/site/twiki/DG_EmailActionExtension.twiki
  oozie-3.1.3-incubating/docs/src/site/twiki/DG_Examples.twiki
  oozie-3.1.3-incubating/docs/src/site/twiki/DG_Overview.twiki
  oozie-3.1.3-incubating/docs/src/site/twiki/DG_QuickStart.twiki
  oozie-3.1.3-incubating/docs/src/site/twiki/DG_UsingHadoopKerberos.twiki
  oozie-3.1.3-incubating/docs/src/site/twiki/DG_WorkflowReRun.twiki
  oozie-3.1.3-incubating/docs/src/site/twiki/ENG_Building.twiki
  oozie-3.1.3-incubating/docs/src/site/twiki/ENG_MiniOozie.twiki
  oozie-3.1.3-incubating/docs/src/site/twiki/WebServicesAPI.twiki
  oozie-3.1.3-incubating/docs/src/site/twiki/WorkflowFunctionalSpec.twiki
  oozie-3.1.3-incubating/examples/src/main/data/_SUCCESS
  oozie-3.1.3-incubating/examples/src/main/data/data.txt
  oozie-3.1.3-incubating/examples/src/main/data/log01.txt
  oozie-3.1.3-incubating/examples/src/main/data/log02.txt
  oozie-3.1.3-incubating/examples/src/main/data/log03.txt
  oozie-3.1.3-incubating/examples/src/main/data/log04.txt
  oozie-3.1.3-incubating/examples/src/main/data/log05.txt
  oozie-3.1.3-incubating/examples/src/main/data/log06.txt
  oozie-3.1.3-incubating/release-log.txt
  oozie-3.1.3-incubating/work.log

Not sure if any of these merit respin of the bits, but wanted to point
these out for discussion.

Thanks,
Arvind Prabhakar


On Thu, Feb 16, 2012 at 3:56 PM, Mohammad Islam misla...@yahoo.com wrote:

 Updated the content with typo correction.


 Hi All,

 Oozie community is delighted to share the RC for first Oozie release from
 Apache.
 The vote at oozie-users@incubator has been +1'd. Please try it out and
 vote for
 the Apache Oozie 3.1.3-incubating release.

 Artifacts and signatures:
 http://people.apache.org/~kamrul/oozie-3.1.3-incubating-candidate-2/

 SVN Tag:
 http://svn.apache.org/repos/asf/incubator/oozie/tags/release-3.1.3-rc2/


 PGP release keys:
 http://svn.apache.org/repos/asf/incubator/oozie/trunk/KEYS

 Vote thread at oozie-user@:

 http://mail-archives.apache.org/mod_mbox/incubator-oozie-users/201202.mbox/%3c1329180206.98608.yahoomail...@web161301.mail.bf1.yahoo.com%3e


 [ ] +1 Release the packages as Apache Oozie 3.1.3-incubating
 []   0
 [ ] -1 Do not release the packages because...

 Thanks,
 Mohammad



 - Original Message -
 From: Mohammad Islam misla...@yahoo.com
 To: general@incubator.apache.org general@incubator.apache.org
 Cc:
 Sent: Thursday, February 16, 2012 3:13 PM
 Subject: [VOTE] Release Oozie 3.1.3-incubating (RC2)

 Hi all,

 Oozie community is delighted to share that RC for first Oozie release from
 Apache.
 The vote at oozie-users@incubator has been +1'd. Please try it out and
 vote for
 the Apache Oozie 3.1.3-incubating release.

 Artifacts and signatures:
 http://people.apache.org/~kamrul/oozie-3.1.3-incubating-candidate-2/

 SVN Tag:
 http://svn.apache.org/repos/asf/incubator/oozie/tags/release-3.1.3-rc2/


 PGP release keys:
 http://svn.apache.org/repos/asf/incubator/oozie/trunk/KEYS

 Vote thread at oozie-user@:

 http://mail-archives.apache.org/mod_mbox/incubator-oozie-users/201202.mbox/%3c1329180206.98608.yahoomail...@web161301.mail.bf1.yahoo.com%3e


 [ ] +1 Release the packages as Apache HCatalog 0.2-incubating
 []   0
 [ ] -1 Do not release the packages because...

 Thanks,
 Mohammad

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

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

Re: [VOTE] Release Sqoop version 1.4.0-incubating (with release candidate rc1)

[Arvind Prabhakar]

On Mon, Nov 21, 2011 at 5:15 AM, sebb seb...@gmail.com wrote:
 On 21 November 2011 07:40, Bilung Lee b...@apache.org wrote:
 This will be the first incubator release for Apache Sqoop, version
 1.4.0-incubating.

 We got two IPMC votes from our dev list and are looking for a third.
  Thanks!

 *** Please cast the vote by November 23, 2011 ***

 Dev list vote result:
 http://markmail.org/message/jehsoo2vi6xboovu

 The list of fixed issues:
 http://svn.apache.org/repos/asf/incubator/sqoop/branches/branch-1.4.0/CHANGES.txt

 The tarball (*.tar.gz), signature (*.asc), checksum (*.md5), license audit
 result (log/*.ant_releaseaudit.log), and test result (log/*.ant_test.log):
 http://people.apache.org/~blee/sqoop-1.4.0-incubating-rc1/

 There are RAT run logs, but could not find the RAT reports.
 I did not find any issues when running RAT locally, however please
 provide the actual reports next time.

 The md5 hashes have an unusual format:

 sqoop-1.4.0-incubating.tar.gz: F8 80 44 33 7D D5 9B AF  DB 2D 1B 9B C9 AA C9 
 7B
 rather than
 F88044337DD59BAFDB2D1B9BC9AAC97B  sqoop-1.4.0-incubating.tar.gz
 which means that some tools may not be able to process them.

 Not a blocker.

 The tag to be voted upon:
 http://svn.apache.org/repos/asf/incubator/sqoop/tags/release-1.4.0-rc1

 Lots of missing/incorrect SVN properties, see:
 https://issues.apache.org/jira/browse/SQOOP-395

 There are a lot of Java files with packages under com.cloudera.
 I assume these will all be replaced with org.apache packages?

 The KEYS file:
 http://www.apache.org/dist/incubator/sqoop/KEYS


 The sqoop web-site is missing the required incubator disclaimer.
 This needs to be fixed ASAP please.

I have updated the website with disclaimer text on the main page. Once
the mirrors have all synced up, this should be visible to all.

Thanks,
Arvind


 -
 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] Oozie to join the Incubator

[Arvind Prabhakar]

+1 (non-binding)

Thanks,
Arvind

On Wed, Jun 29, 2011 at 12:10 PM, Mohammad Islam misla...@yahoo.com wrote:
 Hi All,

 The discussion about Oozie proposal is settling down. Therefore I would like 
 to
 initiate a vote to accept Oozie as an Apache Incubator project.

 The latest proposal is pasted at the end and it could be found in the wiki as
 well:

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


 The related discussion thread is at:
 http://www.mail-archive.com/general@incubator.apache.org/msg29633.html


 Please cast your votes:

 [  ] +1 Accept Oozie for incubation
 [  ] +0 Indifferent to Oozie incubation
 [  ] -1 Reject Oozie for incubation

 This vote will close 72 hours  from now.

 Regards,
 Mohammad


 Abstract
 Oozie is a server-based workflow scheduling and coordination system to manage
 data processing jobs for Apache HadoopTM.

 Proposal
 Oozie is an  extensible, scalable and reliable system to define, manage,
 schedule,  and execute complex Hadoop workloads via web services. More
 specifically, this includes:

        * XML-based declarative framework to specify a job or a complex 
 workflow of
 dependent jobs.

        * Support different types of job such as Hadoop Map-Reduce, Pipe, 
 Streaming,
 Pig, Hive and custom java applications.

        * Workflow scheduling based on frequency and/or data availability.
        * Monitoring capability, automatic retry and failure handing of jobs.
        * Extensible and pluggable architecture to allow arbitrary grid 
 programming
 paradigms.

        * Authentication, authorization, and capacity-aware load throttling to 
 allow
 multi-tenant software as a service.

 Background
 Most data  processing applications require multiple jobs to achieve their 
 goals,
 with inherent dependencies among the jobs. A dependency could be  sequential,
 where one job can only start after another job has finished.  Or it could be
 conditional, where the execution of a job depends on the  return value or 
 status
 of another job. In other cases, parallel  execution of multiple jobs may be
 permitted – or desired – to exploit  the massive pool of compute nodes 
 provided
 by Hadoop.

 These  job dependencies are often expressed as a Directed Acyclic Graph, also
 called a workflow. A node in the workflow is typically a job (a  computation 
 on
 the grid) or another type of action such as an eMail  notification. 
 Computations
 can be expressed in map/reduce, Pig, Hive or  any other programming paradigm
 available on the grid. Edges of the graph  represent transitions from one node
 to the next, as the execution of a  workflow proceeds.

 Describing  a workflow in a declarative way has the advantage of decoupling 
 job
 dependencies and execution control from application logic. Furthermore,  the
 workflow is modularized into jobs that can be reused within the same  workflow
 or across different workflows. Execution of the workflow is  then driven by a
 runtime system without understanding the application  logic of the jobs. This
 runtime system specializes in reliable and  predictable execution: It can 
 retry
 actions that have failed or invoke a  cleanup action after termination of the
 workflow; it can monitor  progress, success, or failure of a workflow, and 
 send
 appropriate alerts  to an administrator. The application developer is relieved
 from  implementing these generic procedures.

 Furthermore,  some applications or workflows need to run in periodic intervals
 or  when dependent data is available. For example, a workflow could be  
 executed
 every day as soon as output data from the previous 24 instances  of another,
 hourly workflow is available. The workflow coordinator  provides such 
 scheduling
 features, along with prioritization, load  balancing and throttling to 
 optimize
 utilization of resources in the  cluster. This makes it easier to maintain,
 control, and coordinate  complex data applications.

 Nearly  three years ago, a team of Yahoo! developers addressed these critical
 requirements for Hadoop-based data processing systems by developing a  new
 workflow management and scheduling system called Oozie. While it was  
 initially
 developed as a Yahoo!-internal project, it was designed and  implemented with
 the intention of open-sourcing. Oozie was released as a GitHub project in 
 early
 2010. Oozie is used in production within Yahoo and  since it has been
 open-sourced it has been gaining adoption with  external developers

 Rationale
 Commonly,  applications that run on Hadoop require multiple Hadoop jobs in 
 order
 to  obtain the desired results. Furthermore, these Hadoop jobs are commonly  a
 combination of Java map-reduce jobs, Streaming map-reduce jobs, Pipes
 map-reduce jobs, Pig jobs, Hive jobs, HDFS operations, Java programs  and 
 shell
 scripts.

 Because  of this, developers find themselves writing ad-hoc glue programs to
 combine these Hadoop jobs. These ad-hoc programs are difficult to  schedule,
 manage, monitor and