Philipp von Weitershausen wrote:
> Fair enough. It seems to several people, though, that explaining to
> people how Python packages are installed and then how you hook up these
> packages into your instances is easier than explaining all the magic
> that revolves around Products to them. Because in the end you won't have
> to explain how to install Python packages at all because it's the same
> all the time...

Indeed, its time for Zope developers to think less like zope developers
and think more like python developers :)

>>How urgent is it that all of this works with Zope 2.8? I guess it's
>>urgent if you want to sell it to the Plone community, which will only
>>switch to Zope 2.9 or beyond by next year or so, I expect. How much more
>>often is this kind of thing therefore going to happen?
> Given Plone hasn't adopted time-based releases yet, I'm not sure. AFAIK
> they want time-based releases, 6 months apart like Zope. Just yesterday
> I suggested they make them 3 months off to the Zope releases. That way
> they can keep on track with Zope releases and not lag behind all the time.

My understanding is that Plone 2.1 -> 2.5 was meant to be the first time
based release.  But Alec Mitchel would have to answer that one, being
the release manager.  I do support sync'ing these plone 6 month release
cycles with zope's releases (being 3 months off) and I think I heard a
few plone people second the sentiment.

>>You can turn that around; for consistency of installation experience in
>>Zope 2.8, it's important that people don't get a new way of installing
>>products, confusing innocent individuals installing Zope software. For
>>the "cutting edge", Zope 2.9, that argument is slightly different.

Well, any non-familiar zope2 sys admin who's installed plugins has
almost certainly had to install python code in site-packages as well.
Telling them "oh, you can just stick this on site-packages as well, or
put it in INSTANCE_HOME/lib/python if you need different versions with
different zope instances" I think won't confuse innocent individuals.

>>I want to identify the reasons why it is so important that this change
>>happens with Zope 2.8. The main reason I can identify is Plone, correct?

Single biggest reason is so that people developing products within the
next 6-12 months can develop using this new style.  Of course we can say
that as a consultant we just require our clients to upgrade to Zope 2.9,
but the reality is we all have plenty of clients who won't be able or
willing to make the upgrade from Zope 2.8 to 2.9 especially with the
leap of going from py2.3 to py2.4.

This has the biggest bearing on Plone because even though Plone 2.5 will
support zope 2.8 and 2.9 both (I actually tried to convince them to drop
support for 2.8, but that didn't work out), the majority will use zope
2.8 -- based on experience with Plone 2.1 supporting Zope 2.7 and 2.8
where most Plone 2.1 installs still seem to use Zope 2.7.

I'm not a great debater by any means so I'll finish this with one more
reason as to why and make Zope 2.8 support this functionality -- because
it will make my life a great deal easier :)

- Rocky

Rocky Burt
ServerZen Software --
ServerZen Hosting --
News About The Server --

Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to