Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 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
-
Re: Proposal: create a separate ZooKeeper release artifact for recipes
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 <[EMAIL PROTECTED]> 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-zookeeper.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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> >> During the recent developer meetup we discussed how to more
> >> effectively grow the recipes.
> >>
> https://cwiki.apache.org/confluence/display/ZOOKEEPER/June2011DeveloperMeeting
> >>
> >> 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
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB