yuppie wrote: > Hi! > > > Wichert Akkerman wrote: >> Previously Jens Vagelpohl wrote: >>> That's not the issue I was trying to address. I was specifically >>> talking about putting functionality in the most appropriate part of >>> the stack, meaning moving it further towards the core. If there are >>> bits and pieces that make more sense in the CMF then saying "well, >>> just install our package" may satisfy users, but developers will >>> continue wasting time maintaining different implementations. >> Why would there be multiple implementations if they can just use the >> existing one? I do not see that. > > For the CMF project it is essential to have full control over its own > layer of the stack and to participate in the development of the Zope > layer. Using packages from the Plone repository means either using them > as a black box or joining the Plone Foundation to participate in their > development. IMO both options are not acceptable.
You don't need to join the Plone Foundation to develop packages in svn.plone.org. You *do* need to sign a contributor agreement granting some IP rights over that code to the Plone Foundation, in return for a promise that it will always be available under an open source license. There are no limits on who can sign that agreement or for what purpose they choose to work with the code in that repository. Of course, the same goes for svn.zope.org: you need to sign a document and grant certain rights over your work to the Zope Foundation. If CMF really cannot use packages not in svn.zope.org, then that's a bit sad and will invariably lead to a lot of re-invention rather than re-use. I don't really understand why it is "essential" to have this level of control over every line of code you use. This is entirely a self-imposed restriction. >> I do agree that work should be in in >> CMF itself, and this particular instance of the indexable wrappers is an >> excellent example of that. I hope that in the last few years we have >> already demonstrated that we really do want to work closer with the >> CMF and Zope communities. > > For technical reasons this collaboration is asymmetric. Plone is built > on top of Zope and CMF, not the other way round. If you want to work > really close with these communities, you have to be part of them and use > their repository. I wrote a package that, I hope, is useful. I am pretty sure it'll work with "plain CMF" and therefore with other consumers of the CMF, and if doesn't, I'd consider that a bug and fix it. I'm willing to work to make that package a part of the CMF platform, whether optional or fully integrated. To a certain extent, it already is: someone suing the CMF can choose to use plone.indexer in their own project, though they'll need to install it themselves. I don't quite see how this is asymmetric. Rather, it is an outcome of the evolution of this particular package. It's up to the CMF maintainers to decide whether it is desirable to actually adopt this package as part of a standard release. It's not always going to be appropriate (or even if it is, it's not always going to be the case) for every new line of code that *could* be useful to all/most CMF consumers to be built as part of the CMF itself from the outset. If the CMF project has no model for incorporating code from outside its (rather small) community, then I think that is more to the detriment of CMF than to those who created those packages and chose to put the effort in to reduce their dependencies and make them more generally useful. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book _______________________________________________ Zope-CMF maillist - Zope-CMF@lists.zope.org http://mail.zope.org/mailman/listinfo/zope-cmf See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests