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 Plain View
Zookeeper >> mail # dev >> Proposal: create a separate ZooKeeper release artifact for recipes


+
Patrick Hunt 2011-12-02, 19:45
+
Patrick Hunt 2011-07-13, 18:04
Copy link to this message
-
Re: Proposal: create a separate ZooKeeper release artifact for recipes
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
> 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
>
+
Patrick Hunt 2011-12-01, 01:11
+
Jordan Zimmerman 2011-12-01, 01:31
+
Ted Dunning 2011-12-01, 01:42
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