[Zope-dev] the Zope Framework project

[Roger Ineichen]

Hi Chris

> Betreff: Re: [Zope-dev] the Zope Framework project
> 
> Martijn Faassen wrote:
> > The Zope Framework project
> > ==========================
> > 
> > :Author: Martijn Faassen
> > :Date: 2009-03-02
> > 
> > Introduction
> > ------------
> > 
> > This document offers suggestions to reorganize our 
> community so we can 
> > act more effectively. It does this by trying to clarify what our 
> > community is about. The document tries to innovate minimally in 
> > concepts and naming in order to provide a relatively small 
> > evolutionary step forward that can still make us all work together 
> > better. Even though this is an evolutionary step, it will 
> still have a 
> > big impact if implemented, so please read on.
> > 
> > This document should be relevant to *all* the parts of our 
> community 
> > that build web applications, whether they use Zope 2, Zope 3, Grok, 
> > Repoze, or applications built on top of these such as Plone 
> or Silva. 
> > While it talks a lot about Zope 3 this is because the Zope 
> technology 
> > within Zope 3 is used within all these projects. The 
> document wants to 
> > recognize this officially.
> > 
> > The main innovations in concepts are the name "Zope Framework" to 
> > distinguish it from the Zope 3 application server and the 
> > "core"/"extra" concept. These are all hopefully 
> descriptions of what 
> > are current practices, simply making them more explicit.
> > 
> > The biggest innovation is the introduction of a Zope Framework 
> > Steering Group as a new entity that will be the steward for the 
> > development of this framework. The steering group's primary 
> aim is to 
> > facilitate developers in the community so that they can continue to 
> > maintain and develop the framework so that it is useful to 
> all of us.
> 
> 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
> effective:
> 
> - encouraging radical change for experimentation purposes, 
> releasing folks from
>   various constraints (backwards compatibility, style 
> policing, historical
>   ownership)

Do you see any benefit not following a style policy?
I think that's the minimum price we have to pay if 
we work in a community. btw, our zope style policy is
defently not very strict and gives most developer enough
room for individual coding style.


> - discourage the contribution of stop energy (discourage
>   the utterances of "don't", "stop", "this is wrong",
>   "stop talking about this").
> 
> - 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.


I'm pretty sure you are not using much zope.* or z3c.* packages
in your projects as dependency.

Your idea is not bad in general, but as a developer which developed
all projects based on zope packages your idea could become a nightmare.

Years ago I convienced Stephan Richter to start with a new namespace
called z3c because we implemented some experimental things like viewlets,
templates, macros, pagelets etc. I think this is what happens with repoze
and grok too. Now I think it's time to merge the good patterns back to
the zope core and replace some old stuff. But we should be carfull with 
break things if possible.

Radical changes and experimental stuff should allways be optional till
it's ready, stable and used by a bigger audience. At least it should be 
very good documented for others which have to update thier projects
if we switch to a new concept.

Regards
Roger Ineichen