Home | About | Sematext search-lucene.com search-hadoop.com
 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