--On 14. Juni 2006 06:47:37 -0400 Chris McDonough <[EMAIL PROTECTED]> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Warning: This is gonna be ranty and will almost certainly contain foul language. ;-)
You're allowed to do so :-)
There was a message sent to the list about deprecating zLOG on January 8 of this year by Andreas, but it was supposed to have been deprecated in 2.10, not any 2.9 release, and was supposed to have gone away in 2.12, not in 2.11, as the currently 2.9 deprecation warnings for zLOG state. And why the should the core emit a deprecation warning? If the core uses it, it by definition shouldn't (*can't*) be deprecated. What's the goal here? Removing zLOG is (at least by any sane measure) totally gratuitous in the first place, we have conflicting reports about which version it's going to be deprecated in, and it's not even actually deprecated! This is the definition of a clusterfuck.
Some comments in the zLOG module stated that it was intended to deprecatezLOG in Zope 2.8 afaik (not checking the sources right now). So I deprecated it in Zope 2.9 (without migrating all occurrences (mea culpa)...a cosmetic problem in my opinion) and it is now removed for Zope 2.11..
Yes, I know. I should have spoken up earlier about zLOG. But to be honest I'm just barely keeping my head above water as it is, so I'm hoping to be able to trust that people make wise decisions about this sort of thing, and my main defense mechanism at this point is limited to covering my eyes and hoping everything will turn out ok. I'm hoping that people won't removing some random API for the sake of a hard-on over a Platonic ideal. Is that unreasonable?
At least on the module level we did not remove something without a proper replacement.
So, anyway, I have a really significant number of released products that make use of zLOG. I can't keep up with the release cycle, or the deprecations. These products will likely just be broken for new Zope releases and will emit warning messages for stable branches for some period of time. People are gonna be pissed. But there's not much I can do about it short of just giving up maintainership of those products to someone who is able and willing to keep up. There's only like, what, maybe 20 people who have demonstrated willingness to maintain the *core*, so it's a pretty fat chance of me finding one of those people to maintain my stuff.
At some point you have to make a cut to get rid of old crap. Fixing the zLOGissue is a straight forward approach with very little risks for the programmer and it won't take too much time..I don't see a major problem with that.
There *have* to be other people in the same boat as I am. Speak up if so! Zope 2 is really just not the place to make sweeping innovations. We are losing working products as a result of these "innovations", and as a result, probably developers, and as a result of that, end users. In general we are being *way*, *way*, *way* too aggressive about deprecations and API changes in Zope 2. Sometimes you just need to live with your mistakes. I'd hope that people will try to be conservative in the future.
I agree almost with everything of that. However being conservative should not avoid making progress. This still raises the question: where shall be go with Zope 2. My theory is that Zope 3 will be the spare-part factory for Zope2 (please no beatings from the Zope 3 world :-)) and that Zope 2 will have a long life. This implies that we need to adopt more and more Z3 technology. Such integration will raise deprecation issue and possible...and it is our goal to minimize these issues. ...but that's only my personal theory.
Andreas
pgpSJ3RHCrZVv.pgp
Description: PGP signature
_______________________________________________ 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 )
