[Zope-dev] the Zope Framework project

[Martin Aspeli]

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 c)
> the people who *aren't* capable of maintaining their own index are mostly using
> 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 
applications.

> 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 from
> 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?

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book