[jira] Commented: (ZOOKEEPER-80) Document process for client recipe contributions
[ https://issues.apache.org/jira/browse/ZOOKEEPER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12664645#action_12664645 ] Benjamin Reed commented on ZOOKEEPER-80: My perspective on the issue of the directory layout is that different language bindings for a given recipe should interoperate. to that end it seems best to have a directory representing a recipe, have the recipe specification in that directory and have the different language bindings as subdirectories of that directory. that way if the recipe needs to change, because of a bug for example, it is clear exactly what implementations need to be updated. Document process for client recipe contributions Key: ZOOKEEPER-80 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-80 Project: Zookeeper Issue Type: Task Components: documentation Reporter: Patrick Hunt Assignee: Patrick Hunt Per Doug's suggestion I'll use a link instead of copy/paste: http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-dev/200807.mbox/%3c487f8262.9020...@yahoo-inc.com%3e -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-80) Document process for client recipe contributions
[ https://issues.apache.org/jira/browse/ZOOKEEPER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12617827#action_12617827 ] Hiram Chirino commented on ZOOKEEPER-80: Hi, Here are my 2 cents for how to implement this so it co-exists nicely with ZOOKEEPER-103 For java at least, you want to group lots of small disjoint contributions into one jar. If they become more massive, it may be worth splitting it out to independent jars, but simplicities sake/maintenance needed to manage small contributions, one jar should be enough. The only tricky bit is that we also want to support implementing the recipe in other languages, so we want to also support multiple module directories. So my proposal is to have a module which would mainly hold the general documentation for the protocol which should be language agnostic: trunk/zookeeper-recipes/ trunk/zookeeper-recipes/src/docs And then we just have sub modules for the implementation of those recipes for the different languages. The java module would use maven directory layouts trunk/zookeeper-recipes/zookeeper-java-recipes trunk/zookeeper-recipes/zookeeper-java-recipes/src/main/java The c stuff would standard GNU c source layout trunk/zookeeper-recipes/zookeeper-c-recipes trunk/zookeeper-recipes/zookeeper-c-recipes/src ruby would use what every ruby folks are used to. trunk/zookeeper-recipes/zookeeper-ruby-recipes Also note that it might be better to replace 'recipes' term with 'protocols'. Document process for client recipe contributions Key: ZOOKEEPER-80 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-80 Project: Zookeeper Issue Type: Task Components: documentation Reporter: Patrick Hunt Assignee: Patrick Hunt Per Doug's suggestion I'll use a link instead of copy/paste: http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-dev/200807.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-80) Document process for client recipe contributions
[ https://issues.apache.org/jira/browse/ZOOKEEPER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12615817#action_12615817 ] Patrick Hunt commented on ZOOKEEPER-80: --- Ok, based on Jira comments and thread discussion I propose the following: 1) we'll add a new contrib directory as zookeeper/trunk/src/contrib/module this directory will contain user contributions - such as recipes and the pending fuse module, ex: zookeeper/trunk/src/contrib/recipes zookeeper/trunk/src/contrib/zkfuse (see ZOOKEEPER-25) let's call these sub-dirs contrib modules 2) each module will contain readme/build.xml (or autoconf etc...)/ src, docs, lib, etc subdirectories. if a module contains more than one lang implemention we would have src/c src/java etc... 3) recipes (any contrib module really) will have associated documentation in it's contrib/module/docs directory. Note that Hadoop, and ZooKeeper, use Apache forrest for their documentation and for generating the ASF hadoop.apache.org web site. 4) recipes will have a single source hierarchy: contrib/recipes/src/java/main/org/apache/zookeeper/recipes/leaderelection/... contrib/recipes/src/java/main/org/apache/zookeeper/recipes/locks/... etc... 5) build.xml for recipes will generate a release jar file zookeeper-recipes-version.jar, api docs, etc... which will be tar'd and included in the ZooKeeper release 6) recipe users will be encouraged to use the released jar files in their client code (no checking out from svn as originally proposed) 7) contrib module issues will be tracked on the zookeeper jira 8) contrib modules are maintained on an as is, best effort, work in progress basis. The contents of these contrib modules are tagged, versioned, built, and released along with the ZooKeeper clients/server release. Vote early vote often ;-) Document process for client recipe contributions Key: ZOOKEEPER-80 URL: https://issues.apache.org/jira/browse/ZOOKEEPER-80 Project: Zookeeper Issue Type: Task Components: documentation Reporter: Patrick Hunt Assignee: Patrick Hunt Per Doug's suggestion I'll use a link instead of copy/paste: http://mail-archives.apache.org/mod_mbox/hadoop-zookeeper-dev/200807.mbox/[EMAIL PROTECTED] -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (ZOOKEEPER-80) Document process for client recipe contributions
[
https://issues.apache.org/jira/browse/ZOOKEEPER-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12614466#action_12614466
]
Doug Cutting commented on ZOOKEEPER-80:
---
Whoa! Big issue description! Perhaps you could have gone with a link to the
mail archive? Descriptions are included in every message about the issue...
In any case, I think perhaps each recipe deserves its own code-tree, and should
hence be a separate contrib module. Perhaps, instead of 'contrib/' these
should just be under 'recipes/', with a separate src/, lib/, doc/, build.xml,
README.txt, etc. for each? Multiple language implementations would go in
different src/ subdirectories. Does that work?
Also, I am -1 for making these subversion-only. Only released software is
fully covered by the Apache license. Subversion is for internal exchange by
Apache of works-in-progress, not for end users.
Document process for client recipe contributions
Key: ZOOKEEPER-80
URL: https://issues.apache.org/jira/browse/ZOOKEEPER-80
Project: Zookeeper
Issue Type: Task
Components: documentation
Reporter: Patrick Hunt
Assignee: Patrick Hunt
How do we accept zk client recipe contributions? Initiated by the following
discussion on the mailing list:
-- ben reed wrote
Excellent proposal. The only thing I would add is that there should be
an english description of the recipe in subversion. That way if someone
wanted to do a compatible binding they can do it. If the recipe is on
the wiki it would be hard to keep it in sync, so it is important that it
is in subversion. My preference would be that the doc would be in the
same contrib subdirectory as the source for ease of maintenance.
ben
Patrick Hunt wrote:
James, thanks for the contribution! Tests and everything. :-)
Jacob sent some mail to the list recently (attached) that details a
protocol that he's used successfully (and picked up by some zk users).
I have a todo item to document this protocol on the recipes wiki page,
haven't gotten to it yet. Not sure how/if this matches what you've
done but we should sync up (also see below).
https://issues.apache.org/jira/browse/ZOOKEEPER-79
There has been some discussion on client side helper code in the past
however this is the first contribution. We need to make some decisions
and outline what/how we will accept.
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
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.
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)
4) We will not require parody btw the various client languages.
Currently we support Java/C clients, we will be adding various
scripting languages soon. Contributions will be submitted for various
clients (James' submission is for java), that will be placed into
contrib, if someone else contributes C bindings (etc...) we will add
those to contrib/recipes as well.
5) Implementations should strive to implement similar recipe protocols
(see 2 above, a good reason to document before implement). There may
be multiple, different, protocols each with their own implementation,
but for a particular protocol the implementations should be the same.
We may want to stress 5 even more - if multiple clients
implementations (c/java/...) are participating in a single instance of
leader election it will be CRITICAL for them to be inter-operable.
Comments, questions, suggestion?
Patrick
James Strachan wrote:
So having recently discovered ZooKeeper, I'm really liking it - good
job folks!
I've seen discussions of building high level features from the core ZK
library and had not seen any available on the interweb so figured I'd
have a try creating a simple one. Feel free to ignore it if a ZK ninja
can think of a neater way of doing it - I've basically followed the
protocol defined in the recent ZK presentation...
http://developer.yahoo.com/blogs/hadoop/2008/03/intro-to-zookeeper-video.html
I've submitted the code as a patch here...
https://issues.apache.org/jira/browse/ZOOKEEPER-78
I
