Jim Fulton wrote:
On Oct 7, 2007, at 6:25 AM, Lennart Regebro wrote:
- 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.
Do you have a sort explanation on what is the missing resource? Is it,
as it was for 3.3, lack of people-hours with knowledge in fixing the
I'm not entirely sure. I just observe that this doesn't seem to be
making much progress.
I think it's one of the drawbacks of taking an ecosystem/libraries
approach instead of a application/framework style approach. An
application or framework typically is an integrated whole that has a
single version number. An ecosystem or set of libraries can be
integrated (which Zope 3 is) but everything evolves at different rates
and there's no single thing to install or talk about.
I'm not saying an ecosystem approach is bad, if that's what Zope 3 wants
to be. I do think that such an approach needs to be supplemented by a
framework approach (and I've been putting work into one way to do that).
If Zope 3 is an ecosystem, a "release" of Zope 3 the ecosystem doesn't
really make much sense. To follow the comparison with Linux
distribution, it's more like a "distribution" of an ecosystem. I'd
therefore suggest that the release of Zope 3.4, if it ever actually
happens, will be the last release of Zope 3 the application server
I hope that besides Grok, some community will stand up that takes a less
radical approach to building an application server on top of the Zope 3
ecosystem. People having existing applications in Zope 3 to maintain
(like myself with the Document Library) will have a need for it, and
Grok doesn't suit everyone's tastes anyway, especially people
comfortable with existing Zope 3 practices. As I said elsewhere, I
suggest we call this project not "Zope 3" but something else, to avoid
confusion with the Zope ecosystem (and also to avoid implying it's the
clear successor to Zope 2. I think we can safely say by now that's not
how history went).
Zope3-dev mailing list