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

Reply via email to