> 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
>> 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
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
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
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests