Chris McDonough wrote:
> I'm pretty sure a steering group and a rebranding of existing software is not
> going to make us more effective. Here's what I believe would make us more
First of all, I'm not sure what Martijn is saying is necessarily in
dichotomy with what you're saying, so we may be going off-topic here.
> - encouraging radical change for experimentation purposes, releasing folks
> various constraints (backwards compatibility, style policing, historical
> - focusing on externalizing software; each egg should stand on its own as
> something that a non-Zope person would be able to understand and use
> in isolation. This means documentation for each thing, as well as
> a sane dependency graph. This is *less* about giving this collection
> of software a group name ("the zope framework") and more about
> making people *forget* that it is a part of some larger thing. When
> a piece of software does not have a purpose in isolation but still
> lives in its own egg, kill it off and merge it back into whatever
> thing its most closely related to.
> - Stop trying to version control and treat all this software in some
> overall release. Let each piece of software have its own life. Likewise
> if a piece of software does not have its own life, kill it.
As a consumer of various bits of the Zope Framework, I'd be pretty
troubled if no-one were to care about backward compatibility or testing
a known-good set (what we now call a "release") of things that are known
to work together. To have to do that myself (or ourselves, in the Plone
project) would be a substantial overhead; if we were concerned that
backwards compatibility would be ignored, we would have serious concerns
about adopting any piece of software coming out of the project.
Realistically, there's a release and management overhead that leads to
some kind of economy of scale. zope.* is a big namespace. Managing at
least some chunks of that namespace as a single unit will likely be
beneficial, in terms of getting consensus around evolution, instilling
some energy in people and setting goals to get things done, in terms of
making releases and managing expectations, and so on.
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -