Somehow this got off list, Jordan and I just noticed, summary so far:

---------- Forwarded message ----------
From: Patrick Hunt <[EMAIL PROTECTED]>
Date: Fri, Dec 2, 2011 at 9:56 AM
Subject: Re: Proposal: create a separate ZooKeeper release artifact for recipes
To: Jordan Zimmerman <[EMAIL PROTECTED]>
Did you mean to reply just to me? I think this is a great idea btw,
just need to work out the mechanics of getting it integrated and get
the others on board. Would it help to talk f2f?

On Thu, Dec 1, 2011 at 6:20 PM, Jordan Zimmerman <[EMAIL PROTECTED]> wrote:
> From talking to folks here (and my own feeling), I'd like to have Curator
> get as wide use as possible. Some sort of sanction from the ZooKeeper team
> would do that. I don't see a lot of downside to getting a community around
> it either. Sure, it's nice to be the only guy I need to please, but the
> benefits of a community outweigh that.
>
> I think the beauty of folding it in to ZooKeeper is that the structure is
> already there: Jira, website, etc. I (and probably one other from Netflix)
> could take on the role of managing the Curator portion so that it doesn't
> burden you folks. I'm doing that internally at Netflix anyway. Frankly, it
> sounds like fun (famous last words).
>
> -Jordan
>
> On 12/1/11 5:36 PM, "Patrick Hunt" <[EMAIL PROTECTED]> wrote:
>
>>On Thu, Dec 1, 2011 at 2:05 PM, Jordan Zimmerman <[EMAIL PROTECTED]>
>>wrote:
>>> The feeling here is that it would be nice to push Curator into ZK.
>>> However, we'd still like to contribute to it. If you don't want separate
>>> contributor lists, I could be a ZK contributor but explicitly only work
>>>on
>>> Curator. Of course, we're open to your suggestions on this as well.
>>
>>Don't get me wrong, I don't mind having one list of
>>contributors/committers for ZK/Curator, I'm personally fine with
>>having one. If you notice in my original proposal I lean towards that
>>direction (single set of committers with multiple artifacts)
>>
>>I see a benefit to having something like Curator available to users,
>>open sourcing it on GH accomplishes this. Bringing something to Apache
>>means building a community around it though, not just making the code
>>open source. This is analogous to when ZK itself was on sourceforge,
>>eventually moving to Apache.
>>
>>Here's the issue: building community adds overhead, which you might
>>not be willing to sign up for. I'm not sure we (zk community) can take
>>on this additional cost alone. Hence my question -- I _wouldn't_ want
>>to you leave, that's the point. We'd need some set of core "Curator
>>contributors" who would continue to work on Curator, answer questions,
>>shepherd new contributor/committers/etc... If that doesn't happen the
>>code will get imported, see some use, but never really reach it's full
>>potential.
>>
>>Hope that helps. LMK.
>>
>>Patrick
>>
>>>
>>> On 12/1/11 2:01 PM, "Patrick Hunt" <[EMAIL PROTECTED]> wrote:
>>>
>>>>On Thu, Dec 1, 2011 at 1:26 PM, Jordan Zimmerman
>>>><[EMAIL PROTECTED]>
>>>>wrote:
>>>>> I've spoken about this with the appropriate folks here at Netflix and
>>>>> we're interested in pursuing this. What are the next steps?
>>>>
>>>>Hi Jordan, what are your intentions. Do you want to build a community
>>>>around "Apache Curator" or are you just looking to push the source
>>>>into ZK and move on to other things?
>>>>
>>>>Patrick
>>>>
>>>>
>>>>>
>>>>>
>>>>> On 11/30/11 5:42 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>>Separator committer lists are generally frowned on by Apache (ref
>>>>>>Lucene/Solr and also Mahout).
>>>>>>
>>>>>>They also are essentially unnecessary.  It isn't that big a deal to
>>>>>>have a
>>>>>>single committer list and depend on reversion to enforce community
>>>>>>standards.  Core ZK is review-then-commit and should continue to be.
>>>>>> Add-on modules that are relatively independent of the core can quite
>>>>>>reasonably be commit-then-review or whatever level of care is implied
>>>>

I think it sounds like a great idea and a nice nucleus for a ZK
applications area.

On Fri, Dec 2, 2011 at 11:45 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:

> Somehow this got off list, Jordan and I just noticed, summary so far:
>
> ---------- Forwarded message ----------
> From: Patrick Hunt <[EMAIL PROTECTED]>
> Date: Fri, Dec 2, 2011 at 9:56 AM
> Subject: Re: Proposal: create a separate ZooKeeper release artifact for
> recipes
> To: Jordan Zimmerman <[EMAIL PROTECTED]>
>
>
> Did you mean to reply just to me? I think this is a great idea btw,
> just need to work out the mechanics of getting it integrated and get
> the others on board. Would it help to talk f2f?
>
> On Thu, Dec 1, 2011 at 6:20 PM, Jordan Zimmerman <[EMAIL PROTECTED]>
> wrote:
> > From talking to folks here (and my own feeling), I'd like to have Curator
> > get as wide use as possible. Some sort of sanction from the ZooKeeper
> team
> > would do that. I don't see a lot of downside to getting a community
> around
> > it either. Sure, it's nice to be the only guy I need to please, but the
> > benefits of a community outweigh that.
> >
> > I think the beauty of folding it in to ZooKeeper is that the structure is
> > already there: Jira, website, etc. I (and probably one other from
> Netflix)
> > could take on the role of managing the Curator portion so that it doesn't
> > burden you folks. I'm doing that internally at Netflix anyway. Frankly,
> it
> > sounds like fun (famous last words).
> >
> > -Jordan
> >
> > On 12/1/11 5:36 PM, "Patrick Hunt" <[EMAIL PROTECTED]> wrote:
> >
> >>On Thu, Dec 1, 2011 at 2:05 PM, Jordan Zimmerman <[EMAIL PROTECTED]
> >
> >>wrote:
> >>> The feeling here is that it would be nice to push Curator into ZK.
> >>> However, we'd still like to contribute to it. If you don't want
> separate
> >>> contributor lists, I could be a ZK contributor but explicitly only work
> >>>on
> >>> Curator. Of course, we're open to your suggestions on this as well.
> >>
> >>Don't get me wrong, I don't mind having one list of
> >>contributors/committers for ZK/Curator, I'm personally fine with
> >>having one. If you notice in my original proposal I lean towards that
> >>direction (single set of committers with multiple artifacts)
> >>
> >>I see a benefit to having something like Curator available to users,
> >>open sourcing it on GH accomplishes this. Bringing something to Apache
> >>means building a community around it though, not just making the code
> >>open source. This is analogous to when ZK itself was on sourceforge,
> >>eventually moving to Apache.
> >>
> >>Here's the issue: building community adds overhead, which you might
> >>not be willing to sign up for. I'm not sure we (zk community) can take
> >>on this additional cost alone. Hence my question -- I _wouldn't_ want
> >>to you leave, that's the point. We'd need some set of core "Curator
> >>contributors" who would continue to work on Curator, answer questions,
> >>shepherd new contributor/committers/etc... If that doesn't happen the
> >>code will get imported, see some use, but never really reach it's full
> >>potential.
> >>
> >>Hope that helps. LMK.
> >>
> >>Patrick
> >>
> >>>
> >>> On 12/1/11 2:01 PM, "Patrick Hunt" <[EMAIL PROTECTED]> wrote:
> >>>
> >>>>On Thu, Dec 1, 2011 at 1:26 PM, Jordan Zimmerman
> >>>><[EMAIL PROTECTED]>
> >>>>wrote:
> >>>>> I've spoken about this with the appropriate folks here at Netflix and
> >>>>> we're interested in pursuing this. What are the next steps?
> >>>>
> >>>>Hi Jordan, what are your intentions. Do you want to build a community
> >>>>around "Apache Curator" or are you just looking to push the source
> >>>>into ZK and move on to other things?
> >>>>
> >>>>Patrick
> >>>>
> >>>>
> >>>>>
> >>>>>
> >>>>> On 11/30/11 5:42 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
> >>>>>
> >>>>>>Separator committer lists are generally frowned on by Apache (ref
> >>>>>>Lucene/Solr and also Mahout).
> >>>>>>
> >>>>>>They also are essentially unnecessary.  It isn't that big a deal to

I suppose you're just trying to sense if others think that it would be  
a good idea to have it as a subproject. If so, I'm in favor of putting  
a proposal together, +1.

-Flavio

On Dec 2, 2011, at 8:45 PM, Patrick Hunt wrote:

> Somehow this got off list, Jordan and I just noticed, summary so far:
>
> ---------- Forwarded message ----------
> From: Patrick Hunt <[EMAIL PROTECTED]>
> Date: Fri, Dec 2, 2011 at 9:56 AM
> Subject: Re: Proposal: create a separate ZooKeeper release artifact  
> for recipes
> To: Jordan Zimmerman <[EMAIL PROTECTED]>
>
>
> Did you mean to reply just to me? I think this is a great idea btw,
> just need to work out the mechanics of getting it integrated and get
> the others on board. Would it help to talk f2f?
>
> On Thu, Dec 1, 2011 at 6:20 PM, Jordan Zimmerman <[EMAIL PROTECTED]
> > wrote:
>> From talking to folks here (and my own feeling), I'd like to have  
>> Curator
>> get as wide use as possible. Some sort of sanction from the  
>> ZooKeeper team
>> would do that. I don't see a lot of downside to getting a community  
>> around
>> it either. Sure, it's nice to be the only guy I need to please, but  
>> the
>> benefits of a community outweigh that.
>>
>> I think the beauty of folding it in to ZooKeeper is that the  
>> structure is
>> already there: Jira, website, etc. I (and probably one other from  
>> Netflix)
>> could take on the role of managing the Curator portion so that it  
>> doesn't
>> burden you folks. I'm doing that internally at Netflix anyway.  
>> Frankly, it
>> sounds like fun (famous last words).
>>
>> -Jordan
>>
>> On 12/1/11 5:36 PM, "Patrick Hunt" <[EMAIL PROTECTED]> wrote:
>>
>>> On Thu, Dec 1, 2011 at 2:05 PM, Jordan Zimmerman <[EMAIL PROTECTED]
>>> >
>>> wrote:
>>>> The feeling here is that it would be nice to push Curator into ZK.
>>>> However, we'd still like to contribute to it. If you don't want  
>>>> separate
>>>> contributor lists, I could be a ZK contributor but explicitly  
>>>> only work
>>>> on
>>>> Curator. Of course, we're open to your suggestions on this as well.
>>>
>>> Don't get me wrong, I don't mind having one list of
>>> contributors/committers for ZK/Curator, I'm personally fine with
>>> having one. If you notice in my original proposal I lean towards  
>>> that
>>> direction (single set of committers with multiple artifacts)
>>>
>>> I see a benefit to having something like Curator available to users,
>>> open sourcing it on GH accomplishes this. Bringing something to  
>>> Apache
>>> means building a community around it though, not just making the  
>>> code
>>> open source. This is analogous to when ZK itself was on sourceforge,
>>> eventually moving to Apache.
>>>
>>> Here's the issue: building community adds overhead, which you might
>>> not be willing to sign up for. I'm not sure we (zk community) can  
>>> take
>>> on this additional cost alone. Hence my question -- I _wouldn't_  
>>> want
>>> to you leave, that's the point. We'd need some set of core "Curator
>>> contributors" who would continue to work on Curator, answer  
>>> questions,
>>> shepherd new contributor/committers/etc... If that doesn't happen  
>>> the
>>> code will get imported, see some use, but never really reach it's  
>>> full
>>> potential.
>>>
>>> Hope that helps. LMK.
>>>
>>> Patrick
>>>
>>>>
>>>> On 12/1/11 2:01 PM, "Patrick Hunt" <[EMAIL PROTECTED]> wrote:
>>>>
>>>>> On Thu, Dec 1, 2011 at 1:26 PM, Jordan Zimmerman
>>>>> <[EMAIL PROTECTED]>
>>>>> wrote:
>>>>>> I've spoken about this with the appropriate folks here at  
>>>>>> Netflix and
>>>>>> we're interested in pursuing this. What are the next steps?
>>>>>
>>>>> Hi Jordan, what are your intentions. Do you want to build a  
>>>>> community
>>>>> around "Apache Curator" or are you just looking to push the source
>>>>> into ZK and move on to other things?
>>>>>
>>>>> Patrick
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> On 11/30/11 5:42 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>>>>>>
>>>>>>> Separator committer lists are generally frowned on by Apache  

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

i also agreed that it would be great to build a community around
curator especially if it could pull in other zk recipes. i've felt for
a while that the core developers don't have the bandwidth to really
keep track of recipe development and recipes are a very important
aspect of zk. so, having a self sustaining community of developers
focused on that would be awesome. being able to have a separate
release cycle is also important i think. (i may be reading too much
into the proposal though :)

ben

On Mon, Dec 5, 2011 at 7:14 AM, Flavio Junqueira <[EMAIL PROTECTED]> wrote:
> I suppose you're just trying to sense if others think that it would be a
> good idea to have it as a subproject. If so, I'm in favor of putting a
> proposal together, +1.
>
> -Flavio
>
> On Dec 2, 2011, at 8:45 PM, Patrick Hunt wrote:
>
>> Somehow this got off list, Jordan and I just noticed, summary so far:
>>
>> ---------- Forwarded message ----------
>> From: Patrick Hunt <[EMAIL PROTECTED]>
>> Date: Fri, Dec 2, 2011 at 9:56 AM
>> Subject: Re: Proposal: create a separate ZooKeeper release artifact for
>> recipes
>> To: Jordan Zimmerman <[EMAIL PROTECTED]>
>>
>>
>> Did you mean to reply just to me? I think this is a great idea btw,
>> just need to work out the mechanics of getting it integrated and get
>> the others on board. Would it help to talk f2f?
>>
>> On Thu, Dec 1, 2011 at 6:20 PM, Jordan Zimmerman <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> From talking to folks here (and my own feeling), I'd like to have Curator
>>> get as wide use as possible. Some sort of sanction from the ZooKeeper
>>> team
>>> would do that. I don't see a lot of downside to getting a community
>>> around
>>> it either. Sure, it's nice to be the only guy I need to please, but the
>>> benefits of a community outweigh that.
>>>
>>> I think the beauty of folding it in to ZooKeeper is that the structure is
>>> already there: Jira, website, etc. I (and probably one other from
>>> Netflix)
>>> could take on the role of managing the Curator portion so that it doesn't
>>> burden you folks. I'm doing that internally at Netflix anyway. Frankly,
>>> it
>>> sounds like fun (famous last words).
>>>
>>> -Jordan
>>>
>>> On 12/1/11 5:36 PM, "Patrick Hunt" <[EMAIL PROTECTED]> wrote:
>>>
>>>> On Thu, Dec 1, 2011 at 2:05 PM, Jordan Zimmerman
>>>> <[EMAIL PROTECTED]>
>>>> wrote:
>>>>>
>>>>> The feeling here is that it would be nice to push Curator into ZK.
>>>>> However, we'd still like to contribute to it. If you don't want
>>>>> separate
>>>>> contributor lists, I could be a ZK contributor but explicitly only work
>>>>> on
>>>>> Curator. Of course, we're open to your suggestions on this as well.
>>>>
>>>>
>>>> Don't get me wrong, I don't mind having one list of
>>>> contributors/committers for ZK/Curator, I'm personally fine with
>>>> having one. If you notice in my original proposal I lean towards that
>>>> direction (single set of committers with multiple artifacts)
>>>>
>>>> I see a benefit to having something like Curator available to users,
>>>> open sourcing it on GH accomplishes this. Bringing something to Apache
>>>> means building a community around it though, not just making the code
>>>> open source. This is analogous to when ZK itself was on sourceforge,
>>>> eventually moving to Apache.
>>>>
>>>> Here's the issue: building community adds overhead, which you might
>>>> not be willing to sign up for. I'm not sure we (zk community) can take
>>>> on this additional cost alone. Hence my question -- I _wouldn't_ want
>>>> to you leave, that's the point. We'd need some set of core "Curator
>>>> contributors" who would continue to work on Curator, answer questions,
>>>> shepherd new contributor/committers/etc... If that doesn't happen the
>>>> code will get imported, see some use, but never really reach it's full
>>>> potential.
>>>>
>>>> Hope that helps. LMK.
>>>>
>>>> Patrick
>>>>
>>>>>
>>>>> On 12/1/11 2:01 PM, "Patrick Hunt" <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>> On Thu, Dec 1, 2011 at 1:26 PM, Jordan Zimmerman

Ben,

I think that you are right on target with this.  We need to have a wider
community of developers in order to have the bandwidth to handle recipes
and the recipes really do need separate release cycles.  Independent
releases should be not much of an issue given how compatible ZK versions
tend to be.

On Mon, Dec 5, 2011 at 10:59 AM, Benjamin Reed <[EMAIL PROTECTED]> wrote:

> i also agreed that it would be great to build a community around
> curator especially if it could pull in other zk recipes. i've felt for
> a while that the core developers don't have the bandwidth to really
> keep track of recipe development and recipes are a very important
> aspect of zk. so, having a self sustaining community of developers
> focused on that would be awesome. being able to have a separate
> release cycle is also important i think. (i may be reading too much
> into the proposal though :)
>
> ben
>
> On Mon, Dec 5, 2011 at 7:14 AM, Flavio Junqueira <[EMAIL PROTECTED]>
> wrote:
> > I suppose you're just trying to sense if others think that it would be a
> > good idea to have it as a subproject. If so, I'm in favor of putting a
> > proposal together, +1.
> >
> > -Flavio
> >
> > On Dec 2, 2011, at 8:45 PM, Patrick Hunt wrote:
> >
> >> Somehow this got off list, Jordan and I just noticed, summary so far:
> >>
> >> ---------- Forwarded message ----------
> >> From: Patrick Hunt <[EMAIL PROTECTED]>
> >> Date: Fri, Dec 2, 2011 at 9:56 AM
> >> Subject: Re: Proposal: create a separate ZooKeeper release artifact for
> >> recipes
> >> To: Jordan Zimmerman <[EMAIL PROTECTED]>
> >>
> >>
> >> Did you mean to reply just to me? I think this is a great idea btw,
> >> just need to work out the mechanics of getting it integrated and get
> >> the others on board. Would it help to talk f2f?
> >>
> >> On Thu, Dec 1, 2011 at 6:20 PM, Jordan Zimmerman <
> [EMAIL PROTECTED]>
> >> wrote:
> >>>
> >>> From talking to folks here (and my own feeling), I'd like to have
> Curator
> >>> get as wide use as possible. Some sort of sanction from the ZooKeeper
> >>> team
> >>> would do that. I don't see a lot of downside to getting a community
> >>> around
> >>> it either. Sure, it's nice to be the only guy I need to please, but the
> >>> benefits of a community outweigh that.
> >>>
> >>> I think the beauty of folding it in to ZooKeeper is that the structure
> is
> >>> already there: Jira, website, etc. I (and probably one other from
> >>> Netflix)
> >>> could take on the role of managing the Curator portion so that it
> doesn't
> >>> burden you folks. I'm doing that internally at Netflix anyway. Frankly,
> >>> it
> >>> sounds like fun (famous last words).
> >>>
> >>> -Jordan
> >>>
> >>> On 12/1/11 5:36 PM, "Patrick Hunt" <[EMAIL PROTECTED]> wrote:
> >>>
> >>>> On Thu, Dec 1, 2011 at 2:05 PM, Jordan Zimmerman
> >>>> <[EMAIL PROTECTED]>
> >>>> wrote:
> >>>>>
> >>>>> The feeling here is that it would be nice to push Curator into ZK.
> >>>>> However, we'd still like to contribute to it. If you don't want
> >>>>> separate
> >>>>> contributor lists, I could be a ZK contributor but explicitly only
> work
> >>>>> on
> >>>>> Curator. Of course, we're open to your suggestions on this as well.
> >>>>
> >>>>
> >>>> Don't get me wrong, I don't mind having one list of
> >>>> contributors/committers for ZK/Curator, I'm personally fine with
> >>>> having one. If you notice in my original proposal I lean towards that
> >>>> direction (single set of committers with multiple artifacts)
> >>>>
> >>>> I see a benefit to having something like Curator available to users,
> >>>> open sourcing it on GH accomplishes this. Bringing something to Apache
> >>>> means building a community around it though, not just making the code
> >>>> open source. This is analogous to when ZK itself was on sourceforge,
> >>>> eventually moving to Apache.
> >>>>
> >>>> Here's the issue: building community adds overhead, which you might
> >>>> not be willing to sign up for. I'm not sure we (zk community) can take

Incubator is the Apache recommended way to handle this. We could be
the sponsor, with the intent that once Curator graduates from the
incubator we would accept it
http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Sponsor
anyone could join the curator effort, including existing ZK
committers/contributors.

if curator felt it should be a tlp (at time of graduation) I think
that would be fine too.

I would be happy to Champion/Mentor this effort.

Patrick

On Mon, Dec 5, 2011 at 11:06 AM, Ted Dunning <[EMAIL PROTECTED]> wrote:
> Ben,
>
> I think that you are right on target with this.  We need to have a wider
> community of developers in order to have the bandwidth to handle recipes
> and the recipes really do need separate release cycles.  Independent
> releases should be not much of an issue given how compatible ZK versions
> tend to be.
>
> On Mon, Dec 5, 2011 at 10:59 AM, Benjamin Reed <[EMAIL PROTECTED]> wrote:
>
>> i also agreed that it would be great to build a community around
>> curator especially if it could pull in other zk recipes. i've felt for
>> a while that the core developers don't have the bandwidth to really
>> keep track of recipe development and recipes are a very important
>> aspect of zk. so, having a self sustaining community of developers
>> focused on that would be awesome. being able to have a separate
>> release cycle is also important i think. (i may be reading too much
>> into the proposal though :)
>>
>> ben
>>
>> On Mon, Dec 5, 2011 at 7:14 AM, Flavio Junqueira <[EMAIL PROTECTED]>
>> wrote:
>> > I suppose you're just trying to sense if others think that it would be a
>> > good idea to have it as a subproject. If so, I'm in favor of putting a
>> > proposal together, +1.
>> >
>> > -Flavio
>> >
>> > On Dec 2, 2011, at 8:45 PM, Patrick Hunt wrote:
>> >
>> >> Somehow this got off list, Jordan and I just noticed, summary so far:
>> >>
>> >> ---------- Forwarded message ----------
>> >> From: Patrick Hunt <[EMAIL PROTECTED]>
>> >> Date: Fri, Dec 2, 2011 at 9:56 AM
>> >> Subject: Re: Proposal: create a separate ZooKeeper release artifact for
>> >> recipes
>> >> To: Jordan Zimmerman <[EMAIL PROTECTED]>
>> >>
>> >>
>> >> Did you mean to reply just to me? I think this is a great idea btw,
>> >> just need to work out the mechanics of getting it integrated and get
>> >> the others on board. Would it help to talk f2f?
>> >>
>> >> On Thu, Dec 1, 2011 at 6:20 PM, Jordan Zimmerman <
>> [EMAIL PROTECTED]>
>> >> wrote:
>> >>>
>> >>> From talking to folks here (and my own feeling), I'd like to have
>> Curator
>> >>> get as wide use as possible. Some sort of sanction from the ZooKeeper
>> >>> team
>> >>> would do that. I don't see a lot of downside to getting a community
>> >>> around
>> >>> it either. Sure, it's nice to be the only guy I need to please, but the
>> >>> benefits of a community outweigh that.
>> >>>
>> >>> I think the beauty of folding it in to ZooKeeper is that the structure
>> is
>> >>> already there: Jira, website, etc. I (and probably one other from
>> >>> Netflix)
>> >>> could take on the role of managing the Curator portion so that it
>> doesn't
>> >>> burden you folks. I'm doing that internally at Netflix anyway. Frankly,
>> >>> it
>> >>> sounds like fun (famous last words).
>> >>>
>> >>> -Jordan
>> >>>
>> >>> On 12/1/11 5:36 PM, "Patrick Hunt" <[EMAIL PROTECTED]> wrote:
>> >>>
>> >>>> On Thu, Dec 1, 2011 at 2:05 PM, Jordan Zimmerman
>> >>>> <[EMAIL PROTECTED]>
>> >>>> wrote:
>> >>>>>
>> >>>>> The feeling here is that it would be nice to push Curator into ZK.
>> >>>>> However, we'd still like to contribute to it. If you don't want
>> >>>>> separate
>> >>>>> contributor lists, I could be a ZK contributor but explicitly only
>> work
>> >>>>> on
>> >>>>> Curator. Of course, we're open to your suggestions on this as well.
>> >>>>
>> >>>>
>> >>>> Don't get me wrong, I don't mind having one list of
>> >>>> contributors/committers for ZK/Curator, I'm personally fine with

sounds great. do you think they would broaden their scope to all of
the zk recipes rather than just their own?

ben

On Mon, Dec 5, 2011 at 11:11 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> Incubator is the Apache recommended way to handle this. We could be
> the sponsor, with the intent that once Curator graduates from the
> incubator we would accept it
> http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Sponsor
> anyone could join the curator effort, including existing ZK
> committers/contributors.
>
> if curator felt it should be a tlp (at time of graduation) I think
> that would be fine too.
>
> I would be happy to Champion/Mentor this effort.
>
> Patrick
>
> On Mon, Dec 5, 2011 at 11:06 AM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>> Ben,
>>
>> I think that you are right on target with this.  We need to have a wider
>> community of developers in order to have the bandwidth to handle recipes
>> and the recipes really do need separate release cycles.  Independent
>> releases should be not much of an issue given how compatible ZK versions
>> tend to be.
>>
>> On Mon, Dec 5, 2011 at 10:59 AM, Benjamin Reed <[EMAIL PROTECTED]> wrote:
>>
>>> i also agreed that it would be great to build a community around
>>> curator especially if it could pull in other zk recipes. i've felt for
>>> a while that the core developers don't have the bandwidth to really
>>> keep track of recipe development and recipes are a very important
>>> aspect of zk. so, having a self sustaining community of developers
>>> focused on that would be awesome. being able to have a separate
>>> release cycle is also important i think. (i may be reading too much
>>> into the proposal though :)
>>>
>>> ben
>>>
>>> On Mon, Dec 5, 2011 at 7:14 AM, Flavio Junqueira <[EMAIL PROTECTED]>
>>> wrote:
>>> > I suppose you're just trying to sense if others think that it would be a
>>> > good idea to have it as a subproject. If so, I'm in favor of putting a
>>> > proposal together, +1.
>>> >
>>> > -Flavio
>>> >
>>> > On Dec 2, 2011, at 8:45 PM, Patrick Hunt wrote:
>>> >
>>> >> Somehow this got off list, Jordan and I just noticed, summary so far:
>>> >>
>>> >> ---------- Forwarded message ----------
>>> >> From: Patrick Hunt <[EMAIL PROTECTED]>
>>> >> Date: Fri, Dec 2, 2011 at 9:56 AM
>>> >> Subject: Re: Proposal: create a separate ZooKeeper release artifact for
>>> >> recipes
>>> >> To: Jordan Zimmerman <[EMAIL PROTECTED]>
>>> >>
>>> >>
>>> >> Did you mean to reply just to me? I think this is a great idea btw,
>>> >> just need to work out the mechanics of getting it integrated and get
>>> >> the others on board. Would it help to talk f2f?
>>> >>
>>> >> On Thu, Dec 1, 2011 at 6:20 PM, Jordan Zimmerman <
>>> [EMAIL PROTECTED]>
>>> >> wrote:
>>> >>>
>>> >>> From talking to folks here (and my own feeling), I'd like to have
>>> Curator
>>> >>> get as wide use as possible. Some sort of sanction from the ZooKeeper
>>> >>> team
>>> >>> would do that. I don't see a lot of downside to getting a community
>>> >>> around
>>> >>> it either. Sure, it's nice to be the only guy I need to please, but the
>>> >>> benefits of a community outweigh that.
>>> >>>
>>> >>> I think the beauty of folding it in to ZooKeeper is that the structure
>>> is
>>> >>> already there: Jira, website, etc. I (and probably one other from
>>> >>> Netflix)
>>> >>> could take on the role of managing the Curator portion so that it
>>> doesn't
>>> >>> burden you folks. I'm doing that internally at Netflix anyway. Frankly,
>>> >>> it
>>> >>> sounds like fun (famous last words).
>>> >>>
>>> >>> -Jordan
>>> >>>
>>> >>> On 12/1/11 5:36 PM, "Patrick Hunt" <[EMAIL PROTECTED]> wrote:
>>> >>>
>>> >>>> On Thu, Dec 1, 2011 at 2:05 PM, Jordan Zimmerman
>>> >>>> <[EMAIL PROTECTED]>
>>> >>>> wrote:
>>> >>>>>
>>> >>>>> The feeling here is that it would be nice to push Curator into ZK.
>>> >>>>> However, we'd still like to contribute to it. If you don't want
>>> >>>>> separate
>>> >>>>> contributor lists, I could be a ZK contributor but explicitly only

Good question. I think they should subsume it. Also note that current
curator is java while recipes are c and java. I'd hope that curator
would include development of both and possibly more (python, perl,
etc...)

On Mon, Dec 5, 2011 at 11:14 AM, Benjamin Reed <[EMAIL PROTECTED]> wrote:
> sounds great. do you think they would broaden their scope to all of
> the zk recipes rather than just their own?
>
> ben
>
> On Mon, Dec 5, 2011 at 11:11 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>> Incubator is the Apache recommended way to handle this. We could be
>> the sponsor, with the intent that once Curator graduates from the
>> incubator we would accept it
>> http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Sponsor
>> anyone could join the curator effort, including existing ZK
>> committers/contributors.
>>
>> if curator felt it should be a tlp (at time of graduation) I think
>> that would be fine too.
>>
>> I would be happy to Champion/Mentor this effort.
>>
>> Patrick
>>
>> On Mon, Dec 5, 2011 at 11:06 AM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>>> Ben,
>>>
>>> I think that you are right on target with this.  We need to have a wider
>>> community of developers in order to have the bandwidth to handle recipes
>>> and the recipes really do need separate release cycles.  Independent
>>> releases should be not much of an issue given how compatible ZK versions
>>> tend to be.
>>>
>>> On Mon, Dec 5, 2011 at 10:59 AM, Benjamin Reed <[EMAIL PROTECTED]> wrote:
>>>
>>>> i also agreed that it would be great to build a community around
>>>> curator especially if it could pull in other zk recipes. i've felt for
>>>> a while that the core developers don't have the bandwidth to really
>>>> keep track of recipe development and recipes are a very important
>>>> aspect of zk. so, having a self sustaining community of developers
>>>> focused on that would be awesome. being able to have a separate
>>>> release cycle is also important i think. (i may be reading too much
>>>> into the proposal though :)
>>>>
>>>> ben
>>>>
>>>> On Mon, Dec 5, 2011 at 7:14 AM, Flavio Junqueira <[EMAIL PROTECTED]>
>>>> wrote:
>>>> > I suppose you're just trying to sense if others think that it would be a
>>>> > good idea to have it as a subproject. If so, I'm in favor of putting a
>>>> > proposal together, +1.
>>>> >
>>>> > -Flavio
>>>> >
>>>> > On Dec 2, 2011, at 8:45 PM, Patrick Hunt wrote:
>>>> >
>>>> >> Somehow this got off list, Jordan and I just noticed, summary so far:
>>>> >>
>>>> >> ---------- Forwarded message ----------
>>>> >> From: Patrick Hunt <[EMAIL PROTECTED]>
>>>> >> Date: Fri, Dec 2, 2011 at 9:56 AM
>>>> >> Subject: Re: Proposal: create a separate ZooKeeper release artifact for
>>>> >> recipes
>>>> >> To: Jordan Zimmerman <[EMAIL PROTECTED]>
>>>> >>
>>>> >>
>>>> >> Did you mean to reply just to me? I think this is a great idea btw,
>>>> >> just need to work out the mechanics of getting it integrated and get
>>>> >> the others on board. Would it help to talk f2f?
>>>> >>
>>>> >> On Thu, Dec 1, 2011 at 6:20 PM, Jordan Zimmerman <
>>>> [EMAIL PROTECTED]>
>>>> >> wrote:
>>>> >>>
>>>> >>> From talking to folks here (and my own feeling), I'd like to have
>>>> Curator
>>>> >>> get as wide use as possible. Some sort of sanction from the ZooKeeper
>>>> >>> team
>>>> >>> would do that. I don't see a lot of downside to getting a community
>>>> >>> around
>>>> >>> it either. Sure, it's nice to be the only guy I need to please, but the
>>>> >>> benefits of a community outweigh that.
>>>> >>>
>>>> >>> I think the beauty of folding it in to ZooKeeper is that the structure
>>>> is
>>>> >>> already there: Jira, website, etc. I (and probably one other from
>>>> >>> Netflix)
>>>> >>> could take on the role of managing the Curator portion so that it
>>>> doesn't
>>>> >>> burden you folks. I'm doing that internally at Netflix anyway. Frankly,
>>>> >>> it
>>>> >>> sounds like fun (famous last words).
>>>> >>>
>>>> >>> -Jordan
>>>> >>>
>>>> >>

+1

On Mon, Dec 5, 2011 at 11:11 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> Incubator is the Apache recommended way to handle this. We could be
> the sponsor, with the intent that once Curator graduates from the
> incubator we would accept it
> http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Sponsor
> anyone could join the curator effort, including existing ZK
> committers/contributors.
>
> if curator felt it should be a tlp (at time of graduation) I think
> that would be fine too.
>
> I would be happy to Champion/Mentor this effort.
>
> Patrick
>
> On Mon, Dec 5, 2011 at 11:06 AM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>> Ben,
>>
>> I think that you are right on target with this.  We need to have a wider
>> community of developers in order to have the bandwidth to handle recipes
>> and the recipes really do need separate release cycles.  Independent
>> releases should be not much of an issue given how compatible ZK versions
>> tend to be.
>>
>> On Mon, Dec 5, 2011 at 10:59 AM, Benjamin Reed <[EMAIL PROTECTED]> wrote:
>>
>>> i also agreed that it would be great to build a community around
>>> curator especially if it could pull in other zk recipes. i've felt for
>>> a while that the core developers don't have the bandwidth to really
>>> keep track of recipe development and recipes are a very important
>>> aspect of zk. so, having a self sustaining community of developers
>>> focused on that would be awesome. being able to have a separate
>>> release cycle is also important i think. (i may be reading too much
>>> into the proposal though :)
>>>
>>> ben
>>>
>>> On Mon, Dec 5, 2011 at 7:14 AM, Flavio Junqueira <[EMAIL PROTECTED]>
>>> wrote:
>>> > I suppose you're just trying to sense if others think that it would be a
>>> > good idea to have it as a subproject. If so, I'm in favor of putting a
>>> > proposal together, +1.
>>> >
>>> > -Flavio
>>> >
>>> > On Dec 2, 2011, at 8:45 PM, Patrick Hunt wrote:
>>> >
>>> >> Somehow this got off list, Jordan and I just noticed, summary so far:
>>> >>
>>> >> ---------- Forwarded message ----------
>>> >> From: Patrick Hunt <[EMAIL PROTECTED]>
>>> >> Date: Fri, Dec 2, 2011 at 9:56 AM
>>> >> Subject: Re: Proposal: create a separate ZooKeeper release artifact for
>>> >> recipes
>>> >> To: Jordan Zimmerman <[EMAIL PROTECTED]>
>>> >>
>>> >>
>>> >> Did you mean to reply just to me? I think this is a great idea btw,
>>> >> just need to work out the mechanics of getting it integrated and get
>>> >> the others on board. Would it help to talk f2f?
>>> >>
>>> >> On Thu, Dec 1, 2011 at 6:20 PM, Jordan Zimmerman <
>>> [EMAIL PROTECTED]>
>>> >> wrote:
>>> >>>
>>> >>> From talking to folks here (and my own feeling), I'd like to have
>>> Curator
>>> >>> get as wide use as possible. Some sort of sanction from the ZooKeeper
>>> >>> team
>>> >>> would do that. I don't see a lot of downside to getting a community
>>> >>> around
>>> >>> it either. Sure, it's nice to be the only guy I need to please, but the
>>> >>> benefits of a community outweigh that.
>>> >>>
>>> >>> I think the beauty of folding it in to ZooKeeper is that the structure
>>> is
>>> >>> already there: Jira, website, etc. I (and probably one other from
>>> >>> Netflix)
>>> >>> could take on the role of managing the Curator portion so that it
>>> doesn't
>>> >>> burden you folks. I'm doing that internally at Netflix anyway. Frankly,
>>> >>> it
>>> >>> sounds like fun (famous last words).
>>> >>>
>>> >>> -Jordan
>>> >>>
>>> >>> On 12/1/11 5:36 PM, "Patrick Hunt" <[EMAIL PROTECTED]> wrote:
>>> >>>
>>> >>>> On Thu, Dec 1, 2011 at 2:05 PM, Jordan Zimmerman
>>> >>>> <[EMAIL PROTECTED]>
>>> >>>> wrote:
>>> >>>>>
>>> >>>>> The feeling here is that it would be nice to push Curator into ZK.
>>> >>>>> However, we'd still like to contribute to it. If you don't want
>>> >>>>> separate
>>> >>>>> contributor lists, I could be a ZK contributor but explicitly only
>>> work
>>> >>>>> on
>>> >>>>> Curator. Of course, we're open to your suggestions on this as well.

+1...

mahadev

On Mon, Dec 5, 2011 at 11:42 AM, Benjamin Reed <[EMAIL PROTECTED]> wrote:
> +1
>
> On Mon, Dec 5, 2011 at 11:11 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>> Incubator is the Apache recommended way to handle this. We could be
>> the sponsor, with the intent that once Curator graduates from the
>> incubator we would accept it
>> http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Sponsor
>> anyone could join the curator effort, including existing ZK
>> committers/contributors.
>>
>> if curator felt it should be a tlp (at time of graduation) I think
>> that would be fine too.
>>
>> I would be happy to Champion/Mentor this effort.
>>
>> Patrick
>>
>> On Mon, Dec 5, 2011 at 11:06 AM, Ted Dunning <[EMAIL PROTECTED]> wrote:
>>> Ben,
>>>
>>> I think that you are right on target with this.  We need to have a wider
>>> community of developers in order to have the bandwidth to handle recipes
>>> and the recipes really do need separate release cycles.  Independent
>>> releases should be not much of an issue given how compatible ZK versions
>>> tend to be.
>>>
>>> On Mon, Dec 5, 2011 at 10:59 AM, Benjamin Reed <[EMAIL PROTECTED]> wrote:
>>>
>>>> i also agreed that it would be great to build a community around
>>>> curator especially if it could pull in other zk recipes. i've felt for
>>>> a while that the core developers don't have the bandwidth to really
>>>> keep track of recipe development and recipes are a very important
>>>> aspect of zk. so, having a self sustaining community of developers
>>>> focused on that would be awesome. being able to have a separate
>>>> release cycle is also important i think. (i may be reading too much
>>>> into the proposal though :)
>>>>
>>>> ben
>>>>
>>>> On Mon, Dec 5, 2011 at 7:14 AM, Flavio Junqueira <[EMAIL PROTECTED]>
>>>> wrote:
>>>> > I suppose you're just trying to sense if others think that it would be a
>>>> > good idea to have it as a subproject. If so, I'm in favor of putting a
>>>> > proposal together, +1.
>>>> >
>>>> > -Flavio
>>>> >
>>>> > On Dec 2, 2011, at 8:45 PM, Patrick Hunt wrote:
>>>> >
>>>> >> Somehow this got off list, Jordan and I just noticed, summary so far:
>>>> >>
>>>> >> ---------- Forwarded message ----------
>>>> >> From: Patrick Hunt <[EMAIL PROTECTED]>
>>>> >> Date: Fri, Dec 2, 2011 at 9:56 AM
>>>> >> Subject: Re: Proposal: create a separate ZooKeeper release artifact for
>>>> >> recipes
>>>> >> To: Jordan Zimmerman <[EMAIL PROTECTED]>
>>>> >>
>>>> >>
>>>> >> Did you mean to reply just to me? I think this is a great idea btw,
>>>> >> just need to work out the mechanics of getting it integrated and get
>>>> >> the others on board. Would it help to talk f2f?
>>>> >>
>>>> >> On Thu, Dec 1, 2011 at 6:20 PM, Jordan Zimmerman <
>>>> [EMAIL PROTECTED]>
>>>> >> wrote:
>>>> >>>
>>>> >>> From talking to folks here (and my own feeling), I'd like to have
>>>> Curator
>>>> >>> get as wide use as possible. Some sort of sanction from the ZooKeeper
>>>> >>> team
>>>> >>> would do that. I don't see a lot of downside to getting a community
>>>> >>> around
>>>> >>> it either. Sure, it's nice to be the only guy I need to please, but the
>>>> >>> benefits of a community outweigh that.
>>>> >>>
>>>> >>> I think the beauty of folding it in to ZooKeeper is that the structure
>>>> is
>>>> >>> already there: Jira, website, etc. I (and probably one other from
>>>> >>> Netflix)
>>>> >>> could take on the role of managing the Curator portion so that it
>>>> doesn't
>>>> >>> burden you folks. I'm doing that internally at Netflix anyway. Frankly,
>>>> >>> it
>>>> >>> sounds like fun (famous last words).
>>>> >>>
>>>> >>> -Jordan
>>>> >>>
>>>> >>> On 12/1/11 5:36 PM, "Patrick Hunt" <[EMAIL PROTECTED]> wrote:
>>>> >>>
>>>> >>>> On Thu, Dec 1, 2011 at 2:05 PM, Jordan Zimmerman
>>>> >>>> <[EMAIL PROTECTED]>
>>>> >>>> wrote:
>>>> >>>>>
>>>> >>>>> The feeling here is that it would be nice to push Curator into ZK.
>>>> >>>>> However, we'd still like to contribute to it. If you don't want

-1

I don't think that a full incubator process is needed or even useful here.
 Incubator is ONE process in Apache process for this, but a contrib
artifact is another way to do it.

This isn't a sub-project.  This is additional ZK software.  It just isn't
the core stuff.   This is more akin to Solr being added to Lucene than it
is like Mahout spinning out of Lucene ultimately as a top level project.
On Mon, Dec 5, 2011 at 11:58 AM, Mahadev Konar <[EMAIL PROTECTED]>wrote:

> +1...
>
> mahadev
>
> On Mon, Dec 5, 2011 at 11:42 AM, Benjamin Reed <[EMAIL PROTECTED]> wrote:
> > +1
> >
> > On Mon, Dec 5, 2011 at 11:11 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
> >> Incubator is the Apache recommended way to handle this. We could be
> >> the sponsor, with the intent that once Curator graduates from the
> >> incubator we would accept it
> >>
> http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Sponsor
> >> anyone could join the curator effort, including existing ZK
> >> committers/contributors.
> >>
> >> if curator felt it should be a tlp (at time of graduation) I think
> >> that would be fine too.
> >>
> >> I would be happy to Champion/Mentor this effort.
> >>
> >> Patrick
> >>
> >> On Mon, Dec 5, 2011 at 11:06 AM, Ted Dunning <[EMAIL PROTECTED]>
> wrote:
> >>> Ben,
> >>>
> >>> I think that you are right on target with this.  We need to have a
> wider
> >>> community of developers in order to have the bandwidth to handle
> recipes
> >>> and the recipes really do need separate release cycles.  Independent
> >>> releases should be not much of an issue given how compatible ZK
> versions
> >>> tend to be.
> >>>
> >>> On Mon, Dec 5, 2011 at 10:59 AM, Benjamin Reed <[EMAIL PROTECTED]>
> wrote:
> >>>
> >>>> i also agreed that it would be great to build a community around
> >>>> curator especially if it could pull in other zk recipes. i've felt for
> >>>> a while that the core developers don't have the bandwidth to really
> >>>> keep track of recipe development and recipes are a very important
> >>>> aspect of zk. so, having a self sustaining community of developers
> >>>> focused on that would be awesome. being able to have a separate
> >>>> release cycle is also important i think. (i may be reading too much
> >>>> into the proposal though :)
> >>>>
> >>>> ben
> >>>>
> >>>> On Mon, Dec 5, 2011 at 7:14 AM, Flavio Junqueira <[EMAIL PROTECTED]>
> >>>> wrote:
> >>>> > I suppose you're just trying to sense if others think that it would
> be a
> >>>> > good idea to have it as a subproject. If so, I'm in favor of
> putting a
> >>>> > proposal together, +1.
> >>>> >
> >>>> > -Flavio
> >>>> >
> >>>> > On Dec 2, 2011, at 8:45 PM, Patrick Hunt wrote:
> >>>> >
> >>>> >> Somehow this got off list, Jordan and I just noticed, summary so
> far:
> >>>> >>
> >>>> >> ---------- Forwarded message ----------
> >>>> >> From: Patrick Hunt <[EMAIL PROTECTED]>
> >>>> >> Date: Fri, Dec 2, 2011 at 9:56 AM
> >>>> >> Subject: Re: Proposal: create a separate ZooKeeper release
> artifact for
> >>>> >> recipes
> >>>> >> To: Jordan Zimmerman <[EMAIL PROTECTED]>
> >>>> >>
> >>>> >>
> >>>> >> Did you mean to reply just to me? I think this is a great idea btw,
> >>>> >> just need to work out the mechanics of getting it integrated and
> get
> >>>> >> the others on board. Would it help to talk f2f?
> >>>> >>
> >>>> >> On Thu, Dec 1, 2011 at 6:20 PM, Jordan Zimmerman <
> >>>> [EMAIL PROTECTED]>
> >>>> >> wrote:
> >>>> >>>
> >>>> >>> From talking to folks here (and my own feeling), I'd like to have
> >>>> Curator
> >>>> >>> get as wide use as possible. Some sort of sanction from the
> ZooKeeper
> >>>> >>> team
> >>>> >>> would do that. I don't see a lot of downside to getting a
> community
> >>>> >>> around
> >>>> >>> it either. Sure, it's nice to be the only guy I need to please,
> but the
> >>>> >>> benefits of a community outweigh that.
> >>>> >>>
> >>>> >>> I think the beauty of folding it in to ZooKeeper is that the
> structure
> >>>> is

Ted, can you talk more about this? How do you see this working?

FYI - I had a nice lunch with Patrick today. Personally (and Netflixily)
I'm not very interested in Incubator. The recipes are useless without
ZooKeeper itself so I can't imagine recipes ever becoming a TLP. Patrick
and I talked about going the sub-project route (though he prefers
Incubator). My desires are:

* Get widespread use/visibility for Curator
* Get additional committers to Curator
* Help ZK users by making quality recipe implementations readily available

-JZ

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

>-1
>
>I don't think that a full incubator process is needed or even useful here.
> Incubator is ONE process in Apache process for this, but a contrib
>artifact is another way to do it.
>
>This isn't a sub-project.  This is additional ZK software.  It just isn't
>the core stuff.   This is more akin to Solr being added to Lucene than it
>is like Mahout spinning out of Lucene ultimately as a top level project.
>
>
>On Mon, Dec 5, 2011 at 11:58 AM, Mahadev Konar
><[EMAIL PROTECTED]>wrote:
>
>> +1...
>>
>> mahadev
>>
>> On Mon, Dec 5, 2011 at 11:42 AM, Benjamin Reed <[EMAIL PROTECTED]> wrote:
>> > +1
>> >
>> > On Mon, Dec 5, 2011 at 11:11 AM, Patrick Hunt <[EMAIL PROTECTED]>
>>wrote:
>> >> Incubator is the Apache recommended way to handle this. We could be
>> >> the sponsor, with the intent that once Curator graduates from the
>> >> incubator we would accept it
>> >>
>>
>>http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Sp
>>onsor
>> >> anyone could join the curator effort, including existing ZK
>> >> committers/contributors.
>> >>
>> >> if curator felt it should be a tlp (at time of graduation) I think
>> >> that would be fine too.
>> >>
>> >> I would be happy to Champion/Mentor this effort.
>> >>
>> >> Patrick
>> >>
>> >> On Mon, Dec 5, 2011 at 11:06 AM, Ted Dunning <[EMAIL PROTECTED]>
>> wrote:
>> >>> Ben,
>> >>>
>> >>> I think that you are right on target with this.  We need to have a
>> wider
>> >>> community of developers in order to have the bandwidth to handle
>> recipes
>> >>> and the recipes really do need separate release cycles.  Independent
>> >>> releases should be not much of an issue given how compatible ZK
>> versions
>> >>> tend to be.
>> >>>
>> >>> On Mon, Dec 5, 2011 at 10:59 AM, Benjamin Reed <[EMAIL PROTECTED]>
>> wrote:
>> >>>
>> >>>> i also agreed that it would be great to build a community around
>> >>>> curator especially if it could pull in other zk recipes. i've felt
>>for
>> >>>> a while that the core developers don't have the bandwidth to really
>> >>>> keep track of recipe development and recipes are a very important
>> >>>> aspect of zk. so, having a self sustaining community of developers
>> >>>> focused on that would be awesome. being able to have a separate
>> >>>> release cycle is also important i think. (i may be reading too much
>> >>>> into the proposal though :)
>> >>>>
>> >>>> ben
>> >>>>
>> >>>> On Mon, Dec 5, 2011 at 7:14 AM, Flavio Junqueira
>><[EMAIL PROTECTED]>
>> >>>> wrote:
>> >>>> > I suppose you're just trying to sense if others think that it
>>would
>> be a
>> >>>> > good idea to have it as a subproject. If so, I'm in favor of
>> putting a
>> >>>> > proposal together, +1.
>> >>>> >
>> >>>> > -Flavio
>> >>>> >
>> >>>> > On Dec 2, 2011, at 8:45 PM, Patrick Hunt wrote:
>> >>>> >
>> >>>> >> Somehow this got off list, Jordan and I just noticed, summary so
>> far:
>> >>>> >>
>> >>>> >> ---------- Forwarded message ----------
>> >>>> >> From: Patrick Hunt <[EMAIL PROTECTED]>
>> >>>> >> Date: Fri, Dec 2, 2011 at 9:56 AM
>> >>>> >> Subject: Re: Proposal: create a separate ZooKeeper release
>> artifact for
>> >>>> >> recipes
>> >>>> >> To: Jordan Zimmerman <[EMAIL PROTECTED]>
>> >>>> >>
>> >>>> >>
>> >>>> >> Did you mean to reply just to me? I think this is a great idea
>>btw,
>> >>>> >> just need to work out the mechanics of getting it integrated and
>> get
>>

Hi Ted. Incubator has a number of benefits for new projects; helping
them learn the ropes of Apache, setup infrastructure, build community,
create their own Apache blessed release, etc... That's a big part of
the responsibility that IPMC members take on when a project enters
incubation, something we'd (ZKPMC) have to do ourselves in the
approach you outline. Would you be able to commit that sort of time?

wrt examples:

MRUnit is an incubator project, it was a contrib of Hadoop. Hadoop
recently worked to shed itself of all (most?) contribs. This is
similar no?

Apache Felix is another example (in the extreme, it has 20 subs)
http://felix.apache.org/site/index.html

Doug has always told me that you want to be guided by community more
than anything. Keep two projects together if they are the same
community, otw separating them is ok (he strongly favors incubator
over sub).

Patrick

On Mon, Dec 5, 2011 at 12:36 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
> -1
>
> I don't think that a full incubator process is needed or even useful here.
>  Incubator is ONE process in Apache process for this, but a contrib
> artifact is another way to do it.
>
> This isn't a sub-project.  This is additional ZK software.  It just isn't
> the core stuff.   This is more akin to Solr being added to Lucene than it
> is like Mahout spinning out of Lucene ultimately as a top level project.
>
>
> On Mon, Dec 5, 2011 at 11:58 AM, Mahadev Konar <[EMAIL PROTECTED]>wrote:
>
>> +1...
>>
>> mahadev
>>
>> On Mon, Dec 5, 2011 at 11:42 AM, Benjamin Reed <[EMAIL PROTECTED]> wrote:
>> > +1
>> >
>> > On Mon, Dec 5, 2011 at 11:11 AM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>> >> Incubator is the Apache recommended way to handle this. We could be
>> >> the sponsor, with the intent that once Curator graduates from the
>> >> incubator we would accept it
>> >>
>> http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Sponsor
>> >> anyone could join the curator effort, including existing ZK
>> >> committers/contributors.
>> >>
>> >> if curator felt it should be a tlp (at time of graduation) I think
>> >> that would be fine too.
>> >>
>> >> I would be happy to Champion/Mentor this effort.
>> >>
>> >> Patrick
>> >>
>> >> On Mon, Dec 5, 2011 at 11:06 AM, Ted Dunning <[EMAIL PROTECTED]>
>> wrote:
>> >>> Ben,
>> >>>
>> >>> I think that you are right on target with this.  We need to have a
>> wider
>> >>> community of developers in order to have the bandwidth to handle
>> recipes
>> >>> and the recipes really do need separate release cycles.  Independent
>> >>> releases should be not much of an issue given how compatible ZK
>> versions
>> >>> tend to be.
>> >>>
>> >>> On Mon, Dec 5, 2011 at 10:59 AM, Benjamin Reed <[EMAIL PROTECTED]>
>> wrote:
>> >>>
>> >>>> i also agreed that it would be great to build a community around
>> >>>> curator especially if it could pull in other zk recipes. i've felt for
>> >>>> a while that the core developers don't have the bandwidth to really
>> >>>> keep track of recipe development and recipes are a very important
>> >>>> aspect of zk. so, having a self sustaining community of developers
>> >>>> focused on that would be awesome. being able to have a separate
>> >>>> release cycle is also important i think. (i may be reading too much
>> >>>> into the proposal though :)
>> >>>>
>> >>>> ben
>> >>>>
>> >>>> On Mon, Dec 5, 2011 at 7:14 AM, Flavio Junqueira <[EMAIL PROTECTED]>
>> >>>> wrote:
>> >>>> > I suppose you're just trying to sense if others think that it would
>> be a
>> >>>> > good idea to have it as a subproject. If so, I'm in favor of
>> putting a
>> >>>> > proposal together, +1.
>> >>>> >
>> >>>> > -Flavio
>> >>>> >
>> >>>> > On Dec 2, 2011, at 8:45 PM, Patrick Hunt wrote:
>> >>>> >
>> >>>> >> Somehow this got off list, Jordan and I just noticed, summary so
>> far:
>> >>>> >>
>> >>>> >> ---------- Forwarded message ----------
>> >>>> >> From: Patrick Hunt <[EMAIL PROTECTED]>
>> >>>> >> Date: Fri, Dec 2, 2011 at 9:56 AM

Jordan,

My idea would be a single pool of committers who tend to have
specializations for committing.  There would also possibly be different
policies relative to review before or after commit for different parts of
the project.  My guess is that many of the committers would cross the lines
often, especially since the core committers would probably often have
opinions about recipes.

Pat,

I am not talking about a sub-project.  I am talking about us just starting
a recipes deliverable right now and start accepting contributions (notably
Curator).  As people make significant and continued contributions, we could
make them ZK committers.  This gives a ready made community, expertise with
release processes and so on with less effort than a full-scale incubation
process.

And yes, I would be willing to help with some of this.

With regard to MRUnit, I don't consider the situations parallel.  ZK is
usable by itself, but not for most implementors.  Curator and similar
recipes provide the necessary bridge.  As such, I think that Solr is a much
better analogy.

I completely agree with Doug that community overlap is key.  Here, I can't
imagine any ZK recipe user who is not a ZK user.  I can also imagine that
once the recipes are really available that there will be few ZK users who
are not recipe users.  That seems to me to imply that the communities are
the same.

On Mon, Dec 5, 2011 at 1:50 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:

> Hi Ted. Incubator has a number of benefits for new projects; helping
> them learn the ropes of Apache, setup infrastructure, build community,
> create their own Apache blessed release, etc... That's a big part of
> the responsibility that IPMC members take on when a project enters
> incubation, something we'd (ZKPMC) have to do ourselves in the
> approach you outline. Would you be able to commit that sort of time?
>
> wrt examples:
>
> MRUnit is an incubator project, it was a contrib of Hadoop. Hadoop
> recently worked to shed itself of all (most?) contribs. This is
> similar no?
>
> Apache Felix is another example (in the extreme, it has 20 subs)
> http://felix.apache.org/site/index.html
>
> Doug has always told me that you want to be guided by community more
> than anything. Keep two projects together if they are the same
> community, otw separating them is ok (he strongly favors incubator
> over sub).
>
> Patrick
>
> On Mon, Dec 5, 2011 at 12:36 PM, Ted Dunning <[EMAIL PROTECTED]>
> wrote:
> > -1
> >
> > I don't think that a full incubator process is needed or even useful
> here.
> >  Incubator is ONE process in Apache process for this, but a contrib
> > artifact is another way to do it.
> >
> > This isn't a sub-project.  This is additional ZK software.  It just isn't
> > the core stuff.   This is more akin to Solr being added to Lucene than it
> > is like Mahout spinning out of Lucene ultimately as a top level project.
> >
> >
> > On Mon, Dec 5, 2011 at 11:58 AM, Mahadev Konar <[EMAIL PROTECTED]
> >wrote:
> >
> >> +1...
> >>
> >> mahadev
> >>
> >> On Mon, Dec 5, 2011 at 11:42 AM, Benjamin Reed <[EMAIL PROTECTED]>
> wrote:
> >> > +1
> >> >
> >> > On Mon, Dec 5, 2011 at 11:11 AM, Patrick Hunt <[EMAIL PROTECTED]>
> wrote:
> >> >> Incubator is the Apache recommended way to handle this. We could be
> >> >> the sponsor, with the intent that once Curator graduates from the
> >> >> incubator we would accept it
> >> >>
> >>
> http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Sponsor
> >> >> anyone could join the curator effort, including existing ZK
> >> >> committers/contributors.
> >> >>
> >> >> if curator felt it should be a tlp (at time of graduation) I think
> >> >> that would be fine too.
> >> >>
> >> >> I would be happy to Champion/Mentor this effort.
> >> >>
> >> >> Patrick
> >> >>
> >> >> On Mon, Dec 5, 2011 at 11:06 AM, Ted Dunning <[EMAIL PROTECTED]>
> >> wrote:
> >> >>> Ben,
> >> >>>
> >> >>> I think that you are right on target with this.  We need to have a
> >> wider

I agree with Ted. Patrick and I talked about a sub-project but what Ted is
suggesting seems so much better for everyone. I understand the limitations
(being tied to ZK server's release schedule), etc. End-users though really
are after the recipes. Unless the ZK distro comes with quality recipes,
users will be confused and frustrated.

-JZ

On 12/5/11 2:27 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:

>Jordan,
>
>My idea would be a single pool of committers who tend to have
>specializations for committing.  There would also possibly be different
>policies relative to review before or after commit for different parts of
>the project.  My guess is that many of the committers would cross the
>lines
>often, especially since the core committers would probably often have
>opinions about recipes.
>
>Pat,
>
>I am not talking about a sub-project.  I am talking about us just starting
>a recipes deliverable right now and start accepting contributions (notably
>Curator).  As people make significant and continued contributions, we
>could
>make them ZK committers.  This gives a ready made community, expertise
>with
>release processes and so on with less effort than a full-scale incubation
>process.
>
>And yes, I would be willing to help with some of this.
>
>With regard to MRUnit, I don't consider the situations parallel.  ZK is
>usable by itself, but not for most implementors.  Curator and similar
>recipes provide the necessary bridge.  As such, I think that Solr is a
>much
>better analogy.
>
>I completely agree with Doug that community overlap is key.  Here, I can't
>imagine any ZK recipe user who is not a ZK user.  I can also imagine that
>once the recipes are really available that there will be few ZK users who
>are not recipe users.  That seems to me to imply that the communities are
>the same.
>
>On Mon, Dec 5, 2011 at 1:50 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>
>> Hi Ted. Incubator has a number of benefits for new projects; helping
>> them learn the ropes of Apache, setup infrastructure, build community,
>> create their own Apache blessed release, etc... That's a big part of
>> the responsibility that IPMC members take on when a project enters
>> incubation, something we'd (ZKPMC) have to do ourselves in the
>> approach you outline. Would you be able to commit that sort of time?
>>
>> wrt examples:
>>
>> MRUnit is an incubator project, it was a contrib of Hadoop. Hadoop
>> recently worked to shed itself of all (most?) contribs. This is
>> similar no?
>>
>> Apache Felix is another example (in the extreme, it has 20 subs)
>> http://felix.apache.org/site/index.html
>>
>> Doug has always told me that you want to be guided by community more
>> than anything. Keep two projects together if they are the same
>> community, otw separating them is ok (he strongly favors incubator
>> over sub).
>>
>> Patrick
>>
>> On Mon, Dec 5, 2011 at 12:36 PM, Ted Dunning <[EMAIL PROTECTED]>
>> wrote:
>> > -1
>> >
>> > I don't think that a full incubator process is needed or even useful
>> here.
>> >  Incubator is ONE process in Apache process for this, but a contrib
>> > artifact is another way to do it.
>> >
>> > This isn't a sub-project.  This is additional ZK software.  It just
>>isn't
>> > the core stuff.   This is more akin to Solr being added to Lucene
>>than it
>> > is like Mahout spinning out of Lucene ultimately as a top level
>>project.
>> >
>> >
>> > On Mon, Dec 5, 2011 at 11:58 AM, Mahadev Konar
>><[EMAIL PROTECTED]
>> >wrote:
>> >
>> >> +1...
>> >>
>> >> mahadev
>> >>
>> >> On Mon, Dec 5, 2011 at 11:42 AM, Benjamin Reed <[EMAIL PROTECTED]>
>> wrote:
>> >> > +1
>> >> >
>> >> > On Mon, Dec 5, 2011 at 11:11 AM, Patrick Hunt <[EMAIL PROTECTED]>
>> wrote:
>> >> >> Incubator is the Apache recommended way to handle this. We could
>>be
>> >> >> the sponsor, with the intent that once Curator graduates from the
>> >> >> incubator we would accept it
>> >> >>
>> >>
>>
>>http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Sp

I don't think that is necessary.

On Mon, Dec 5, 2011 at 2:44 PM, Jordan Zimmerman <[EMAIL PROTECTED]>wrote:

> I understand the limitations
> (being tied to ZK server's release schedule), etc.
>

How would that work?

On 12/5/11 2:49 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:

>I don't think that is necessary.
>
>On Mon, Dec 5, 2011 at 2:44 PM, Jordan Zimmerman
><[EMAIL PROTECTED]>wrote:
>
>> I understand the limitations
>> (being tied to ZK server's release schedule), etc.
>>

There would be two artifacts.  The recipes artifact would have a particular
version of ZK as a dependency.  There might be point releases of the
recipes to backport features.

It is customary with tightly coupled things like this to synchronize major
version numbers.  With ZK, major and minor might be appropriate.  That
doesn't affect the schedule, however.

On Mon, Dec 5, 2011 at 2:55 PM, Jordan Zimmerman <[EMAIL PROTECTED]>wrote:

> How would that work?
>
> On 12/5/11 2:49 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>
> >I don't think that is necessary.
> >
> >On Mon, Dec 5, 2011 at 2:44 PM, Jordan Zimmerman
> ><[EMAIL PROTECTED]>wrote:
> >
> >> I understand the limitations
> >> (being tied to ZK server's release schedule), etc.
> >>
>
>

I see - this would be done in Ivy. OK by me.

So, to summarize, there are 3 possibilities:

* Push Curator into ZooKeeper proper under a new recipes artifact. Curator
would get n committers from Netflix with the understanding that their
focus is on Curator
* Start a sub-project ala BookKeeper for ZooKeeper with its own committer
list
* Put Curator into the Incubator and follow that road

Ted (and now I) prefer the first option. I believe Patrick prefers the
third option but would accept the second. How do the others feel?

-JZ

On 12/5/11 3:06 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:

>There would be two artifacts.  The recipes artifact would have a
>particular
>version of ZK as a dependency.  There might be point releases of the
>recipes to backport features.
>
>It is customary with tightly coupled things like this to synchronize major
>version numbers.  With ZK, major and minor might be appropriate.  That
>doesn't affect the schedule, however.
>
>On Mon, Dec 5, 2011 at 2:55 PM, Jordan Zimmerman
><[EMAIL PROTECTED]>wrote:
>
>> How would that work?
>>
>> On 12/5/11 2:49 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>>
>> >I don't think that is necessary.
>> >
>> >On Mon, Dec 5, 2011 at 2:44 PM, Jordan Zimmerman
>> ><[EMAIL PROTECTED]>wrote:
>> >
>> >> I understand the limitations
>> >> (being tied to ZK server's release schedule), etc.
>> >>
>>
>>

Some nuances.  Overall, I like the way you are working for consensus.

On Mon, Dec 5, 2011 at 3:13 PM, Jordan Zimmerman <[EMAIL PROTECTED]>wrote:

> I see - this would be done in Ivy. OK by me.
>

ZK is moving to maven, I would prefer to just jump recipes to there
directly.  I can set up the project initially.
>
> So, to summarize, there are 3 possibilities:
>
> * Push Curator into ZooKeeper proper under a new recipes artifact. Curator
> would get n committers from Netflix with the understanding that their
> focus is on Curator
>

Initially, n would be a very small number (possibly even 0, but that seems
unnecessary).  The number could increase over time.
> * Start a sub-project ala BookKeeper for ZooKeeper with its own committer
> list
> * Put Curator into the Incubator and follow that road
>
> Ted (and now I) prefer the first option. I believe Patrick prefers the
> third option but would accept the second. How do the others feel?
>
>
I don't really think that we have heard from Patrick on option 1.  I think
he was thinking I was suggesting option 2 and I agree with him that is
sub-optimal.

>ZK is moving to maven, I would prefer to just jump recipes to there
>directly.  I can set up the project initially.
Better for me. Curator is Maven already.

-JZ

On 12/5/11 3:29 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:

>Some nuances.  Overall, I like the way you are working for consensus.
>
>On Mon, Dec 5, 2011 at 3:13 PM, Jordan Zimmerman
><[EMAIL PROTECTED]>wrote:
>
>> I see - this would be done in Ivy. OK by me.
>>
>
>ZK is moving to maven, I would prefer to just jump recipes to there
>directly.  I can set up the project initially.
>
>
>>
>> So, to summarize, there are 3 possibilities:
>>
>> * Push Curator into ZooKeeper proper under a new recipes artifact.
>>Curator
>> would get n committers from Netflix with the understanding that their
>> focus is on Curator
>>
>
>Initially, n would be a very small number (possibly even 0, but that seems
>unnecessary).  The number could increase over time.
>
>
>> * Start a sub-project ala BookKeeper for ZooKeeper with its own
>>committer
>> list
>> * Put Curator into the Incubator and follow that road
>>
>> Ted (and now I) prefer the first option. I believe Patrick prefers the
>> third option but would accept the second. How do the others feel?
>>
>>
>I don't really think that we have heard from Patrick on option 1.  I think
>he was thinking I was suggesting option 2 and I agree with him that is
>sub-optimal.

On 12/5/11 3:29 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:

>Initially, n would be a very small number (possibly even 0, but that seems
>unnecessary).  The number could increase over time.

We'd want 1 (me) at minimum. 2 would be better as I have a backup here at
Netflix.

-JZ

On Mon, Dec 5, 2011 at 3:33 PM, Jordan Zimmerman <[EMAIL PROTECTED]>wrote:

>
> On 12/5/11 3:29 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>
> >Initially, n would be a very small number (possibly even 0, but that seems
> >unnecessary).  The number could increase over time.
>
> We'd want 1 (me) at minimum. 2 would be better as I have a backup here at
> Netflix.
Let's see what the rest of the ZK world says.

I vote incubator. It seems to be to zookeeper as hector is to cassandra.

>From my phone
On Dec 5, 2011 7:13 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:

> On Mon, Dec 5, 2011 at 3:33 PM, Jordan Zimmerman <[EMAIL PROTECTED]
> >wrote:
>
> >
> > On 12/5/11 3:29 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
> >
> > >Initially, n would be a very small number (possibly even 0, but that
> seems
> > >unnecessary).  The number could increase over time.
> >
> > We'd want 1 (me) at minimum. 2 would be better as I have a backup here at
> > Netflix.
>
>
> Let's see what the rest of the ZK world says.
>

On Mon, Dec 5, 2011 at 2:27 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
> I am not talking about a sub-project.  I am talking about us just starting
> a recipes deliverable right now and start accepting contributions (notably
> Curator).  As people make significant and continued contributions, we could
> make them ZK committers.  This gives a ready made community, expertise with
> release processes and so on with less effort than a full-scale incubation
> process.

Hi Ted. Sounds reasonable and maybe that's the way to go based on
Jordan's feedback. What I'm concerned about is that we could
negatively impact ZK development where we have very limited resources
as it is. My initial thought was to instead allow a core community to
form around Curator in the incubator, and then pull back into ZK in
whichever way makes most sense (separate artifact or sub, either is
fine w/me) once that happens. We would eventually have two ZK release
artifacts in this way, while still allowing Curator to initially
mature under the guidance of the incubator.

However I could see us go any of these ways, these are just
suggestions based on my personal experience. As you mention later in
the thread it would be good to see what others think.

Patrick

> On Mon, Dec 5, 2011 at 1:50 PM, Patrick Hunt <[EMAIL PROTECTED]> wrote:
>
>> Hi Ted. Incubator has a number of benefits for new projects; helping
>> them learn the ropes of Apache, setup infrastructure, build community,
>> create their own Apache blessed release, etc... That's a big part of
>> the responsibility that IPMC members take on when a project enters
>> incubation, something we'd (ZKPMC) have to do ourselves in the
>> approach you outline. Would you be able to commit that sort of time?
>>
>> wrt examples:
>>
>> MRUnit is an incubator project, it was a contrib of Hadoop. Hadoop
>> recently worked to shed itself of all (most?) contribs. This is
>> similar no?
>>
>> Apache Felix is another example (in the extreme, it has 20 subs)
>> http://felix.apache.org/site/index.html
>>
>> Doug has always told me that you want to be guided by community more
>> than anything. Keep two projects together if they are the same
>> community, otw separating them is ok (he strongly favors incubator
>> over sub).
>>
>> Patrick
>>
>> On Mon, Dec 5, 2011 at 12:36 PM, Ted Dunning <[EMAIL PROTECTED]>
>> wrote:
>> > -1
>> >
>> > I don't think that a full incubator process is needed or even useful
>> here.
>> >  Incubator is ONE process in Apache process for this, but a contrib
>> > artifact is another way to do it.
>> >
>> > This isn't a sub-project.  This is additional ZK software.  It just isn't
>> > the core stuff.   This is more akin to Solr being added to Lucene than it
>> > is like Mahout spinning out of Lucene ultimately as a top level project.
>> >
>> >
>> > On Mon, Dec 5, 2011 at 11:58 AM, Mahadev Konar <[EMAIL PROTECTED]
>> >wrote:
>> >
>> >> +1...
>> >>
>> >> mahadev
>> >>
>> >> On Mon, Dec 5, 2011 at 11:42 AM, Benjamin Reed <[EMAIL PROTECTED]>
>> wrote:
>> >> > +1
>> >> >
>> >> > On Mon, Dec 5, 2011 at 11:11 AM, Patrick Hunt <[EMAIL PROTECTED]>
>> wrote:
>> >> >> Incubator is the Apache recommended way to handle this. We could be
>> >> >> the sponsor, with the intent that once Curator graduates from the
>> >> >> incubator we would accept it
>> >> >>
>> >>
>> http://incubator.apache.org/incubation/Roles_and_Responsibilities.html#Sponsor
>> >> >> anyone could join the curator effort, including existing ZK
>> >> >> committers/contributors.
>> >> >>
>> >> >> if curator felt it should be a tlp (at time of graduation) I think
>> >> >> that would be fine too.
>> >> >>
>> >> >> I would be happy to Champion/Mentor this effort.
>> >> >>
>> >> >> Patrick
>> >> >>
>> >> >> On Mon, Dec 5, 2011 at 11:06 AM, Ted Dunning <[EMAIL PROTECTED]>
>> >> wrote:
>> >> >>> Ben,
>> >> >>>
>> >> >>> I think that you are right on target with this.  We need to have a
>> >> wider
>> >> >>> community of developers in order to have the bandwidth to handle

IF we are talking analogies, there are SolR / Lucene, Mahout Collections /
Mahout, PiggyBank / Pig that go the other way.  You will be able to add
many more as well, starting with Lucene / Hadoop and so on.

My thought is that it really has to do most with common development
interests.  The projects that became TLP's had divergent communities and
those that stuck together had more overlapping communities.  In this case,
I see lots of overlap because I have interests on both sides.  Other people
may care only about one side or the other, but I suspect that we actually
have a spectrum rather than a dichotomy.

On Mon, Dec 5, 2011 at 5:35 PM, Camille Fournier <[EMAIL PROTECTED]> wrote:

> I vote incubator. It seems to be to zookeeper as hector is to cassandra.
>
> From my phone
> On Dec 5, 2011 7:13 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>
> > On Mon, Dec 5, 2011 at 3:33 PM, Jordan Zimmerman <[EMAIL PROTECTED]
> > >wrote:
> >
> > >
> > > On 12/5/11 3:29 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
> > >
> > > >Initially, n would be a very small number (possibly even 0, but that
> > seems
> > > >unnecessary).  The number could increase over time.
> > >
> > > We'd want 1 (me) at minimum. 2 would be better as I have a backup here
> at
> > > Netflix.
> >
> >
> > Let's see what the rest of the ZK world says.
> >
>

I'm sure there is. But I still stand behind the idea of this as an incubator.
Personally, I am not comfortable endorsing this project as the
be-all-end-all zk client. I think we have to be truly comfortable
supporting it as such if we pull it in as part of our code base, no
matter how tangential we might keep it, and I for one am not on board
with that just yet. Maybe in a few months if we saw a significant
uptick in adoption by our user base, we could evaluate it as such. But
right now I think it's premature to take this code base on.

C

On Mon, Dec 5, 2011 at 8:59 PM, Ted Dunning <[EMAIL PROTECTED]> wrote:
> IF we are talking analogies, there are SolR / Lucene, Mahout Collections /
> Mahout, PiggyBank / Pig that go the other way.  You will be able to add
> many more as well, starting with Lucene / Hadoop and so on.
>
> My thought is that it really has to do most with common development
> interests.  The projects that became TLP's had divergent communities and
> those that stuck together had more overlapping communities.  In this case,
> I see lots of overlap because I have interests on both sides.  Other people
> may care only about one side or the other, but I suspect that we actually
> have a spectrum rather than a dichotomy.
>
> On Mon, Dec 5, 2011 at 5:35 PM, Camille Fournier <[EMAIL PROTECTED]> wrote:
>
>> I vote incubator. It seems to be to zookeeper as hector is to cassandra.
>>
>> From my phone
>> On Dec 5, 2011 7:13 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>>
>> > On Mon, Dec 5, 2011 at 3:33 PM, Jordan Zimmerman <[EMAIL PROTECTED]
>> > >wrote:
>> >
>> > >
>> > > On 12/5/11 3:29 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>> > >
>> > > >Initially, n would be a very small number (possibly even 0, but that
>> > seems
>> > > >unnecessary).  The number could increase over time.
>> > >
>> > > We'd want 1 (me) at minimum. 2 would be better as I have a backup here
>> at
>> > > Netflix.
>> >
>> >
>> > Let's see what the rest of the ZK world says.
>> >
>>

To me it is difficult to assess the various options without seeing a  
proposal. If you feel strongly about it being a zookeeper sub-project,  
I would suggest to write a proposal following the incubator guidelines  
(http://incubator.apache.org/guides/proposal.html) and let the pmc  
discuss and vote. If the zookeeper pmc does not accept it, then I'm  
sure you can submit it pretty much verbatim to incubator.

If there is interest, there are lots of samples here:

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

-Flavio

On Dec 6, 2011, at 3:11 AM, Camille Fournier wrote:

> I'm sure there is. But I still stand behind the idea of this as an  
> incubator.
> Personally, I am not comfortable endorsing this project as the
> be-all-end-all zk client. I think we have to be truly comfortable
> supporting it as such if we pull it in as part of our code base, no
> matter how tangential we might keep it, and I for one am not on board
> with that just yet. Maybe in a few months if we saw a significant
> uptick in adoption by our user base, we could evaluate it as such. But
> right now I think it's premature to take this code base on.
>
> C
>
> On Mon, Dec 5, 2011 at 8:59 PM, Ted Dunning <[EMAIL PROTECTED]>  
> wrote:
>> IF we are talking analogies, there are SolR / Lucene, Mahout  
>> Collections /
>> Mahout, PiggyBank / Pig that go the other way.  You will be able to  
>> add
>> many more as well, starting with Lucene / Hadoop and so on.
>>
>> My thought is that it really has to do most with common development
>> interests.  The projects that became TLP's had divergent  
>> communities and
>> those that stuck together had more overlapping communities.  In  
>> this case,
>> I see lots of overlap because I have interests on both sides.  
>> Other people
>> may care only about one side or the other, but I suspect that we  
>> actually
>> have a spectrum rather than a dichotomy.
>>
>> On Mon, Dec 5, 2011 at 5:35 PM, Camille Fournier  
>> <[EMAIL PROTECTED]> wrote:
>>
>>> I vote incubator. It seems to be to zookeeper as hector is to  
>>> cassandra.
>>>
>>> From my phone
>>> On Dec 5, 2011 7:13 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>>>
>>>> On Mon, Dec 5, 2011 at 3:33 PM, Jordan Zimmerman <[EMAIL PROTECTED]
>>>>> wrote:
>>>>
>>>>>
>>>>> On 12/5/11 3:29 PM, "Ted Dunning" <[EMAIL PROTECTED]> wrote:
>>>>>
>>>>>> Initially, n would be a very small number (possibly even 0, but  
>>>>>> that
>>>> seems
>>>>>> unnecessary).  The number could increase over time.
>>>>>
>>>>> We'd want 1 (me) at minimum. 2 would be better as I have a  
>>>>> backup here
>>> at
>>>>> Netflix.
>>>>
>>>>
>>>> Let's see what the rest of the ZK world says.
>>>>
>>>

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

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.

== 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, recipe algorithms and best practices 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. 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

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

Build:
* Apache Maven

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

Thanks Jordan.
Want to start a new thread on this? THis has already dragged on for a
while. Can you also include - what happens to existing recipes? Would
this new sub project include the already existing recipes and port
them using Curator?

thanks
mahadev
On Mon, Dec 12, 2011 at 11:06 PM, 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.
>
> == 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, recipe algorithms and best practices 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. 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
>
> Test:
> * Test NG
> * Apache Commons Math
> * Mockito
> * Javaassist

OK - I started a new thread. I've updated the proposal to mention that the
currently bundled recipes should be deprecated.

-JZ

On 12/13/11 12:01 AM, "Mahadev Konar" <[EMAIL PROTECTED]> wrote:

>Thanks Jordan.
>Want to start a new thread on this? THis has already dragged on for a
>while. Can you also include - what happens to existing recipes? Would
>this new sub project include the already existing recipes and port
>them using Curator?
>
>thanks
>mahadev
>
>
>On Mon, Dec 12, 2011 at 11:06 PM, 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.
>>
>> == 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, recipe algorithms and best practices 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. 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