[Zope-dev] the Zope Framework project

[Matthew Wilkes]

On 2 Mar 2009, at 16:33, Martijn Faassen wrote:

> What is the Zope project? The Zope project is an umbrella project for
> a number of sub-projects. Its source code is in a repository managed
> by the Zope Foundation. Within the Zope project, there are a number of
> projects that ship full-stack web frameworks (or application servers):

One of the most striking things about the Zope community (imho) is  
that we don't have a single central presence.  There's no Zope  
conference, people go to PyCon, EuroPython, PloneConf, etc, they hang  
out in different irc channels (personally I discuss Zope in #plone,  
#zope, #zope.de, #plone-framework and #repoze), and this mailing list  
isn't widely read.  Yeah, the people are mostly the same, and you know  
a Zopista from people outside the community, but there doesn't feel  
like there's a central community.  I couldn't tell you what the Zope  
Foundation does, for example.

> To distinguish between these two perspectives on Zope 3, we will
> introduce a new term: "the Zope Framework". "Zope 3" should be used to
> indicate the Zope 3 application server that is one consumer of these
> libraries. To be explicit we encourage the use of "Zope 3 application
> server" to indicate Zope 3 and discourage the use of "Zope 3" to
> indicate the Zope Framework itself.

+1

> The Zope Framework has a central status within the wider Zope
> project. It is the core Zope technology ingredient to Zope projects
> such as Zope 2, Zope 3 and Grok.

With it's own IRC channel and mailing lists, that become the canonical  
place for questions about the ZCA, etc?

Either way, +1

> A library that at some point in time is considered to be part of the
> Zope Framework is called a "core library". The Zope Framework contains
> those libraries that are reused by a large number of projects, or that
> the Zope Framework developers want to promote to be being more widely
> adopted. The Zope Framework developers especially favor inclusions of
> libraries that are used by other Zope projects.

+1 on everything but the "want to promote" bit - the libraries will be  
decided by the same developers they'd be promoted to.  I'm -1 on  
framework bloat to help spread libraries.  If a package is truly  
useful as part of the framework it goes in, if it's just cool I don't  
think it should.

> The set of libraries that is "core" can change over time depending on
> how these libraries evolve and are used. New libraries considered to
> be "core" can be added to the set, and existing libraries once
> considered "core" can be removed from the set.  We should be careful
> though, as we cannot just drop libraries from the core without
> considerable thought. A library being in the core signals a level of
> commitment to this library.

Meh, ish.  I think if we make it clear enough in advance we should be  
fine.  If a non-core library is widely used compatibility will have to  
be maintained, but it doesn't mean we should keep it in core if it  
doesn't deserve it.

> * if it has a lot of people who contribute to it from our community,
>   it's likely core.

-1, it's a zope community package, but not necessarily part of our  
framework.

> * if it's something we want to encourage more consumer platforms use,
>   it's likely core.

-1, as stated above.

> Which libraries should be core to start with? Proposed is to take the
> ``zope.*`` libraries. We can immediately weed out a lot of libraries
> that aren't considered core, and we can then start the slower
> processes of adding and removing from that set over time.

zope.* is a good start, but I think it'd be more useful to look at  
what packages are actually used by everyone that's considered to be a  
framework user.

> Libraries may have a different status in the core to convey extra
> information about them, such as deprecation status.

How will this be signalled?

> As a service to the users of the Zope Framework, the Zope developers
> also make available lists of version numbers of core libraries that
> have been tested to work together as a "Known Good Set". This receives
> a version number and is the Zope Framework release.

+1

How will the numbering convention work, currently it is in step with  
Zope3-the-application-server.

> Currently intermixed with the Zope Framework core there is code that
> implements a particular user interface, the Zope 3 ZMI. There is a
> consensus that these application-like parts should be removed from the
> core set, as that code typically only sees use by a single consumer
> (the Zope 3 application server). It is not used by other consumers of
> the framework.

+1

> Examples of "extra" libraries are the "hurry.query" library for
> constructing catalog queries, the "z3c.form" related libraries for
> form generation, and the "grokcore.component" library which contains a
> different way to configure components.

Sounds sensible.

> Any library that is developed for integration with the Zope Framework
> in the Zope repository can be considered "extra"; "extra" is the set
> of libraries that is not in the Zope Framework but can work with it.  
> By
> having an "extra" designation we can more easily discuss such  
> libraries.

What about other dependencies?  Should we have a list of blacklist  
packages/things that prevent something being called an extra?  What if  
it only works with 1 user of the framework, or 2, or all but 1, where  
do we draw the line?

> The Zope Framework Steering Group is there to provide leadership for
> the development of the Zope Framework. The Zope Framework Steering
> Group consists of a small number of developers. The Steering Group
> takes on the task to represent the interests of the consumers of the
> Zope Framework. The Steering Group searches for consensus in the
> community of users and contributors and thereby guide the evolution of
> the Zope Framework.

+1, I think they should be pretty hands-off, but I think it'd be  
valuable to the community to have people who feel responsible for  
pushing Zope forward.

> It also resolves deadlocks: in
> case of disagreements within the community about particular
> development decisions, the Steering Group can make a decision based on
> what it believes is in the best interest of the current and future
> users of the Zope Framework.

How is the steering group selected?  How long do they serve for?  All  
these questions need to be answered in a way that everyone considers  
fair for this to work.

> The Steering Group is
> there to act as a catalyst for the community, enabling cooperation,
> helping to make good decisions, to have a positive atmosphere, and so
> on.

Hear, hear!

> In order to
> determine who is in it we could devise an election procedure by Zope
> Foundation members.

-1, I'm not sure the foundation membership is representative of the  
users.  I'd say people put themselves up for election, there is a  
secret public vote, the foundation review the results and then appoint  
people.  That way they can overrule the public but are informed by them.

>

Matt