[Zope3-dev] Zope 3 releases?

[Christian Theune]

Hi,

(sorry for not responding earlier, I've been on vacation last week and
it took me a while to advance through my mail to this thread.)

Am Samstag, den 06.10.2007, 11:17 -0400 schrieb Jim Fulton:
> Recent discussions make it obvious to me that we need to come to  
> terms with Zope 3 releases.

I'm glad you raise this.

> 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 was to be a  
> release modeled on previous Zope 3 releases.  It provides a  
> monolithic Zope 3 application.  I expect that it is stalled because  
> the person who volunteered to see it through overcommitted and, more  
> importantly, it isn't of much practical use, except as a testing  
> platform or as some sort of known good configuration.  The original  
> rational was that we didn't want to be too disruptive in the next  
> release.  I think we've been overtaken by events and a lack of  
> interested resources.

Yup. Both underestimation of the work and overestimation of the amount
of time I have. Mea culpa.

As Stephan pointed out, the release isn't dead. Actually it's pretty
close. We do have a beta release still working with zpkg and we do have
a straight-forward process to get the old tree into shape. See the
resources that Stephan pointed out in his mail with approach 1.

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

I personally prefer a KGS that is updated with a "bugfix/security only"
policy.

> - There is a need for a mechanism for testing "core" components to  
> make sure they don't cause breakage.

Right. If I read my mail correctly Stephan has a tool to do that from a
KGS (or: index page).

> - We need to decide what Zope 3 is.  Zope 3 is *not* an application.  
> I think there is fairly broad agreement on that.  I can think of  
> several words that could be used to describe what it *is*, like  
> "platform", "environment", "ecosystem".  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.  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.

My thinking goes similar (but maybe a little different) to others. Here
some input from my perspective:

- There is a "Zope" project which develops software, tools and practices
  that allows me to write web applications in a technically clean and
  high-quality way (aka Doing the right thing (tm)). This can be
  identified with the foundation.

- One output of the Zope project is the component architecture and
  specific components that are developed.

- An application server is a technology/tool. The Zope project currently
  has multiple implementations of this (containers that start Python
  applications in which I can let my Zope applications run). They are at
  least called "Zope 2", "Zope 3". It might be argued that "Zope 3" is
  just the a release of the application servers implemented
  "zope.app.server" and "zope.app.twisted". I value that Zope gives me
  the components and the actual process container in which to run in. 

> - 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 think we should explicitly state who the audience of the release is. 

If I'm the audience, then a release of Zope 3 is a KGS + security
updates. (With the ability of mine to override the KGS's choices if I
have reason to and know what I'm doing.)

> - We need a *realistic* (especially wrt available resources) process  
> for managing releases.  There are 2 aspects of this.  We shouldn't  
> make plans for which there aren't enough resources.  We also  
> shouldn't plan significant tasks that people won't care enough to  
> work on.  I think the classic Zope 3.4 release is a good example of a  
> large effort that really wouldn't benefit many people, if any.

I agree on both aspects.

Christian

-- 
gocept gmbh & co. kg - forsterstrasse 29 - 06112 halle/saale - germany
www.gocept.com - ct at gocept.com - phone +49 345 122 9889 7 -
fax +49 345 122 9889 1 - zope and plone consulting and development

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Dies ist ein digital signierter Nachrichtenteil
Url : http://mail.zope.org/pipermail/zope3-dev/attachments/20071011/d5cbae01/attachment.bin