On Mon, Feb 25, 2013 at 7:10 PM, Greg Stein <[EMAIL PROTECTED]> wrote:
> My concern is that we're looking at two "new" committers, rather than
> a Curator community. Following normal Incubator work, Curator would
> build a community for itself. But then we'd have a community
> *distinct* from that of Zookeeper. And it really looks like this
> should be part of Zookeeper itself -- a more capable and easier-to-use
> So I question the incubation of this. Why do we want to build a
> new/separate project? Why isn't this just part of Zookeeper right from
> the start?
> I would suggest that this work is placed on a branch within Zookeeper.
> That Jordan and Jay become committers on that branch (not necessarily
> Zookeeper trunk). Over time, the branch can be folded into trunk,
> along with all the various tests, doc, and other artifacts that I see
> in the GitHub repository. And hopefully that Jordan and Jay become
> regular committers (and PMC members!) of the Zookeeper project itself.
> The current Zookeeper client can remain for backwards compat, and the
> Curator work can become the next-gen client.
> Honestly, in my opnion, incubating this project seems like it would
> create a distinct community, and really doesn't seem like it would
> serve the Zookeeper community.
> All that said, I am not familiar with the Zookeeper or Curator
> communities. But from this read, I don't think Incubation is the right
> approach. I would rather push for a more direct incorporation of
> Curator directly into Zookeeper. (use the short-form IP clearance) ...
> so, unless somebody can help me understand the communities and
> situation better, I'm -1 (binding) on this incubation. I'd rather see
> combined, rather than distinct, communities from the start.
The Curator library is built upon the current ZooKeeper client
libraries. They are an extension that implements higher level use
cases (what we call "recipes" in ZK) whereas the ZK libraries
implement lower level primitives. An analogy might be Apache Crunch
(recently graduated to TLP) and MapReduce. Also, not everyone agrees
with Jordan's assessment that Curator is 'better" than (or a
replacement for) the existing client libraries.
The ZK community discussed incorporating the Curator code about a year
ago. At that time there wasn't interest to adopt these libraries into
ZK itself. My belief is that if Curator were to go through incubation
the ZK community would be more likely to adopt it. Similar to how
HCatalog spun off to work on the metastore and recently merged back
into Hive. If there's significant overlap in the Curator podling
community and the ZK community that will be a strong indication that
they should be merged (my belief). If not it would have the
opportunity to go TLP.
Here's my report (ZooKeeper) to the board in Dec 2011 and the response
I received. This is one of the reasons I advised Jordan to go the
incubator approach. There's also the discussion thread on ZooKeeper
dev if you want more insight.
>> A discussion is currently under way regarding the possibility of> merging the recently open sourced "Curator" source base from> Netflix. These are client implementations of ZooKeeper "recipes"> (e.g. leadership election, group membership, etc...) which simplify> the act of using ZooKeeper in client side applications.>> The authors of Curator are unwilling to join the incubator, this is> based on their past experience as well as some of the ongoing issues> they are seeing wrt projects entering the incubator. They have> expressed a preference to come in either as a subproject or as a> separate release artifact of the TLP.
> to which the board responded:
> Doug Cutting (chairman):
> + Long-term, do you think that Curator will have an
> + indepdendent community from Zookeeper? If so, then it
> + ought to enter through the Incubator. If not then the
> + code might still enter through the incubator for
> + resolution of IP issues, but then transfer relatively