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 _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
