Re: Zope 3 releases?

--===============2108014969==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature";
	boundary="=-D4AfnWbO2oVbYS50LulK"


--=-D4AfnWbO2oVbYS50LulK
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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 =20
> terms with Zope 3 releases.

I'm glad you raise this.

> I have some ideas and observations.  I don't have decisions at this =20
> point.  We need to make some decisions as a community, with me =20
> hopefully helping at times to get us unstuck. :)

:)

> - The classic 3.4 release seems to be stalled.  This was to be a =20
> release modeled on previous Zope 3 releases.  It provides a =20
> monolithic Zope 3 application.  I expect that it is stalled because =20
> the person who volunteered to see it through overcommitted and, more =20
> importantly, it isn't of much practical use, except as a testing =20
> platform or as some sort of known good configuration.  The original =20
> rational was that we didn't want to be too disruptive in the next =20
> release.  I think we've been overtaken by events and a lack of =20
> 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 =20
> components that work well together and that people can build on =20
> 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 =20
> 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. =20
> I think there is fairly broad agreement on that.  I can think of =20
> several words that could be used to describe what it *is*, like =20
> "platform", "environment", "ecosystem".  I think it's time we came up =20
> with the elevator speech for what Zope 3 is.  It should be a few =20
> sentences at most.  It need not be carved in stone forever, but it =20
> should be agreed on and used for tactical planning.  This should =20
> probably go hand in hand with the bigger definition of what Zope is =20
> 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.=20

> - We need to decide what a Zope 3 release is (or maybe multiple =20
> 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.=20

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 =20
> for managing releases.  There are 2 aspects of this.  We shouldn't =20
> make plans for which there aren't enough resources.  We also =20
> shouldn't plan significant tasks that people won't care enough to =20
> work on.  I think the classic Zope 3.4 release is a good example of a =20
> large effort that really wouldn't benefit many people, if any.

I agree on both aspects.

Christian

--=20
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


--=-D4AfnWbO2oVbYS50LulK
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: Dies ist ein digital signierter Nachrichtenteil

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBHDjZKdUt9X/gknwIRAg1UAJ0QohshXNmCyEdy1byg27yKcQ3HjwCgnIVQ
xJnkpC75goAxpLatjFJ0fsI=
=BCxR
-----END PGP SIGNATURE-----

--=-D4AfnWbO2oVbYS50LulK--


--===============2108014969==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline