While we're not interested in submitting Curator to the Incubator, I've
prepared a proposal for including Curator as a ZooKeeper sub-project or
inclusion in the main project. Here's the proposal (for commenting, etc.):
Curator, a ZooKeeper Recipe Proposal
===================================
== Abstract =Users of Apache ZooKeeper would greatly benefit from having a high quality
implementation of common recipes included with the ZooKeeper distribution.
Curator is that implementation.

== Proposal =Apache ZooKeeper should produce a new artifact for recipes/applications.
This artifact should either be a ZooKeeper sub-project or top-level part
of ZooKeeper itself. For Java (and possibly other JVM based languages),
the Netflix Curator project should be the artifact.

The recipe implementations currently included with the ZooKeeper
distribution should be deprecated in favor of Curator.

== Background =ZooKeeper consists of server software and client software. The client
implementations that are part of the ZooKeeper distribution are very low
level and difficult to use correctly. Further, implementing the recipes
listed in the ZooKeeper documentation is non-trivial and involves deep
knowledge of ZooKeeper best practices and edge cases.

== Rationale =The existing clients for ZooKeeper are difficult to use and are limited.
Further, correct usage of ZooKeeper is non-trivial and non-obvious. Users
of ZooKeeper are mostly interested in the recipes/applications and are not
likely interested in becoming experts in the minutiae of correct ZooKeeper
client usage. What they want is a simple way to use the recipes. Curator
is directed at this goal.

== Current Status =Curator is an active open source project hosted at Github
(https://github.com/netflix/curator). It has no dependencies other than
industry standard libraries. It provides implementations for all recipes
listed on the ZooKeeper recipes doc as well as a high level framework for
using ZooKeeper that simplifies most of the low level housekeeping
normally required.

Curator has been open since October, 2011 and has been reviewed by several
active members of the ZooKeeper community.

Netflix is a strong proponent of open source and is supportive of
providing the community with this project.

== Core Developers =The initial set of committers are all employees of Netflix, Inc. The lead
developer is Jordan Zimmerman ([EMAIL PROTECTED]), Senior Platform
Engineer at Netflix, Inc.

== Alignment =The current ZooKeeper distribution has an obvious hole in regard to
recipes/applications. Curator's minimal dependencies and use of standard
ZooKeeper components and recipe algorithms make it a natural compliment to
the ZooKeeper distribution.

== Known Risks =Orphan-ing of Curator:
ZooKeeper has become a major component at Netflix. Curator is the
abstraction being used.

Open Source Experience:
Netflix has major experience with open source. All the committers of
Curator have long experience with open source.

Homogenous/Salaried Developers:
The current committers are all salaried employees of Netflix. This
proposal would help by having a more diverse set of committers.

Ties to Apache products:
The initial codebase relies heavily on existing Apache technologies and
will continue to do so.

== Documentation =Comprehensive documentation is at https://github.com/Netflix/curator/wiki

== Initial Source =The source code currently is hosted at Github at:
https://github.com/Netflix/curator

== External Dependencies =Runtime:
* Apache ZooKeeper
* Google Guava

Testing:
* Test NG
* Apache Commons Math
* Mockito
* Javaassist

Building:
* Apache Maven

== Initial Committers =Jordan Zimmerman (Netflix, Inc.)
Jay Zarfoss (Netflix, Inc.)
Jerome Boulon (Netflix, Inc.)

Hi Jordan, Here is some feedback. I like the proposal and it makes  
sense to have such a project as either sub-project or incubator. I  
have a few concerns, though:

1- I haven't been following closely the development of the recipes,  
but I wonder if it really makes sense to deprecate the current ones in  
favor of Curator's, or if it is a better idea to keep multiple  
versions in the case of duplicates. People in the community have spent  
time on the current recipes, so I don't like very much the idea of  
dropping the current recipes without some evidence that the community  
accepts it. Note that I'm not saying that deprecating is not the right  
thing to do, I'm simply saying that we need to make sure that the  
community agrees.

2- The set of committers needs to be more diverse. Perhaps it would be  
easier to find more committers if you follow the incubation process,  
given that typically people sign up for committership once you post a  
proposal there. I wonder how many other people on this list would like  
to volunteer to become a committer of Curator, though. I like the  
project, but unfortunately I don't have the cycles to do it.

3- If Curator becomes a sub-project of ZooKeeper, then you need at  
least one mentor. Is there anyone who would like to sign up to mentor  
Curator?

-Flavio

On Dec 13, 2011, at 5:46 PM, Jordan Zimmerman wrote:

> While we're not interested in submitting Curator to the Incubator,  
> I've
> prepared a proposal for including Curator as a ZooKeeper sub-project  
> or
> inclusion in the main project. Here's the proposal (for commenting,  
> etc.):
>
>
> Curator, a ZooKeeper Recipe Proposal
> ===================================>
> == Abstract => Users of Apache ZooKeeper would greatly benefit from having a high  
> quality
> implementation of common recipes included with the ZooKeeper  
> distribution.
> Curator is that implementation.
>
> == Proposal => Apache ZooKeeper should produce a new artifact for recipes/
> applications.
> This artifact should either be a ZooKeeper sub-project or top-level  
> part
> of ZooKeeper itself. For Java (and possibly other JVM based  
> languages),
> the Netflix Curator project should be the artifact.
>
> The recipe implementations currently included with the ZooKeeper
> distribution should be deprecated in favor of Curator.
>
> == Background => ZooKeeper consists of server software and client software. The client
> implementations that are part of the ZooKeeper distribution are very  
> low
> level and difficult to use correctly. Further, implementing the  
> recipes
> listed in the ZooKeeper documentation is non-trivial and involves deep
> knowledge of ZooKeeper best practices and edge cases.
>
> == Rationale => The existing clients for ZooKeeper are difficult to use and are  
> limited.
> Further, correct usage of ZooKeeper is non-trivial and non-obvious.  
> Users
> of ZooKeeper are mostly interested in the recipes/applications and  
> are not
> likely interested in becoming experts in the minutiae of correct  
> ZooKeeper
> client usage. What they want is a simple way to use the recipes.  
> Curator
> is directed at this goal.
>
> == Current Status => Curator is an active open source project hosted at Github
> (https://github.com/netflix/curator). It has no dependencies other  
> than
> industry standard libraries. It provides implementations for all  
> recipes
> listed on the ZooKeeper recipes doc as well as a high level  
> framework for
> using ZooKeeper that simplifies most of the low level housekeeping
> normally required.
>
> Curator has been open since October, 2011 and has been reviewed by  
> several
> active members of the ZooKeeper community.
>
> Netflix is a strong proponent of open source and is supportive of
> providing the community with this project.
>
> == Core Developers => The initial set of committers are all employees of Netflix, Inc. The  
> lead
> developer is Jordan Zimmerman ([EMAIL PROTECTED]), Senior  
> Platform

It would be good to have more diversity here. I would love to  
contribute, but I don't feel I have cycles for now.

-Flavio

flavio
junqueira

research scientist

[EMAIL PROTECTED]
direct +34 93-183-8828

avinguda diagonal 177, 8th floor, barcelona, 08018, es
phone (408) 349 3300    fax (408) 349 3301

On Wed, Dec 14, 2011 at 7:35 PM, Flavio Junqueira <[EMAIL PROTECTED]> wrote:

> Hi Jordan, Here is some feedback. I like the proposal and it makes sense
> to have such a project as either sub-project or incubator. I have a few
> concerns, though:
>
> 1- I haven't been following closely the development of the recipes, but I
> wonder if it really makes sense to deprecate the current ones in favor of
> Curator's, or if it is a better idea to keep multiple versions in the case
> of duplicates. People in the community have spent time on the current
> recipes, so I don't like very much the idea of dropping the current recipes
> without some evidence that the community accepts it. Note that I'm not
> saying that deprecating is not the right thing to do, I'm simply saying
> that we need to make sure that the community agrees.
>

I agree that not deprecating is a good thing.  We could mark them with
annotations that indicate that we haven't heard yet from a community of
users.  If we don't hear about significant usage, then deprecation might be
warranted.

2- The set of committers needs to be more diverse. Perhaps it would be
> easier to find more committers if you follow the incubation process, given
> that typically people sign up for committership once you post a proposal
> there. I wonder how many other people on this list would like to volunteer
> to become a committer of Curator, though. I like the project, but
> unfortunately I don't have the cycles to do it.
>

I would volunteer.
> 3- If Curator becomes a sub-project of ZooKeeper, then you need at least
> one mentor. Is there anyone who would like to sign up to mentor Curator?
>

Likewise.

I'd be happy to have Ted as both committer and mentor. I'd be happy to
have Patrick and/or as mentor as well.

-JZ

On 12/14/11 7:03 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:

>On Wed, Dec 14, 2011 at 7:35 PM, Flavio Junqueira <[EMAIL PROTECTED]>
>wrote:
>
>> Hi Jordan, Here is some feedback. I like the proposal and it makes sense
>> to have such a project as either sub-project or incubator. I have a few
>> concerns, though:
>>
>> 1- I haven't been following closely the development of the recipes, but
>>I
>> wonder if it really makes sense to deprecate the current ones in favor
>>of
>> Curator's, or if it is a better idea to keep multiple versions in the
>>case
>> of duplicates. People in the community have spent time on the current
>> recipes, so I don't like very much the idea of dropping the current
>>recipes
>> without some evidence that the community accepts it. Note that I'm not
>> saying that deprecating is not the right thing to do, I'm simply saying
>> that we need to make sure that the community agrees.
>>
>
>I agree that not deprecating is a good thing.  We could mark them with
>annotations that indicate that we haven't heard yet from a community of
>users.  If we don't hear about significant usage, then deprecation might
>be
>warranted.
>
>2- The set of committers needs to be more diverse. Perhaps it would be
>> easier to find more committers if you follow the incubation process,
>>given
>> that typically people sign up for committership once you post a proposal
>> there. I wonder how many other people on this list would like to
>>volunteer
>> to become a committer of Curator, though. I like the project, but
>> unfortunately I don't have the cycles to do it.
>>
>
>I would volunteer.
>
>
>> 3- If Curator becomes a sub-project of ZooKeeper, then you need at least
>> one mentor. Is there anyone who would like to sign up to mentor Curator?
>>
>
>Likewise.

Any other comments on this? If not, what should the next steps be?

-JZ

On 12/15/11 10:07 AM, "Jordan Zimmerman" <[EMAIL PROTECTED]> wrote:

>I'd be happy to have Ted as both committer and mentor. I'd be happy to
>have Patrick and/or as mentor as well.
>
>-JZ
>
>On 12/14/11 7:03 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>
>>On Wed, Dec 14, 2011 at 7:35 PM, Flavio Junqueira <[EMAIL PROTECTED]>
>>wrote:
>>
>>> Hi Jordan, Here is some feedback. I like the proposal and it makes
>>>sense
>>> to have such a project as either sub-project or incubator. I have a few
>>> concerns, though:
>>>
>>> 1- I haven't been following closely the development of the recipes, but
>>>I
>>> wonder if it really makes sense to deprecate the current ones in favor
>>>of
>>> Curator's, or if it is a better idea to keep multiple versions in the
>>>case
>>> of duplicates. People in the community have spent time on the current
>>> recipes, so I don't like very much the idea of dropping the current
>>>recipes
>>> without some evidence that the community accepts it. Note that I'm not
>>> saying that deprecating is not the right thing to do, I'm simply saying
>>> that we need to make sure that the community agrees.
>>>
>>
>>I agree that not deprecating is a good thing.  We could mark them with
>>annotations that indicate that we haven't heard yet from a community of
>>users.  If we don't hear about significant usage, then deprecation might
>>be
>>warranted.
>>
>>2- The set of committers needs to be more diverse. Perhaps it would be
>>> easier to find more committers if you follow the incubation process,
>>>given
>>> that typically people sign up for committership once you post a
>>>proposal
>>> there. I wonder how many other people on this list would like to
>>>volunteer
>>> to become a committer of Curator, though. I like the project, but
>>> unfortunately I don't have the cycles to do it.
>>>
>>
>>I would volunteer.
>>
>>
>>> 3- If Curator becomes a sub-project of ZooKeeper, then you need at
>>>least
>>> one mentor. Is there anyone who would like to sign up to mentor
>>>Curator?
>>>
>>
>>Likewise.
>
>

I wanted to share this section of my recent report to the board (I've
also gotten permission to share the board's response)

> A discussion is currently under way regarding the possibility of> merging the recently open sourced "Curator" source base from> Netflix. These are client implementations of ZooKeeper "recipes"> (e.g. leadership election, group membership, etc...) which simplify> the act of using ZooKeeper in client side applications.>> The authors of Curator are unwilling to join the incubator, this is> based on their past experience as well as some of the ongoing issues> they are seeing wrt projects entering the incubator. They have> expressed a preference to come in either as a subproject or as a> separate release artifact of the TLP.

to which the board responded:

Doug Cutting (chairman):
+               Long-term, do you think that Curator will have an
+               indepdendent community from Zookeeper?  If so, then it
+               ought to enter through the Incubator.  If not then the
+               code might still enter through the incubator for
+               resolution of IP issues, but then transfer relatively
+               quickly to live under the Zookeeper PMC.  Or the
+               Zookeeper PMC could directly adopt the code, although
+               you might not immediately add its committers to the
+               project but rather have them first contribute patches
+               through the normal process until their community merit
+               is established.

Sam Ruby:
+ suggested that the "short form" of the incubator's IP clearance
process would be appropriate if Zookeeper directly adopts this code.

The short form can be found here:
http://incubator.apache.org/ip-clearance/index.html

I personally still feel that incubator is the best place for starting
this. I have a good track record as a podling mentor and I feel
strongly that we could quickly/successfully incubate this project and
graduate (given there's strong leadership by the Curator committers
themselves).

Patrick

On Tue, Dec 27, 2011 at 11:10 AM, Jordan Zimmerman
<[EMAIL PROTECTED]> wrote:
> Any other comments on this? If not, what should the next steps be?
>
> -JZ
>
> On 12/15/11 10:07 AM, "Jordan Zimmerman" <[EMAIL PROTECTED]> wrote:
>
>>I'd be happy to have Ted as both committer and mentor. I'd be happy to
>>have Patrick and/or as mentor as well.
>>
>>-JZ
>>
>>On 12/14/11 7:03 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>>
>>>On Wed, Dec 14, 2011 at 7:35 PM, Flavio Junqueira <[EMAIL PROTECTED]>
>>>wrote:
>>>
>>>> Hi Jordan, Here is some feedback. I like the proposal and it makes
>>>>sense
>>>> to have such a project as either sub-project or incubator. I have a few
>>>> concerns, though:
>>>>
>>>> 1- I haven't been following closely the development of the recipes, but
>>>>I
>>>> wonder if it really makes sense to deprecate the current ones in favor
>>>>of
>>>> Curator's, or if it is a better idea to keep multiple versions in the
>>>>case
>>>> of duplicates. People in the community have spent time on the current
>>>> recipes, so I don't like very much the idea of dropping the current
>>>>recipes
>>>> without some evidence that the community accepts it. Note that I'm not
>>>> saying that deprecating is not the right thing to do, I'm simply saying
>>>> that we need to make sure that the community agrees.
>>>>
>>>
>>>I agree that not deprecating is a good thing.  We could mark them with
>>>annotations that indicate that we haven't heard yet from a community of
>>>users.  If we don't hear about significant usage, then deprecation might
>>>be
>>>warranted.
>>>
>>>2- The set of committers needs to be more diverse. Perhaps it would be
>>>> easier to find more committers if you follow the incubation process,
>>>>given
>>>> that typically people sign up for committership once you post a
>>>>proposal
>>>> there. I wonder how many other people on this list would like to
>>>>volunteer
>>>> to become a committer of Curator, though. I like the project, but

I appreciate the desire to go through Incubator. Maybe our concerns are
out-dated. I'll circulate this around Netflix and get some responses.

WRT committer status, I don't see how it can work without us being
committers to Curator. If we're not committers, we'll need to fork it
internally and I've already gotten a lot of negative feedback on that
(there are a lot of former Yahoo-ers here).

-JZ

On 12/28/11 10:02 AM, "Patrick Hunt" <[EMAIL PROTECTED]> wrote:

>I wanted to share this section of my recent report to the board (I've
>also gotten permission to share the board's response)
>
>> A discussion is currently under way regarding the possibility of>
>>merging the recently open sourced "Curator" source base from> Netflix.
>>These are client implementations of ZooKeeper "recipes"> (e.g.
>>leadership election, group membership, etc...) which simplify> the act
>>of using ZooKeeper in client side applications.>> The authors of Curator
>>are unwilling to join the incubator, this is> based on their past
>>experience as well as some of the ongoing issues> they are seeing wrt
>>projects entering the incubator. They have> expressed a preference to
>>come in either as a subproject or as a> separate release artifact of the
>>TLP.
>
>to which the board responded:
>
>Doug Cutting (chairman):
>+               Long-term, do you think that Curator will have an
>+               indepdendent community from Zookeeper?  If so, then it
>+               ought to enter through the Incubator.  If not then the
>+               code might still enter through the incubator for
>+               resolution of IP issues, but then transfer relatively
>+               quickly to live under the Zookeeper PMC.  Or the
>+               Zookeeper PMC could directly adopt the code, although
>+               you might not immediately add its committers to the
>+               project but rather have them first contribute patches
>+               through the normal process until their community merit
>+               is established.
>
>Sam Ruby:
>+ suggested that the "short form" of the incubator's IP clearance
>process would be appropriate if Zookeeper directly adopts this code.
>
>The short form can be found here:
>http://incubator.apache.org/ip-clearance/index.html
>
>I personally still feel that incubator is the best place for starting
>this. I have a good track record as a podling mentor and I feel
>strongly that we could quickly/successfully incubate this project and
>graduate (given there's strong leadership by the Curator committers
>themselves).
>
>Patrick
>
>On Tue, Dec 27, 2011 at 11:10 AM, Jordan Zimmerman
><[EMAIL PROTECTED]> wrote:
>> Any other comments on this? If not, what should the next steps be?
>>
>> -JZ
>>
>> On 12/15/11 10:07 AM, "Jordan Zimmerman" <[EMAIL PROTECTED]> wrote:
>>
>>>I'd be happy to have Ted as both committer and mentor. I'd be happy to
>>>have Patrick and/or as mentor as well.
>>>
>>>-JZ
>>>
>>>On 12/14/11 7:03 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>>>
>>>>On Wed, Dec 14, 2011 at 7:35 PM, Flavio Junqueira <[EMAIL PROTECTED]>
>>>>wrote:
>>>>
>>>>> Hi Jordan, Here is some feedback. I like the proposal and it makes
>>>>>sense
>>>>> to have such a project as either sub-project or incubator. I have a
>>>>>few
>>>>> concerns, though:
>>>>>
>>>>> 1- I haven't been following closely the development of the recipes,
>>>>>but
>>>>>I
>>>>> wonder if it really makes sense to deprecate the current ones in
>>>>>favor
>>>>>of
>>>>> Curator's, or if it is a better idea to keep multiple versions in the
>>>>>case
>>>>> of duplicates. People in the community have spent time on the current
>>>>> recipes, so I don't like very much the idea of dropping the current
>>>>>recipes
>>>>> without some evidence that the community accepts it. Note that I'm
>>>>>not
>>>>> saying that deprecating is not the right thing to do, I'm simply
>>>>>saying
>>>>> that we need to make sure that the community agrees.
>>>>>
>>>>
>>>>I agree that not deprecating is a good thing.  We could mark them with

On Wed, Dec 28, 2011 at 2:39 PM, Jordan Zimmerman
<[EMAIL PROTECTED]> wrote:
> I appreciate the desire to go through Incubator. Maybe our concerns are
> out-dated. I'll circulate this around Netflix and get some responses.

whirr recently graduated to tlp status, see flume, sqoop, bigtop,
mrunit, s4 for examples of projects that I'm currently mentoring and
are doing quite well (granted I'm not the only mentor. ;-) ). All
short of s4 and flume have had successful releases in the incubator
with minimal muss/fuss. (s4 is quite new and flume is about to put out
a release).

> WRT committer status, I don't see how it can work without us being
> committers to Curator. If we're not committers, we'll need to fork it
> internally and I've already gotten a lot of negative feedback on that
> (there are a lot of former Yahoo-ers here).

What Doug is suggesting is that while you wouldn't be able to commit
yourselves (to start with) one of the existing zk committers would
have to review/commit for you. Granted it's not an optimal situation.
That's why incubator/subproj are better imo.

Patrick

>
> On 12/28/11 10:02 AM, "Patrick Hunt" <[EMAIL PROTECTED]> wrote:
>
>>I wanted to share this section of my recent report to the board (I've
>>also gotten permission to share the board's response)
>>
>>> A discussion is currently under way regarding the possibility of>
>>>merging the recently open sourced "Curator" source base from> Netflix.
>>>These are client implementations of ZooKeeper "recipes"> (e.g.
>>>leadership election, group membership, etc...) which simplify> the act
>>>of using ZooKeeper in client side applications.>> The authors of Curator
>>>are unwilling to join the incubator, this is> based on their past
>>>experience as well as some of the ongoing issues> they are seeing wrt
>>>projects entering the incubator. They have> expressed a preference to
>>>come in either as a subproject or as a> separate release artifact of the
>>>TLP.
>>
>>to which the board responded:
>>
>>Doug Cutting (chairman):
>>+               Long-term, do you think that Curator will have an
>>+               indepdendent community from Zookeeper?  If so, then it
>>+               ought to enter through the Incubator.  If not then the
>>+               code might still enter through the incubator for
>>+               resolution of IP issues, but then transfer relatively
>>+               quickly to live under the Zookeeper PMC.  Or the
>>+               Zookeeper PMC could directly adopt the code, although
>>+               you might not immediately add its committers to the
>>+               project but rather have them first contribute patches
>>+               through the normal process until their community merit
>>+               is established.
>>
>>Sam Ruby:
>>+ suggested that the "short form" of the incubator's IP clearance
>>process would be appropriate if Zookeeper directly adopts this code.
>>
>>The short form can be found here:
>>http://incubator.apache.org/ip-clearance/index.html
>>
>>I personally still feel that incubator is the best place for starting
>>this. I have a good track record as a podling mentor and I feel
>>strongly that we could quickly/successfully incubate this project and
>>graduate (given there's strong leadership by the Curator committers
>>themselves).
>>
>>Patrick
>>
>>On Tue, Dec 27, 2011 at 11:10 AM, Jordan Zimmerman
>><[EMAIL PROTECTED]> wrote:
>>> Any other comments on this? If not, what should the next steps be?
>>>
>>> -JZ
>>>
>>> On 12/15/11 10:07 AM, "Jordan Zimmerman" <[EMAIL PROTECTED]> wrote:
>>>
>>>>I'd be happy to have Ted as both committer and mentor. I'd be happy to
>>>>have Patrick and/or as mentor as well.
>>>>
>>>>-JZ
>>>>
>>>>On 12/14/11 7:03 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>>>>
>>>>>On Wed, Dec 14, 2011 at 7:35 PM, Flavio Junqueira <[EMAIL PROTECTED]>
>>>>>wrote:
>>>>>
>>>>>> Hi Jordan, Here is some feedback. I like the proposal and it makes
>>>>>>sense
>>>>>> to have such a project as either sub-project or incubator. I have a

To amplify on this, it would be much easier to add committers to the
incubator project than to ZK itself.

On Wed, Dec 28, 2011 at 2:52 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:

> > WRT committer status, I don't see how it can work without us being
> > committers to Curator. If we're not committers, we'll need to fork it
> > internally and I've already gotten a lot of negative feedback on that
> > (there are a lot of former Yahoo-ers here).
>
> What Doug is suggesting is that while you wouldn't be able to commit
> yourselves (to start with) one of the existing zk committers would
> have to review/commit for you. Granted it's not an optimal situation.
> That's why incubator/subproj are better imo.

>I wonder if it really makes sense to deprecate the current ones in
>favor of Curator's, or if it is a better idea to keep multiple
>versions in the case of duplicates.
I thought that that would be confusing. My thinking is that most people
are going to get ZooKeeper because they need to do X (locking, leader,
etc.). They won't spend a lot of time learning the internals and will just
search for the recipe they need. If they see two they'd be uncertain.

On 12/14/11 4:35 PM, "Flavio Junqueira" <[EMAIL PROTECTED]> wrote:

>Hi Jordan, Here is some feedback. I like the proposal and it makes
>sense to have such a project as either sub-project or incubator. I
>have a few concerns, though:
>
>1- I haven't been following closely the development of the recipes,
>but I wonder if it really makes sense to deprecate the current ones in
>favor of Curator's, or if it is a better idea to keep multiple
>versions in the case of duplicates. People in the community have spent
>time on the current recipes, so I don't like very much the idea of
>dropping the current recipes without some evidence that the community
>accepts it. Note that I'm not saying that deprecating is not the right
>thing to do, I'm simply saying that we need to make sure that the
>community agrees.
>
>2- The set of committers needs to be more diverse. Perhaps it would be
>easier to find more committers if you follow the incubation process,
>given that typically people sign up for committership once you post a
>proposal there. I wonder how many other people on this list would like
>to volunteer to become a committer of Curator, though. I like the
>project, but unfortunately I don't have the cycles to do it.
>
>3- If Curator becomes a sub-project of ZooKeeper, then you need at
>least one mentor. Is there anyone who would like to sign up to mentor
>Curator?
>
>-Flavio
>
>On Dec 13, 2011, at 5:46 PM, Jordan Zimmerman wrote:
>
>> While we're not interested in submitting Curator to the Incubator,
>> I've
>> prepared a proposal for including Curator as a ZooKeeper sub-project
>> or
>> inclusion in the main project. Here's the proposal (for commenting,
>> etc.):
>>
>>
>> Curator, a ZooKeeper Recipe Proposal
>> ===================================>>
>> == Abstract =>> Users of Apache ZooKeeper would greatly benefit from having a high
>> quality
>> implementation of common recipes included with the ZooKeeper
>> distribution.
>> Curator is that implementation.
>>
>> == Proposal =>> Apache ZooKeeper should produce a new artifact for recipes/
>> applications.
>> This artifact should either be a ZooKeeper sub-project or top-level
>> part
>> of ZooKeeper itself. For Java (and possibly other JVM based
>> languages),
>> the Netflix Curator project should be the artifact.
>>
>> The recipe implementations currently included with the ZooKeeper
>> distribution should be deprecated in favor of Curator.
>>
>> == Background =>> ZooKeeper consists of server software and client software. The client
>> implementations that are part of the ZooKeeper distribution are very
>> low
>> level and difficult to use correctly. Further, implementing the
>> recipes
>> listed in the ZooKeeper documentation is non-trivial and involves deep
>> knowledge of ZooKeeper best practices and edge cases.
>>
>> == Rationale =>> The existing clients for ZooKeeper are difficult to use and are
>> limited.
>> Further, correct usage of ZooKeeper is non-trivial and non-obvious.
>> Users
>> of ZooKeeper are mostly interested in the recipes/applications and
>> are not
>> likely interested in becoming experts in the minutiae of correct
>> ZooKeeper
>> client usage. What they want is a simple way to use the recipes.
>> Curator
>> is directed at this goal.
>>
>> == Current Status =>> Curator is an active open source project hosted at Github
>> (https://github.com/netflix/curator). It has no dependencies other
>> than
>> industry standard libraries. It provides implementations for all
>> recipes
>> listed on the ZooKeeper recipes doc as well as a high level

On Thu, Dec 15, 2011 at 12:58 PM, Jordan Zimmerman
<[EMAIL PROTECTED]>wrote:

> >I wonder if it really makes sense to deprecate the current ones in
> >favor of Curator's, or if it is a better idea to keep multiple
> >versions in the case of duplicates.
>
> I thought that that would be confusing. My thinking is that most people
> are going to get ZooKeeper because they need to do X (locking, leader,
> etc.). They won't spend a lot of time learning the internals and will just
> search for the recipe they need. If they see two they'd be uncertain.
>

This is what Javadoc is for.  If one of the legacy recipes is distinctly
less good than a new one, we should document the distinction and give a
pointer in the javadoc.

As long as the doc for the legacy recipes point ppl to the new
implementations that would be fine. What should be avoided is someone
casually looking at the docs and using the legacy version because he
wasn't aware that there was a newer one.

-JZ

On 12/15/11 12:17 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:

>>I thought that that would be confusing. My thinking is that most people
>> are going to get ZooKeeper because they need to do X (locking, leader,
>> etc.). They won't spend a lot of time learning the internals and will
>>just
>> search for the recipe they need. If they see two they'd be uncertain.
>>
>
>This is what Javadoc is for.  If one of the legacy recipes is distinctly
>less good than a new one, we should document the distinction and give a
>pointer in the javadoc.

That will be our responsibility once (if) this is accepted.

On Thu, Dec 15, 2011 at 1:35 PM, Jordan Zimmerman <[EMAIL PROTECTED]>wrote:

> As long as the doc for the legacy recipes point ppl to the new
> implementations that would be fine. What should be avoided is someone
> casually looking at the docs and using the legacy version because he
> wasn't aware that there was a newer one.
>
> -JZ
>
> On 12/15/11 12:17 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>
> >>I thought that that would be confusing. My thinking is that most people
> >> are going to get ZooKeeper because they need to do X (locking, leader,
> >> etc.). They won't spend a lot of time learning the internals and will
> >>just
> >> search for the recipe they need. If they see two they'd be uncertain.
> >>
> >
> >This is what Javadoc is for.  If one of the legacy recipes is distinctly
> >less good than a new one, we should document the distinction and give a
> >pointer in the javadoc.
>
>

Of course. I'll update the proposal (my copy - I'll resend when there are
more comments).

-JZ

On 12/15/11 1:24 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:

>That will be our responsibility once (if) this is accepted.
>
>On Thu, Dec 15, 2011 at 1:35 PM, Jordan Zimmerman
><[EMAIL PROTECTED]>wrote:
>
>> As long as the doc for the legacy recipes point ppl to the new
>> implementations that would be fine. What should be avoided is someone
>> casually looking at the docs and using the legacy version because he
>> wasn't aware that there was a newer one.
>>
>> -JZ
>>
>> On 12/15/11 12:17 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>>
>> >>I thought that that would be confusing. My thinking is that most
>>people
>> >> are going to get ZooKeeper because they need to do X (locking,
>>leader,
>> >> etc.). They won't spend a lot of time learning the internals and will
>> >>just
>> >> search for the recipe they need. If they see two they'd be uncertain.
>> >>
>> >
>> >This is what Javadoc is for.  If one of the legacy recipes is
>>distinctly
>> >less good than a new one, we should document the distinction and give a
>> >pointer in the javadoc.
>>
>>

This proposal looks good to me in general. I'm in favor of having
improved recipes available for users, Curator seems to fit the bill.
However as I stated previously while I'd be +1 for this to go to the
incubator (with ZK PMC as sponsor), I'm -0 for this as a sub/artifact.
(this is the same as my vote for BK btw)

I have similar comments to Flavio:

* what does it mean to deprecate the old recipes? Carry them fwd as
deprecated in Curator but not drop them?

* lang bindings - would Curator accept all comers (c, python, perl,
etc...). If not it doesn't seem like a great replacement for current
recipes.

* re diversity I think it's fine, that's what incubation is for - to
build diversity.

Patrick

On Tue, Dec 13, 2011 at 8:46 AM, Jordan Zimmerman
<[EMAIL PROTECTED]> wrote:
> While we're not interested in submitting Curator to the Incubator, I've
> prepared a proposal for including Curator as a ZooKeeper sub-project or
> inclusion in the main project. Here's the proposal (for commenting, etc.):
>
>
> Curator, a ZooKeeper Recipe Proposal
> ===================================>
> == Abstract => Users of Apache ZooKeeper would greatly benefit from having a high quality
> implementation of common recipes included with the ZooKeeper distribution.
> Curator is that implementation.
>
> == Proposal => Apache ZooKeeper should produce a new artifact for recipes/applications.
> This artifact should either be a ZooKeeper sub-project or top-level part
> of ZooKeeper itself. For Java (and possibly other JVM based languages),
> the Netflix Curator project should be the artifact.
>
> The recipe implementations currently included with the ZooKeeper
> distribution should be deprecated in favor of Curator.
>
> == Background => ZooKeeper consists of server software and client software. The client
> implementations that are part of the ZooKeeper distribution are very low
> level and difficult to use correctly. Further, implementing the recipes
> listed in the ZooKeeper documentation is non-trivial and involves deep
> knowledge of ZooKeeper best practices and edge cases.
>
> == Rationale => The existing clients for ZooKeeper are difficult to use and are limited.
> Further, correct usage of ZooKeeper is non-trivial and non-obvious. Users
> of ZooKeeper are mostly interested in the recipes/applications and are not
> likely interested in becoming experts in the minutiae of correct ZooKeeper
> client usage. What they want is a simple way to use the recipes. Curator
> is directed at this goal.
>
> == Current Status => Curator is an active open source project hosted at Github
> (https://github.com/netflix/curator). It has no dependencies other than
> industry standard libraries. It provides implementations for all recipes
> listed on the ZooKeeper recipes doc as well as a high level framework for
> using ZooKeeper that simplifies most of the low level housekeeping
> normally required.
>
> Curator has been open since October, 2011 and has been reviewed by several
> active members of the ZooKeeper community.
>
> Netflix is a strong proponent of open source and is supportive of
> providing the community with this project.
>
> == Core Developers => The initial set of committers are all employees of Netflix, Inc. The lead
> developer is Jordan Zimmerman ([EMAIL PROTECTED]), Senior Platform
> Engineer at Netflix, Inc.
>
> == Alignment => The current ZooKeeper distribution has an obvious hole in regard to
> recipes/applications. Curator's minimal dependencies and use of standard
> ZooKeeper components and recipe algorithms make it a natural compliment to
> the ZooKeeper distribution.
>
> == Known Risks => Orphan-ing of Curator:
> ZooKeeper has become a major component at Netflix. Curator is the
> abstraction being used.
>
> Open Source Experience:
> Netflix has major experience with open source. All the committers of
> Curator have long experience with open source.
>
> Homogenous/Salaried Developers:
> The current committers are all salaried employees of Netflix. This

>what does it mean to deprecate the old recipes? Carry them fwd as
>deprecated in Curator but not drop them?
I haven't thought too much about project organization. But, that is a
possibility.
>lang bindings - would Curator accept all comers (c, python, perl,
>etc...). If not it doesn't seem like a great replacement for current
>recipes.
Absolutely. I'd love to see it.

On 12/14/11 4:54 PM, "Patrick Hunt" <[EMAIL PROTECTED]> wrote:

>This proposal looks good to me in general. I'm in favor of having
>improved recipes available for users, Curator seems to fit the bill.
>However as I stated previously while I'd be +1 for this to go to the
>incubator (with ZK PMC as sponsor), I'm -0 for this as a sub/artifact.
>(this is the same as my vote for BK btw)
>
>I have similar comments to Flavio:
>
>* what does it mean to deprecate the old recipes? Carry them fwd as
>deprecated in Curator but not drop them?
>
>* lang bindings - would Curator accept all comers (c, python, perl,
>etc...). If not it doesn't seem like a great replacement for current
>recipes.
>
>* re diversity I think it's fine, that's what incubation is for - to
>build diversity.
>
>Patrick
>
>On Tue, Dec 13, 2011 at 8:46 AM, Jordan Zimmerman
><[EMAIL PROTECTED]> wrote:
>> While we're not interested in submitting Curator to the Incubator, I've
>> prepared a proposal for including Curator as a ZooKeeper sub-project or
>> inclusion in the main project. Here's the proposal (for commenting,
>>etc.):
>>
>>
>> Curator, a ZooKeeper Recipe Proposal
>> ===================================>>
>> == Abstract =>> Users of Apache ZooKeeper would greatly benefit from having a high
>>quality
>> implementation of common recipes included with the ZooKeeper
>>distribution.
>> Curator is that implementation.
>>
>> == Proposal =>> Apache ZooKeeper should produce a new artifact for recipes/applications.
>> This artifact should either be a ZooKeeper sub-project or top-level part
>> of ZooKeeper itself. For Java (and possibly other JVM based languages),
>> the Netflix Curator project should be the artifact.
>>
>> The recipe implementations currently included with the ZooKeeper
>> distribution should be deprecated in favor of Curator.
>>
>> == Background =>> ZooKeeper consists of server software and client software. The client
>> implementations that are part of the ZooKeeper distribution are very low
>> level and difficult to use correctly. Further, implementing the recipes
>> listed in the ZooKeeper documentation is non-trivial and involves deep
>> knowledge of ZooKeeper best practices and edge cases.
>>
>> == Rationale =>> The existing clients for ZooKeeper are difficult to use and are limited.
>> Further, correct usage of ZooKeeper is non-trivial and non-obvious.
>>Users
>> of ZooKeeper are mostly interested in the recipes/applications and are
>>not
>> likely interested in becoming experts in the minutiae of correct
>>ZooKeeper
>> client usage. What they want is a simple way to use the recipes. Curator
>> is directed at this goal.
>>
>> == Current Status =>> Curator is an active open source project hosted at Github
>> (https://github.com/netflix/curator). It has no dependencies other than
>> industry standard libraries. It provides implementations for all recipes
>> listed on the ZooKeeper recipes doc as well as a high level framework
>>for
>> using ZooKeeper that simplifies most of the low level housekeeping
>> normally required.
>>
>> Curator has been open since October, 2011 and has been reviewed by
>>several
>> active members of the ZooKeeper community.
>>
>> Netflix is a strong proponent of open source and is supportive of
>> providing the community with this project.
>>
>> == Core Developers =>> The initial set of committers are all employees of Netflix, Inc. The
>>lead
>> developer is Jordan Zimmerman ([EMAIL PROTECTED]), Senior Platform
>> Engineer at Netflix, Inc.
>>
>> == Alignment =>> The current ZooKeeper distribution has an obvious hole in regard to
>> recipes/applications. Curator's minimal dependencies and use of standard