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
