Chris McDonough wrote:
> Sure. We can be careful, grown-up, conservative, and all that. But I'll note
> that a) there just really aren't that many people using Zope 3 b) the people
> that *are* using Zope 3 by itself are capable of maintaining their own index
> the people who *aren't* capable of maintaining their own index are mostly
> Zope 2, and that means they're using Zope 3.4 which doesn't really need to
> change and
I'm not sure this is all true:
a) Relative to what? I agree it's not a huge community, of course.
Still, we're bigger than a lot of other open source projects out there.
b) I don't think we can generally assume that. If we do that, then the
answer to a) is certainly going to shrink even further. And even those
who could (me, for instance), may not want to (me again)
c) The Zope 2 and Zope 3/framework release schedules are being
co-ordinated. Zope 2.12 will have a KGS of packages aligned with the
Zope 3.5 release. I hope that Zope 2.13 or whatever will be able to use
a new stable platform of known-to-work-well-together Zope packages,
whether you call that Zope 3.6 or not. The ongoing work to refactor
dependencies will both make this easier and more important, as getting
any old version pulled form PyPI could cause a lot of headaches. Chasing
dependencies is about as much fun as a hole in the head.
I think there's a market for a somewhat "boring and grown up" Zope
release that cares about backwards compatibility and stability. There's
also a market for more radical things. With eggs and individual
releases, we have the ability to mix and match between the two in our
> c) the time for careful, measured effort was over three years ago.
> IMO, to stay relevant, Zope needs a total overhaul.
This may be true, but it's not terribly constructive because it's so
non-specific. I don't think Martijn's proposal will stop people from
doing more radical things. It wouldn't have stopped you doing repoze.bfg
for example. If anything, it may have resulted in a situation where you
had someone to talk to about that refactoring that may be able to act
and steer Zope development so as to be better aligned with BFG.
You and I had a discussion a while back about forking the zope.component
ZCML directives, and how it would've been better to work within the
boundaries of the Zope packages so that everyone who wanted to lose the
zope.security dependency could benefit, rather than fork this and all
other configuration that depends on the core ZCML directives. The main
reason you had for creating your own package, was the lack of momentum
(and/or stop energy) encountered when trying to do this in the Zope
world. If there was someone who could both consider BFG's needs in a
more objective light, and have the power to actually do something rather
than just bicker, then maybe we could've gone a different route on that
one. With more and more dependency untangling happening, I am pretty
sure this same situation is going to come up again.
> Martijn's original message was about "being effective". It's hard to be
> effective without being relevant. To gather support and development effort
> new people, things need to change drastically.
I think things are already changing drastically, even if that happens
more in the repoze.* and grok.* namespaces rather than in the zope.*
namespaces. I'm really excited to see the amount of TurboGears activity
on the repoze-devel list, for example. We need more of that. A steering
group that may be able to recognise that doing this is in Zope's
interest, and actively act on it, would be a way to make that happen.
Without some kind of leadership, it sure as hell *isn't* going to happen.
And don't assume there's no desire. Just today, Jim asked whether we
should consider using the WebOb request types. That's a pretty radical
change in the direction of relevancy to others, wouldn't you agree?
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -