Patrick Hunt wrote:
1) I think we should have a
"contrib/recipes/{java/{main,test}/org/apache/zookeeper/... ,c/,...}"
hierarchy for contributions that implement recipes, including any helper
code
Are folks expected to be able to use this code as-is? Are these, in
effect, libraries? If so, you might make each a separate contrib
module, so they can be packaged as separate jars and folks can use them
ala carte.
2) We should first document recipes on the wiki, then implement them in
the code
http://wiki.apache.org/hadoop/ZooKeeper/ZooKeeperRecipes
The code should fully document the api/implementation, and refer to wiki
page for protocol specifics.
The wiki should not be used long-term for code documentation. It's a
good documentation scratchpad, but for code that's released, the
documentation should be versioned and released as well, and thus should
live in subversion.
3) What should we do relative to ZK releases. Are recipes included in a
release? Will bugs in recipes hold up a release?
My initial thought is that contrib is available through svn, but not
included in the release. If users want to access/use this code they will
be required to checkout/build themselves. (at least initially)
Won't recipes change as ZK API's change? If so, then recipes should be
versioned with releases. And if non-committers are expected to download
recipes, then, legally, they should be released through an official
release process. Stuff in svn isn't fully covered by the Apache
license. Apache only vouches for stuff that's gone through an official
release process. Subversion is for internal exchange by Apache of
works-in-progress, not for end users.
Doug
