--On 2. Oktober 2006 10:24:33 -0700 Christopher Lozinski <lozinski@freerecruiting.com> wrote:

I do like the idea of ZClasses as a separate product.

If we make ZClasses a separate product, does that mean we can get our own mailing list for ZClasses. Maybe a separate web site, wiki, etc?

I doubt that there would be any objections if you want to take over responsibility and ownership over this particular subproject.

Maybe the 4 or 5 companies who care about ZClasses can get together and fund the upgrade.

How much will your company offer? Will you work on getting the funding together?

Open source is good, democratic source would be better.

What does that mean?

I am not trying to upset people with this email message. I just want to present a different point of view.

I am only upset to continuous postings containing a lot of hot air without any kind of outcome. I bring it back the point: you have legitimate interest in ZClasses. Most of the core developers don't have such an interest. It is now *your turn* to do something for ZClasses - either by finding a volunteer to fix outstanding issues or by fundraising to pay a talented ZClasses maintainer. Sorry for repeating myself but I don't see any progress on the ZClasses front. As release manager I want to make clear that I don't want to ship further Zope 2 releases with packages that are in a bad shape and partly broken (I am not talking of packages that are in bad shape but that do work :-)). Andreas

Christopher Lozinski wrote:

I do like the idea of ZClasses as a separate product.

Good! Then let's move it out of the Zope 2 trunk.

Actually I think all of Zope should be an assembly of separate products. I would love to see multiple flavors of Zope each as an assembly of separate products.

If we make ZClasses a separate product, does that mean we can get our own mailing list for ZClasses. Maybe a separate web site, wiki, etc?

Maybe the 4 or 5 companies who care about ZClasses can get together and fund the upgrade.

That'd be great.

Accordingly, this rapid evolution of Zope, to make it compatible with Zope 3 drives a lot of us nuts. We would prefer to just see a stable Zope 2, and an incompatible Zope 3.

If you want a stable Zope 2, take Zope 2.8.x and stick with it (and possibly maintain it). Many other Zope users actually want to use more and more of the Zope 3 Component Architecture and some of its features in Zope 2. So, this evolution is happening "by popular demand", not just because we like driving you nuts. Oh, and by the way, we do try to provide backward-compatibility. The ZClass case really is an (unfortunate) exception. I wish I even knew what the problem was with them (and I get the feeling most of this discussion could've been avoided if someone who cared about ZClasses actually looked into them and provided by some useful info, and that that had perhaps happened a bit earlier than, say, more than 9 months after that problem was introduced).

But I get no say in the matter.

Well, you posted your thoughts on this list. That's what the rest of us do as well. So, I don't see how you "get no say".

Open source is good, democratic source would be better.

We write proposals and we often vote on things. You're welcome to give your input at any time. Incidentally, Zope 2.9 has been out for more than 9 months and now you're raising the ZClass issue... This is something that could've been brought up during the 2.9 beta phase. Why should we even bother with beta releases if they don't get tested???