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 >
