Martin Aspeli wrote:
> yuppie wrote:
>> 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.
Just to make it clear: I'm talking about the code in the CMF and the
Zope layer. Not about lower level layers. I'm absolutely fine with
having Python and some other libraries in different repositories. And
I'm not talking about CMF users. I'm sure there are good reasons to use
Plone libraries together with the CMF.
I'm talking about closely related code. Maintaining it in different
repositories with different code ownership, license and policies creates
extra costs. Either everybody has to work in both repositories or you
have to ask people to make changes are releases. Refactoring code across
repository boundaries becomes almost impossible.
>> 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
> generally useful.
I don't think it's the role of the CMF project to integrate all the code
that could be useful for people building applications. Others like Plone
can do that much better.
The CMF has to become simpler, not more complex. Third party products
always add complexity. Incorporating new code means replacing old code
in a backwards compatible way, not just adding another hook.
Code evolution is useful, but it can't replace discussions and
Zope-CMF maillist - Zope-CMF@lists.zope.org
See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests