Hi Jordan,
On 2/26/13 11:48 AM, "Jordan Zimmerman" <jor...@jordanzimmerman.com> wrote: >My viewpoint: I can see benefit to Curator both as a TLP and as part of >ZK. One of my hopes of this process is to get an idea of what the >community wants. Curator has been doing well outside of Apache. But, it's >become clear to me that "limited devs - single company" is a hinderance >to wider adoption and growth of Curator. It's because of this that I >thought the Incubator would be the perfect place for Curator at this >point. From the FAQ: > >* "The Incubator, among other things, is where the due-diligence of >making sure the licence is correct" >* "The Incubator is also the place where projects can familiarize >themselves with how the ASF works under the guidance of Incubator PMC >members" > >Also, my reading of the Incubator docs shows that graduation does not >necessarily mean TLP. I was hoping that, via Incubation, Curator's future >could be explored and defined. If that means a Curator TLP, that's great. >If it means something else, that's great too. Quoting Incubator docs written by one or two or a small handful of people in a committee with 100+ members: http://people.apache.org/committers-by-project.html#incubator-pmc Isn't exactly quoting scripture or anything. :) I've been on the committee for a while and at the ASF since 2005, and thus have seen things that have or haven't made their way into those docs, that I know to be true. It's really volunteer driven. Yes, I know, we'd like it to be doctrine but in an org like this it isn't. That being said, I get what you guys are trying to do and I support Incubation. I don't support Graduation->existing TLP. The Incubator is not a home for projects that end up in an existing TLP in my mind (and in several other people's that have been hanging around here for a while). So, if your goal is to eventually get into ZK, I just don't think the Incubator is the right way. It sounds like you guys are a distinct project anyways, so I would recommend going that way. My 2c. Cheers, Chris > >-Jordan > >On Feb 26, 2013, at 10:30 AM, "Mattmann, Chris A (388J)" ><chris.a.mattm...@jpl.nasa.gov> wrote: > >> Hi Guys, >> >> Sorry I have to ask the question here. If the mentors consist of PMC >> members on ZK >> (at least Pat and Mahadev), what's the problem with creating a branch in >> ZK and just >> having the code be there and getting the Curator proposed committers as >> committers in >> ZK ville, and hopefully PMC members soon thereafter. >> >> I have to agree with Greg here. Seems like Incubation is something that >> might not be >> needed. If the end result of this after N months is that Curator >> "graduates" into another >> set of flipping bylaw updates, and more legislation that makes these >> people unofficial >> PMC members on ZK, then I'm double triple -1 with 50 piles of coal on >>top. >> Yes, I'm >> still remembering the HCatalog/Hive thing here - I still don't get that. >> >> Either: (a) define Curator to be its own separate project/community, >>with >> a goal of TLP; >> or (b) nix Incubation and just make these guys part of ZK, on a branch >> now. >> >> Cheers, >> Chris >> >> On 2/26/13 9:40 AM, "Benson Margulies" <bimargul...@gmail.com> wrote: >> >>> On Tue, Feb 26, 2013 at 12:22 PM, Patrick Hunt <ph...@apache.org> >>>wrote: >>>> On Tue, Feb 26, 2013 at 8:32 AM, Benson Margulies >>>> <bimargul...@gmail.com> wrote: >>>>> If you think that the right destination for curator is as part of ZK, >>>>> then it would be good to see substantive participation of the ZK PMC >>>>> in the incubation. The goal should be to 'graduate' by having the >>>>> curator community be granted karma at ZK and the code folded in. This >>>>> would require, I think, the ZK community to supply at least one >>>>> mentor, and to have a plan in advance for the eventual votes based on >>>>> success in the incubator. >>>> >>>> Hi Benson. What you're suggesting matches my current thinking. >>>> >>>> The three Curator mentors are as follows: Mahadev and I (champion) are >>>> both PMC members on ZK, Enis Söztutar is active on HBase and >>>> interested in using Curator for that project (which already uses ZK >>>> heavily). >>> >>> OK, that's lovely. >>> >>> >>>> >>>> Patrick >>>> >>>>> On Tue, Feb 26, 2013 at 10:53 AM, Henry Saputra >>>>> <henry.sapu...@gmail.com> wrote: >>>>>> 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 >>>>>>> >>>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>>>> For additional commands, e-mail: general-h...@incubator.apache.org >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>>> For additional commands, e-mail: general-h...@incubator.apache.org >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >>> For additional commands, e-mail: general-h...@incubator.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >> For additional commands, e-mail: general-h...@incubator.apache.org >> > > >--------------------------------------------------------------------- >To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org >For additional commands, e-mail: general-h...@incubator.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
