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 _______________________________________________ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
