--On 14. Juni 2006 06:47:37 -0400 Chris McDonough <[EMAIL PROTECTED]> wrote:

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 deprecate
zLOG 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 zLOG
issue 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.


Attachment: pgpSJ3RHCrZVv.pgp
Description: PGP signature

Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to