Ah no, I was not suggesting about Curator to become subproject of ZK. I
just afraid that if Curator is going as incubator it will end up as sub of
ZK as merging process.

Like Greg has mentioned in another reply, I would prefer Curator to be
merged as a higher level ZK client. Surely project like HBase and others
that relying on ZK would appreciate simpler client to ZK.

Thanks,

Henry


On Mon, Feb 25, 2013 at 11:23 PM, Patrick Hunt <ph...@apache.org> wrote:

> On Mon, Feb 25, 2013 at 11:01 PM, Henry Saputra <henry.sapu...@gmail.com>
> wrote:
> > So isnt this similar to HCatalog which relying on Hive metadata service
> > that ends up as sub project of Apache Hive?
> >
>
> I was against having Curator as a sub when it came up on the original
> discussion thread, I still am.
>
> Patrick
>
> >
> >
> > On Mon, Feb 25, 2013 at 7:10 PM, Greg Stein <gst...@gmail.com> wrote:
> >
> >> My concern is that we're looking at two "new" committers, rather than
> >> a Curator community. Following normal Incubator work, Curator would
> >> build a community for itself. But then we'd have a community
> >> *distinct* from that of Zookeeper. And it really looks like this
> >> should be part of Zookeeper itself -- a more capable and easier-to-use
> >> client.
> >>
> >> So I question the incubation of this. Why do we want to build a
> >> new/separate project? Why isn't this just part of Zookeeper right from
> >> the start?
> >>
> >> I would suggest that this work is placed on a branch within Zookeeper.
> >> That Jordan and Jay become committers on that branch (not necessarily
> >> Zookeeper trunk). Over time, the branch can be folded into trunk,
> >> along with all the various tests, doc, and other artifacts that I see
> >> in the GitHub repository. And hopefully that Jordan and Jay become
> >> regular committers (and PMC members!) of the Zookeeper project itself.
> >>
> >> The current Zookeeper client can remain for backwards compat, and the
> >> Curator work can become the next-gen client.
> >>
> >> Honestly, in my opnion, incubating this project seems like it would
> >> create a distinct community, and really doesn't seem like it would
> >> serve the Zookeeper community.
> >>
> >> All that said, I am not familiar with the Zookeeper or Curator
> >> communities. But from this read, I don't think Incubation is the right
> >> approach. I would rather push for a more direct incorporation of
> >> Curator directly into Zookeeper. (use the short-form IP clearance) ...
> >> so, unless somebody can help me understand the communities and
> >> situation better, I'm -1 (binding) on this incubation. I'd rather see
> >> combined, rather than distinct, communities from the start.
> >>
> >> Thanks,
> >> -g
> >>
> >> On Mon, Feb 25, 2013 at 8:14 PM, Jordan Zimmerman
> >> <jor...@jordanzimmerman.com> wrote:
> >> > Hello,
> >> >
> >> > I would like to propose that Curator to be an Apache Incubator
> project.
> >> >
> >> > The proposal can be found here:
> >> http://wiki.apache.org/incubator/CuratorProposal
> >> >
> >> > I have included the contents of the proposal below.
> >> >
> >> > Sincerely,
> >> >
> >> > Jordan Zimmerman
> >> >
> >> > ===================
> >> >
> >> > = Curator - ZooKeeper client wrapper and rich ZooKeeper framework =
> >> >
> >> > == Abstract ==
> >> >
> >> > Curator is a set of Java libraries that make using Apache ZooKeeper
> much
> >> easier. While ZooKeeper comes bundled with a Java client, using the
> client
> >> is non-trivial and error prone.
> >> >
> >> > == Proposal ==
> >> >
> >> > Curator is a set of Java libraries that make using Apache ZooKeeper
> much
> >> easier. While ZooKeeper comes bundled with a Java client, using the
> client
> >> is non-trivial and error prone. It consists of three components that
> build
> >> on each other. Curator Client is a replacement for the bundled ZooKeeper
> >> class that takes care of some low-level housekeeping and provides some
> >> useful utilities. Curator Framework is a high-level API that greatly
> >> simplifies using ZooKeeper. It adds many features that build on
> ZooKeeper
> >> and handles the complexity of managing connections to the ZooKeeper
> cluster
> >> and retrying operations. Curator Recipes consists of implementations of
> >> some of the common ZooKeeper “recipes”. Additionally, Curator Test is
> >> included which includes utilities to help with unit testing
> ZooKeeper-based
> >> applications.
> >> >
> >> > == Background ==
> >> >
> >> > Curator was initially developed by Netflix to make writing
> >> ZooKeeper-based applications easier and more reliable. Curator was
> >> open-sourced by Netflix on !GitHub as an Apache 2.0 licensed project in
> >> July 2011. During this time Curator has been formally released many
> times
> >> and has gained widespread adoption.
> >> >
> >> > == Rationale ==
> >> >
> >> > New users of ZooKeeper are surprised to learn that a significant
> amount
> >> of connection management must be done manually. For example, when the
> >> ZooKeeper client connects to the ensemble it must negotiate a new
> session,
> >> etc. This takes some time. If you use a ZooKeeper client API before the
> >> connection process has completed, ZooKeeper will throw an exception.
> These
> >> types of exceptions are referred to as “recoverable” errors.
> >> > Curator automatically handles connection management, greatly
> simplifying
> >> client code. Instead of directly using the ZooKeeper APIs you use
> Curator
> >> APIs that internally check for connection completion and wrap each
> >> ZooKeeper API in a retry loop. Curator uses a retry mechanism to handle
> >> recoverable errors and automatically retry operations. The method of
> retry
> >> is customizable. Curator comes bundled with several implementations
> >> (ExponentialBackoffRetry, etc.) or custom implementations can be
> written.
> >> >
> >> > The ZooKeeper documentation describes many possible uses for ZooKeeper
> >> calling each a “recipe”. While the distribution comes bundled with a few
> >> implementations of these recipes, most ZooKeeper users will need to
> >> manually implement one or more of the recipes. Implementing a ZooKeeper
> >> recipe is not trivial. Besides the connection handling issues, there are
> >> numerous edge cases that are not well documented that must be
> considered.
> >> For example, many recipes require that an ephemeral-sequential node be
> >> created. New users of ZooKeeper will not know that there is an edge
> case in
> >> ephemeral-sequential node creation that requires you to put a special
> >> “marker” in the node’s name so that you can search for the created node
> if
> >> an I/O failure occurs. This is but one of many edge cases that are not
> well
> >> documented but are handled by Curator.
> >> >
> >> > = Current Status =
> >> >
> >> > == Meritocracy ==
> >> >
> >> > Curator was initially developed by Jordan Zimmerman in 2011 at
> Netflix.
> >> Developers external to Netflix provided feedback, suggested features and
> >> fixes and implemented extensions of Curator. Netflix's engineering team
> has
> >> since maintained the project and has been dedicated towards its
> >> improvement. Contributors to Curator include developers from multiple
> >> organizations around the world. Curator will be a meritocracy as it
> enters
> >> the Incubator and beyond.
> >> >
> >> > == Community ==
> >> >
> >> > Curator is currently used by a number of organizations all over the
> >> world. Curator has an active and growing user and developer community
> with
> >> active participation in the [[
> http://groups.google.com/group/curator-users]]
> >> mailing list and at its !Github home: [[
> >> https://github.com/Netflix/curator]].
> >> >
> >> > Since open sourcing the project, there have been fifteen individuals
> >> from various organizations who have contributed code.
> >> >
> >> > == Core Developers ==
> >> >
> >> > The core developers for Curator are:
> >> >  * Jordan Zimmerman
> >> >  * Jay Zarfoss
> >> >
> >> > Jordan has contributed towards Apache ZooKeeper and both Jordan and
> Jay
> >> are familiar with Apache principles and philosophy for community driven
> >> software development.
> >> >
> >> > == Alignment ==
> >> >
> >> > Curator is a natural complement for Apache ZooKeeper. Java users of
> >> ZooKeeper will naturally want to use Curator. When Curator graduates
> from
> >> Incubator it may be useful to distribute Curator artifacts as part of
> >> ZooKeeper releases as the preferred/recommended client side library.
> >> Further, at graduation a determination can be made as to whether Curator
> >> should become a Top Level Project or be merged into ZooKeeper itself.
> >> >
> >> > = Known Risks =
> >> >
> >> > == Orphaned Products ==
> >> >
> >> > Curator is already deployed in production at multiple companies and
> they
> >> are actively participating in creating new features. Curator is getting
> >> traction with developers and thus the risks of it being orphaned are
> >> minimal.
> >> >
> >> > == Inexperience with Open Source ==
> >> >
> >> > All code developed for Curator has been open sourced by Netflix under
> >> Apache 2.0 license.  All committers to Curator are intimately familiar
> with
> >> the Apache model for open-source development and are experienced with
> >> working with new contributors.
> >> >
> >> > == Homogeneous Developers ==
> >> >
> >> > The initial committers are from a single organization. However, we
> >> expect that once approved for incubation, the project will attract new
> >> contributors from diverse organizations and will thus grow organically.
> The
> >> submission of patches from developers from several different
> organizations
> >> is a strong indication that Curator will be widely adopted.
> >> >
> >> > == Reliance on Salaried Developers ==
> >> >
> >> > It is expected that Curator will be developed on salaried and
> volunteer
> >> time, although all of the initial developers will work on it mainly on
> >> salaried time.
> >> >
> >> > == Relationships with Other Apache Products ==
> >> >
> >> > Curator depends upon other Apache Projects: Apache ZooKeeper, Apache
> >> Log4J, and multiple Apache Commons components. Its build depends upon
> >> Apache Maven. Notably, there is interest from other Apache Projects
> such as
> >> HBase in adopting Curator as the client library for ZooKeeper. Apache
> James
> >> Mailbox has already incorporated Curator.
> >> >
> >> > == An Excessive Fascination with the Apache Brand ==
> >> >
> >> > We would like Curator to become an Apache project to further foster a
> >> healthy community of contributors and consumers around the project.
>  Since
> >> Curator directly interacts with Apache ZooKeeper and solves an important
> >> problem of many ZooKeeper users, residing in the Apache Software
> Foundation
> >> will increase interaction with the larger community.
> >> >
> >> > = Documentation =
> >> >
> >> >  * Curator wiki at GitHub: https://github.com/Netflix/curator/wiki
> >> >  * Curator issues at GitHub:
> https://github.com/Netflix/curator/issues
> >> >  * Curator javadoc at GitHub: http://netflix.github.com/curator/doc/
> >> >
> >> > = Initial Source =
> >> >
> >> >  * git://github.com/Netflix/curator.git
> >> >
> >> > == Source and Intellectual Property Submission Plan ==
> >> >
> >> >  * The initial source is already licensed under the Apache License,
> >> Version 2.0. https://github.com/Netflix/curator/blob/master/LICENSE.txt
> >> >
> >> > == External Dependencies ==
> >> >
> >> > The required external dependencies are all Apache License or
> compatible
> >> licenses. Following components with non-Apache licenses are enumerated:
> >> >
> >> >  * org.slf4j: MIT-like License
> >> >  * org.mockito: MIT-like License
> >> >
> >> > == Cryptography ==
> >> >
> >> > Curator contains no known cryptography.
> >> >
> >> > = Required Resources =
> >> >
> >> > == Mailing lists ==
> >> >
> >> >  * curator-private (with moderated subscriptions)
> >> >  * curator-dev
> >> >  * curator-commits
> >> >  * curator-user
> >> >
> >> > == Github Repositories ==
> >> >
> >> > http://github.com/apache/curator git://git.apache.org/curator.git
> >> >
> >> > == Issue Tracking ==
> >> >
> >> > JIRA Curator (CURATOR)
> >> >
> >> > == Other Resources ==
> >> >
> >> > The existing code already has unit and integration tests so we would
> >> like a Jenkins instance to run them whenever a new patch is submitted.
> This
> >> can be added after project creation.
> >> >
> >> > = Initial Committers =
> >> >
> >> >  * Jordan Zimmerman (jzimmerman at netflix dot com)
> >> >  * Jay Zarfoss (jzarfoss at netflix dot com)
> >> >
> >> > = Affiliations =
> >> >
> >> >  * Jordan Zimmerman, Netflix
> >> >  * Jay Zarfoss, Netflix
> >> >
> >> > = Sponsors =
> >> >
> >> > == Champion ==
> >> >
> >> >  * Patrick Hunt
> >> >
> >> > == Nominated Mentors ==
> >> >
> >> >  * Patrick Hunt
> >> >  * Enis Söztutar
> >> >  * Mahadev Konar
> >> >
> >> > == Sponsoring Entity ==
> >> >
> >> >  * Apache Incubator PMC
> >>
> >> ---------------------------------------------------------------------
> >> 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
>
>

Reply via email to