Patrick Hunt wrote:
my original intent was to have it as zookeeper/trunk/src/contrib/...
where this directory will have not only recipes but also other
contributions.
+1 That's what I meant too. And since you've said you want to package
these all as a single jar, then there should just be a single tree per
language, right?
zookeeper/trunk/src/contrib/recipes/src/java/org/apache/zookeeper/recipes/locking/
zookeeper/trunk/src/contrib/recipes/src/c++/locking/
What happens in this case then, you include them as part of ZK release
or you have a separate "contrib" release? It seems to me that this could
have a ripple effect - where contrib is causing regular releases to be
held up.
If you release them separately from the ZK core then they're a separate
Apache product, and should then probably be not in zookeeper/trunk, but
in zookeeper-recipes/trunk, etc.
Why would they hold up a release?
ZOOKEEPER-25 adds FUSE support, seems like we are going to have similar
issues to face there. Is this a separate "release" from recipes or are
all "contrib" considered to be a single release? What about when we add
REST & scripting support thru contrib....
I don't see the strong connection between releases and new features.
Typically at some point you feature-freeze, branch, and call that
release series X. Then, at some later point, you feature-freeze again,
and call that release series Y. They'll have different features. X may
not include FUSE support, and Y may.
Or you could choose a different release discipline, and permit new
contrib features in a release series, but no new core features. Or
something else. But at some point you're going to roll up a bunch of
code into a binary and vote on it and call it a release of Zookeeper and
a product of Apache.
Am I missing something?
Doug, is there any documentation that I could look at at Apache that
would help? Guidelines/bestpractice for "contrib"?
Not that I know of. Analogous things are perhaps httpd modules, and
httpd is a very well run project.
Doug
