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 - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development
signature.asc
Description: Dies ist ein digital signierter Nachrichtenteil
_______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
