Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Zookeeper >> mail # dev >> Proposal: create a separate ZooKeeper release artifact for recipes


Copy link to this message
-
Proposal: create a separate ZooKeeper release artifact for recipes
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
>>>>