On Saturday 06 October 2007 11:17, Jim Fulton wrote:
> I have some ideas and observations. I don't have decisions at this
> point. We need to make some decisions as a community, with me
> hopefully helping at times to get us unstuck. :)
> - The classic 3.4 release seems to be stalled.
This is actually very sad. Let's take a stab back. The current story that we
have for the outside world is still the same as for Zope 3.3, simply because
we have not released anything else officially yet. That means, people have
the expectation of a Zope 3.4 tar ball.
I think there are two possible solutions to this:
(I) Keep the status quo for one more release.
While the 3.4 release effort has stalled, it is not dead. However, I would
take a different approach this time.
1. Create final 3.4.x releases of all remaining packages. A list of packages
that still have to be packaged can be found here:
2. With the new Zope 3.4 index in place, we can now test the stable set; see
my other post how to do that. The index is at:
3. Once the Zope 3.4 index is stable, a small tool can be used to build a
classic Zope 3.4 tar ball release.
The nice part about this approach is that it requires very little overhead to
what we have to do anyways.
(II) Create a KGS and document the new way
We create a Zope 3.4 index as pointed out above, but instead of releasing a
big tar ball, we write documentation on how to get started with the egg
index. The documentation should have topics like:
- How to get started with buildout.
- How to convert a classic Zope 3 projects to using eggs.
- Using Zope 3.4 eggs without writing your own.
Over the years I have become weary of hoping for people to write
documentation. While I think that we need this sort of documentation badly
and latest for Zope 3.5, I doubt it will happen for 3.4. I would love to be
> - There is a desperate need for a known good configuration of
> components that work well together and that people can build on
> without having to think too hard about the underlying platform.
That's the obvious one. I really hope that the other discussion on KGSs will
gain enough support and a small, smooth workflow that acceptable for
> - There is a need for a mechanism for testing "core" components to
> make sure they don't cause breakage.
Yes, further we learned that the stitched trunk does not serve this need well
enough anymore. Luckily the KGS script I wrote to build an overall
buildout.cfg from the new Zope 3.4 index provides a good testing environment.
(I'll note that several issues with the released packages already surfaced.)
> - We need to decide what Zope 3 is.
I think this is much more difficult.
- I agree, Zope 3 is *not* an application.
- Also, for me, Zope 3 is *not just* a set of components or libraries.
- I like the suggestions of "platform and "environment".
More recently, I was asked to make the case for Zope 3 in very conservative
businesses. I have found that Zope 3 cannot be compared to PHP, RoR and so
on, but competes much more on the level of Java Application Servers, such as
BEA Weblogic and IBM Websphere. In fact, the Java solutions are pretty
similar in to what we have to offer. While we do not have the marketing
behind Zope 3 as the Java guys have, it should not stop us to call Zope 3
an "application server". So that's my entry.
> I think it's time we came up
> with the elevator speech for what Zope 3 is. It should be a few
> sentences at most.
Okay, instead of forming sentences, let me try to come up with a few concepts
that I think are central:
- complete stack of libraries geared towards Web applications
- enterprise-grade technology
- built from experience
- written in Python
- compliant with many standards
- fully customizable due to CA
..  under this buzz-word I mean we provide all the features critically in a
large-scale deployment, such as transaction-safety, scalability, stability
So here is an attempt:
Zope 3 is an enterprise-grade application server written in the Python
programming language. Built on many years of experience, Zope 3's components
implement many technical standards . Thanks to its component architecture, it
empowers the developer to provide custom implementations as desired. Zope 3
is mainly geared towards building Web applications, but can also be used to
built other applications.
Okay, okay, this might sound too much like marketing talk; maybe we should be
> It need not be carved in stone forever, but it
> should be agreed on and used for tactical planning. This should
> probably go hand in hand with the bigger definition of what Zope is
> along the lines of the ideas that Tres expressed at the DZUG in Potsdam.
What are Tres' ideas? I have not been at DZUG, so I have no idea.
> - We need to decide what a Zope 3 release is (or maybe multiple
> flavors). I favor copying the linux experiences, but have an open mind.
I like the Linux parallel as well. I think it would be nice, if we treat the
Zope 3 name like Debian, and Grok or other frameworks on top of it like
Knoppix or other Debian-derived distributions.
> - We need a *realistic* (especially wrt available resources) process
> for managing releases.
Yes. I think one of the fatal mistakes of the eggification process was to
over-estimate the resources available in the Zope community.
I think with KGS we have a means to set realistic goals. Once we have an
initial stable set of releases, we can maintain the Zope 3.4 index as long
as we want to. In the mean time, we will have an unstable index where we can
test new feature releases. Arriving at a new stable index will then be a
matter of (a) creating final releases for all packages in the index and (b)
ensuring that all tests pass.
..  We are not that far away from that. We currently have 32 failures and 6
errors out of 10.3k tests in the Zope 3.4 index.
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
Zope3-dev mailing list