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.
> 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
> * 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
> 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.
How will the numbering convention work, currently it is in step with
> 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.
> 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.
> 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.
> having an "extra" designation we can more easily discuss such
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
> 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.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -