Chris McDonough wrote:
> I'm pretty sure a steering group and a rebranding of existing software is not
> going to make us more effective.
I'm proposing a deconstruction, not a rebranding; a new name is
introduced as an entity needs to be named, namely the Zope Framework.
What is going to make us more effective is:
* a recognition of current reality, i.e. the Zope Framework is not the
same as the Zope 3 application server and it serves a far wider audience.
> - encouraging radical change for experimentation purposes, releasing folks
> various constraints (backwards compatibility, style policing, historical
Who is going to make that decision to encourage this? Allow this? You?
Me? Who? Right now, *nobody* is making such decisions and nobody can
properly get away with saying they allow it. Leadership is a way to get
out of it.
> - discourage the contribution of stop energy (discourage
> the utterances of "don't", "stop", "this is wrong",
> "stop talking about this").
+1, though a simple discouraging of utterance can't accomplish it by
itself. What you need is active leadership that encourages such
> - 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.
Sure, I agree with all this. Does everybody? What if we get 3 times -1
and 3 times +1 in a discussion on it?
> 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.
Someone's still developing all this software: our community. Someone
needs to take responsibility for all this software. I'd say that group
is the Zope project.
Who decides to kill something off? Who decides whether a merge is okay?
Who decides we should have a documentation website for a widely used
> - 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.
If you don't have a list of "known good" versions you don't know what to
test together, unless you maintain a separate list for each library,
which would require a lot of coordination overhead which a single list
If you say we shouldn't maintain a known good set, then other systems
building on top of this will need to maintain their independent lists
all by themselves, and there's less chance that Zope 2's, Zope 3's and
Grok's list will agree. I think such an agreement is a good idea.
Just because *you* tend to use a few selective libraries for your own
efforts doesn't mean everybody else is. I think we should definitely
support your use case, but not only your use case. A steering group
would be aware of these use cases and balance them.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -