[Zope3-dev] Zope 3 releases?

[Stephan Richter]

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. :)

I agree.

> - 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: 

http://wiki.zope.org/zope3/StabilizeEggPackages

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:

http://download.zope.org/zope3.4/

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 
prooven wrong!!

> - 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 
everyone.

> - 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[1] technology
- built from experience
- written in Python
- compliant with many standards
- fully customizable due to CA

.. [1] under this buzz-word I mean we provide all the features critically in a 
large-scale deployment, such as transaction-safety, scalability, stability 
(tests), etc.

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 
more technical?

> 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[2], 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.

.. [2] 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.

Regards,
Stephan
-- 
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training