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 <ph...@apache.org>
Date: Fri, Dec 2, 2011 at 9:56 AM
Subject: Re: Proposal: create a separate ZooKeeper release artifact
for recipes
To: Jordan Zimmerman <jzimmer...@netflix.com>
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 <jzimmer...@netflix.com
> 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" <ph...@apache.org> wrote:
On Thu, Dec 1, 2011 at 2:05 PM, Jordan Zimmerman <jzimmer...@netflix.com
>
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" <ph...@apache.org> wrote:
On Thu, Dec 1, 2011 at 1:26 PM, Jordan Zimmerman
<jzimmer...@netflix.com>
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" <ted.dunn...@gmail.com> 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
by
module's content. The review can include a determination of who
should
actually do the commit.
Moreover, projects can easily have more than one artifact.
Mahout has
three independent artifacts (mahout-math, mahout-collections
and the
core
stuff with examples and integration code). That works well.
There
are
different sets of committers who are typically the ones who
work on
different components. The overall level of diligence required
in
Mahout
is
much lower than for Zookeeper as you might expect, but the
principle
that
multiple artifacts are fine is still the same. Likewise, the
idea of
committers with specialized expertise also applies here.
There is a tradition in Zookeeper of having a very high bar for
committership, but experience in some other projects indicates
that
this
doesn't actually help quality or security all that much and it
can be
argued to decrease community involvement a bit.
On Wed, Nov 30, 2011 at 5:11 PM, Patrick Hunt <ph...@apache.org>
wrote:
Curator has been getting a lot of interest and was just
officially
announced by Netflix:
http://techblog.netflix.com/2011/11/introducing-curator-netflix-zooke
ep
er
.html
I chatted briefly with @adrianco @chad_walters @randgalt
(Jordan
Zimmerman) on twitter and the idea of moving Curator into
Apache/ZooKeeper came up:
https://twitter.com/#!/search/phunt%20curator
I wanted to restart this thread as a way of discussing this
idea in
more depth, and to gauge the interest of both communities. I
personally think this would be a great thing: both for users
and for
the development community itself. Thoughts?
Re the mechanics. See my original post below. Seems to me we
(ZK
PMC)
could sponsor Curator as an incubator project with the intent
to
bring
it to ZK as either a subproject (it's own committer list) or
as a
separate release artifact of the ZK TLP itself. Or just
shortcut the
incubator process altogether. My preference would be to go
incubator
first. At some point we would deprecate the existing ZK
recipes (ala
Curator had suitable replacements).
Patrick
On Fri, Jul 22, 2011 at 10:59 AM, Benjamin Reed <br...@apache.org
>
wrote:
while i agree with the sentiment of not fragmenting the
zookeeper
community and recipe committers also moving into core
development, i
also think it would be good if a strong community of
developers
grew
up around zookeeper recipes. to do that they need a sense of
identity,
and i'm not sure if they can get that with this proposal.
on the other hand the proposal does address all of the other
issues
i
have with recipe maintenance. the key is to grow a committer
base.
ben
On Wed, Jul 13, 2011 at 11:04 AM, Patrick Hunt <ph...@apache.org
>
wrote:
During the recent developer meetup we discussed how to more
effectively grow the recipes.
https://cwiki.apache.org/confluence/display/ZOOKEEPER/June2011Develop
er
Me
eting
The concerns seemed to be around managing changes, community
growth,
and releases. We discussed a number of approaches:
* move recipes into apache-extras
* or github
* or incubator
* or sub-project
each of these has it's good and bad points. One alternative
that
I
put
forth was to create a separate release artifact for recipes
as
part
of
the ZooKeeper project itself. What would this look like?
* zookeeper/trunk/src/recipes would move to
zookeeper/recipes/{trunk,branches,tags,...}
* there would be distinct/separate releases of zookeeper and
zookeeper-recipes artifacts
** these releases would not necessarily be synchronized,
although
we'd
want to ensure that particular versions of each release work
together
** these releases would go through our standard release
process -
ie
creation of release candidate by a committer and approval
by the
PMC
** recipes would no longer be included in "zookeeper" (core)
releases
* continue to use the ZOOKEEPER jira, with "recipes"
component
* space in the web and wiki sites for recipes specific pages
* recipes continue to use the std zookeeper mailing lists
* commits to recipes would continue to use our regular commit
process
(jira, rtc, etc...)
* we would accept new "ZooKeeper committers" with the
intent that
they
focus on their area of expertise, whether this be core
(zookeeper
trunk) or recipes.
This last item is the more interesting I think, the other
issues
are
all pretty straightforward. Although moving to sub (or out
entirely)
would allow us to have a separate commit list it would
fragment
the
ZooKeeper community. I also believe that over time
committers to
recipes would more likely get experience with core and start
contributing there as well. The only issue really, if you
want to
call
it that, is that we'd have committers with "guardrails"
implied.
ie
someone with more expertise in recipes than core. However
there
are
many other Apache projects that take this approach, and do it
successfully. Regardless RTC allows for review both before
and
after
a
change is committed.
What do you think?
Patrick
flavio
junqueira
research scientist
f...@yahoo-inc.com
direct +34 93-183-8828
avinguda diagonal 177, 8th floor, barcelona, 08018, es
phone (408) 349 3300 fax (408) 349 3301
