Re: [Zope-dev] Re: OFS.Application deprecations for Zope 2.10
Chris McDonough wrote: So be it. This is really minor. Not deprecating it is the right thing, and I won't even qualify that with a IMO ;-) +1 Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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 )
[Zope-dev] Time-based releases a good idea?
Florent Guillaume wrote: Yes but the deprecation has been there for a while, and the third party product developers have been ignoring the warning. Their loss. And this is only for Zope 2.10 which I doubt these third party products are using at the moment. If we don't remove things at some point, there's no point in doing deprecation warnings. This and things like it have been niggling me for a while now and I guess this finally prompted me to write a mail on it... I know the good reasoning behind the time-based releases, but have they really worked out? As someone else who never has enough time to keep up with releases I've found the introduction of time-based releases a generally negative thing. I don't say that lightly, they certainly sounded like a great idea when they were introduced but I've experienced more bugs, a helluva lot more pointless deprecation squeal and a lot more upgrade fear since this process was introduced. For me, the fact that Zope 2.9.3 still emits deprecation warnings on a fresh install (zLOG...) is a pretty bad sign. I dunno, it just feels like features are being rammed in and a _lot_ of stuff is being deprecated, sometimes without as much thought as should be given. Change for change's sake is never a good thing. As a result, I'm still mainly on a mix of Zope 2.7 and 2.8, and finally taking timid steps to 2.9 for some projects, all of which have required new versions of just about every add-on product. Now, this could all be seen as fair game, Zope _is_ going through a period of big and positive change as Zope 2 and Zope 3 converge, things like zLOG finally get put to rest and we move onto newer more powerful versions of python. If that's the case, then I hope we, as a community, get there at some point and can get back to focusing on the stability of the good ol' days. Would be interested to know what other people think... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ 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 )
Re: [Zope-dev] Time-based releases a good idea?
--On 14. Juni 2006 07:32:42 +0100 Chris Withers [EMAIL PROTECTED] wrote: Florent Guillaume wrote: Yes but the deprecation has been there for a while, and the third party product developers have been ignoring the warning. Their loss. And this is only for Zope 2.10 which I doubt these third party products are using at the moment. If we don't remove things at some point, there's no point in doing deprecation warnings. This and things like it have been niggling me for a while now and I guess this finally prompted me to write a mail on it... I know the good reasoning behind the time-based releases, but have they really worked out? Yes and No. Yes: It's a must to have Zope 2 and Zope 3 in sync. Zope 2 development got a some more momentum again.. No: Half a yr is a short time. Major changes happened right short before the first beta release. Not all Zope users won't follow this fast release cycle. For me, the fact that Zope 2.9.3 still emits deprecation warnings on a fresh install (zLOG...) is a pretty bad sign. Deprecation warning is only annoying but not a bad sign. Deprecations are not a functional problem. Now, this could all be seen as fair game, Zope _is_ going through a period of big and positive change as Zope 2 and Zope 3 converge, things like zLOG finally get put to rest and we move onto newer more powerful versions of python. right...I did not think that we deprecated and removed something without having a reasonable replacement...or did we? If that's the case, then I hope we, as a community, get there at some point and can get back to focusing on the stability of the good ol' days. +1, +1, +1 Andreas PS @all developers: I hope you don't forget the bugday tomorrow :-)) pgpcyrA2gyahB.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 )
Re: [Zope-dev] Time-based releases a good idea?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 14 Jun 2006, at 09:44, Andreas Jung wrote: --On 14. Juni 2006 07:32:42 +0100 Chris Withers [EMAIL PROTECTED] wrote: I know the good reasoning behind the time-based releases, but have they really worked out? Yes and No. Yes: It's a must to have Zope 2 and Zope 3 in sync. Zope 2 development got a some more momentum again.. No: Half a yr is a short time. Major changes happened right short before the first beta release. Not all Zope users won't follow this fast release cycle. Yes, the 6 month cycle is very short. All of a sudden we have a situation where a whole slew of releases/branches is out there (2.7, 2.8, 2.9, 2.10, trunk) and I bet *no one* can say what's really supposed to be supported and what isn't. And if someone fixes a bug and wants to do the right thing by fixing it everywhere the effort keeps on growing. I think the 6 month number was picked as a good first guess how best to handle the new release process, and IMHO we should look at that again and adjust it. For me, the fact that Zope 2.9.3 still emits deprecation warnings on a fresh install (zLOG...) is a pretty bad sign. I think this is a dead horse now. Some things were deprecated without actually converting all instances where the deprecated code was in use. It's in your power to do something about it, go ahead. jens -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFEj8idRAx5nvEhZLIRAjkEAJ4jP+C8Xus66FRbX5MNaoDPIIg7AwCguNYQ AyHinqF1uQnBQgmli2o4ANc= =r7+N -END 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 )
Re: [Zope-dev] Time-based releases a good idea?
--On 14. Juni 2006 10:28:08 +0200 Jens Vagelpohl [EMAIL PROTECTED] wrote: For me, the fact that Zope 2.9.3 still emits deprecation warnings on a fresh install (zLOG...) is a pretty bad sign. I think this is a dead horse now. Some things were deprecated without actually converting all instances where the deprecated code was in use. It's in your power to do something about it, go ahead. Right. As a rule we must fix any code in the Zope core that would possibly spit out a deprecation warning caused by a deprecation warning. At least for zLOG in Zope 2.9 we (possibly only me) were not totally consequent. -aj pgprTUTFQzyDu.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 )
Re: [Zope-dev] Time-based releases a good idea?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Warning: This is gonna be ranty and will almost certainly contain foul language. ;-) I've never actually seen a deprecation warning emitted for zLOG. And I'm about as in the loop as anybody could expect someone to be, but I've not actually worked on the core for maybe six months. This is because I've been trying to ship a long-term customer project, which we've settled on 2.8 for, and I haven't been keeping a close eye on the checkins list. Yes, I know. I know. I'm bad. But all of you have been there before, I'm pretty sure, so I hope you can sympathize. 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. 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? 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. The time-based release cycle just amplifies this across many branches and point releases, so nobody really knows which products work with what branch/release and under what configuration some feature is supposed to emit a deprecation warning without a good deal of testing. The *reason* I'm stuck back on 2.8 and haven't upgraded the products I maintain to behave nicely on 2.9+ is because I just can't keep the fuck up with these sorts of changes. It's a self- perpetuating cycle because the only sane defensive maneuver for me is to stick with 2.8 for existing customer projects. I say to myself that I'll move them to 2.9 or 2.10, or 2.11, or whatever happens to be the current release once I get a chance to breathe, but honestly, this is the *last* thing I'll do; I've got plenty of other coding to do. 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. For my part, I'll try to be more in the loop on that sort of stuff on the maillist and try to call bullshit more often and more on-time (mea culpa on that). - - C On Jun 14, 2006, at 4:39 AM, Andreas Jung wrote: --On 14. Juni 2006 10:28:08 +0200 Jens Vagelpohl [EMAIL PROTECTED] wrote: For me, the fact that Zope 2.9.3 still emits deprecation warnings on a fresh install (zLOG...) is a pretty bad sign. I think this is a dead horse now. Some things were deprecated without actually converting all instances where the deprecated code was in use. It's in your power to do something about it, go ahead. Right. As a rule we must fix any code in the Zope core that would possibly spit out a deprecation warning caused by a deprecation warning. At least for zLOG in Zope 2.9 we (possibly only me) were not totally consequent. -aj___ 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
Re: [Zope-dev] Time-based releases a good idea?
On 6/14/06, Chris McDonough [EMAIL PROTECTED] wrote: The time-based release cycle just amplifies this across many branches and point releases, so nobody really knows which products work with what branch/release and under what configuration some feature is supposed to emit a deprecation warning without a good deal of testing. The *reason* I'm stuck back on 2.8 and haven't upgraded the products I maintain to behave nicely on 2.9+ is because I just can't keep the fuck up with these sorts of changes. It's a self- perpetuating cycle because the only sane defensive maneuver for me is to stick with 2.8 for existing customer projects. I say to myself that I'll move them to 2.9 or 2.10, or 2.11, or whatever happens to be the current release once I get a chance to breathe, but honestly, this is the *last* thing I'll do; I've got plenty of other coding to do. Well, ignoring the confusion about zLOG, updating things for a new version of Zope with deprecation warnings is not much work. Honestly. You update to the new version, look at the depracation warnings, and do search/replace until they go away. Unless their are compatibility bugs, and that will happen sometimes, that's it. I don't remember exactly how long it took to go to 2.9 for CPS, but it wasn't very much work, and it was all related to changes in Five, which you don't seem to use or worry about. 2.10 seems to have been even less, excepting two bugs in the 2.10 beta. And we do this move for CPS during the beta phase, which one typically shouldn't do. Normally you should get rid of the 2.9 deprecation warnings when you no longer want to support 2.8. Whi typically would be right about after 2.10 is released and 2.8 no longer is officially maintained. If you get rid of all deprecation warnings for 2.10 now, your software may very well stop working on 2.9. ;) Admittedly, now when I think about it, this assumes you have tests for the products that have reasonable coverage. If you don't it's much worse, because you have to test the whole product manually to get rid of all warnings. When you have tests, you are 99% sure things are fine once the warnings are gone. There *have* to be other people in the same boat as I am. Yeah, I was in the same boat with EasyPublisher, when Zope moved from python 1.5.2 to python 2.something. EasyPublisher stopped working. We felt stressed, and did not switch Zope version for a while, staying on, I think, 2.3, while everybody else went to 2.5. Remember, there was no real deprecation period then, each major version would simply have a set of incompatibilities. The result was that the longer we waited we had more and more Zope 2.3 bugs to work around, and while 3rd party products increased in version we had to use old versions because we were on an old zope version. So the longer we waited, the greater became not only the upgrade work, but the work of circumventing bugs and misfeatures in the old software. When I finally DID switch, it still was only a couple of days work, and it solved several of our problems. The changes was done for a reason, mostly. We *should* have kept up to date continously. It would have been less work for us. Zope 2 is really just not the place to make sweeping innovations. You are welcome to stay on 2.8 forever if you want. Or 2.7 for that matter, it doesn't include Five and so has a much smaller tgz. ;) I think alot has been done wrong when it comes to how the innovation known as Zope3 has been handled. But I don't think making those innovations available to Zope2 is a mistake. I also don't think it's a mistake to get rid of the amazing code-duplication that Zope2 and Zope3 together holds. Almost the only component that is not duplicated is the ZODB. Why should we have two publishers to maintain? And two webservers with two WebDav implementations and two of everything else? The majority has agreed that the path forward for Zope is to make it possible for people to use Zope3 technologies without having to rewrite everything from scratch. The changes you see in Zope2 are a direct effect of that. You should only get upgrade problems if you skip several versions. Other than that, it should pretty much just work. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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 )
[Zope-dev] Re: Time-based releases a good idea?
Andreas Jung wrote: 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. Except that it hits a sore spot for open source right on the head. Products are developed for our customers, and they will keep working for those customers until they choose to upgrade. In my case, a single product often starts out as a tool for a single customer, that I then make available. Usually I get a lot of (unreasonable) change request that I ignore :-s, but no bug fixes at all. That is fair enough, as I don't fix many bugs in other peoples products. But the problem is that I don't fix bugs that doesn't exist for my customers. So deprecation warnings are ignored, until the product sponsor chooses upgrade. If this is how OSS generally works, as I expect, then deprecations will break stuff that just doesn't get fixed. And new user will find it impossible to get all the products they need to work together, in the latest version. But the problem is probably not the time based release, just that there is to few generations for deprecations. -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science Phone: +45 66 11 84 94 Mobile: +45 29 93 42 96 ___ 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 )
[Zope-dev] Re: Time-based releases a good idea?
On Wed, 2006-14-06 at 13:34 +0200, Lennart Regebro wrote: The majority has agreed that the path forward for Zope is to make it possible for people to use Zope3 technologies without having to rewrite everything from scratch. The changes you see in Zope2 are a direct effect of that. You should only get upgrade problems if you skip several versions. Other than that, it should pretty much just work. I'd just like to add that I agree with all points in this post. Plone is also in a very similar situation and it was quite minimal work getting from 2.8 to 2.9 and now to 2.10. The result is that Plone is now using more and more component architecture functionality which is making certain area's easier to maintain and is currently making things more fun to code :) As well, the switch to zope 3 technologies is enabling us reuse more zope tech so we have to develop less plone tech which is always a good thing. - Rocky -- Rocky Burt ServerZen Software -- http://www.serverzen.com News About The Server (blog) -- http://www.serverzen.net signature.asc Description: This is a digitally signed message part ___ 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 )
Re: [Zope-dev] Time-based releases a good idea?
On Wed, 2006-06-14 at 13:34 +0200, Lennart Regebro wrote: On 6/14/06, Chris McDonough [EMAIL PROTECTED] wrote: Well, ignoring the confusion about zLOG, updating things for a new version of Zope with deprecation warnings is not much work. Honestly. You update to the new version, look at the depracation warnings, and do search/replace until they go away. I realize it's easy to forget, because I'm clearly no genius, but I do write Zope software for a living, so updating to new versions of things is something I've dealt with in the past. I don't remember exactly how long it took to go to 2.9 for CPS, but it wasn't very much work, and it was all related to changes in Five, which you don't seem to use or worry about. Oh, geez. I maintain a large Five-using product. It may be one of the largest in existence (which is not meant as bragging, it's just probably true). It's currently 31,000 lines of Python, most of which is in browser views, another 12,000 lines of ZPT, and about 3000 lines of SQL. Therefore, I do have a stake in reasonably-recent Zope releases. There are others like me who maintain large 3rd-party code bases that actually depend on this stuff who aren't actively involved in the development of all of the pieces of the framework. These sorts of people just can't afford to upgrade in lockstep with the various current release cycles. These are the people I'd like to avoid pissing off. FWIW, I can actually deal with the churn, I'm not going anywhere anytime soon, but I can imagine not sticking around and ditching Zope for something more stable if I were less involved. Admittedly, now when I think about it, this assumes you have tests for the products that have reasonable coverage. If you don't it's much worse, because you have to test the whole product manually to get rid of all warnings. When you have tests, you are 99% sure things are fine once the warnings are gone. The product I speak of above has 700 individual unit tests and still has bugs. Shrug. I expect some breakage, and the tests will catch most of them, and that's fine. But I also have maybe five or six open source products that I maintain which don't see attention every week or even every month or sometimes every six months, because I'm working on other stuff. These are problematic for me to keep in sync, which causes problems for other folks. When I finally DID switch, it still was only a couple of days work, and it solved several of our problems. The changes was done for a reason, mostly. We *should* have kept up to date continously. It would have been less work for us. But really, in honest-to-god reality, you probably couldn't have while simultaneously serving your customers' immediate best interests. That's of course a subjective judgment, but at least think it over a little before saying you could have. Zope 2 is really just not the place to make sweeping innovations. You are welcome to stay on 2.8 forever if you want. Or 2.7 for that matter, it doesn't include Five and so has a much smaller tgz. ;) Thanks for giving me your permission to do that. I think alot has been done wrong when it comes to how the innovation known as Zope3 has been handled. But I don't think making those innovations available to Zope2 is a mistake. Me neither. None of what I'm talking about has yet been related to Five. The two things that have brought this up in my mind so far have been the deprecation of 'methods' in __init__.py and the zLOG clusterfuck. Those things have nothing to do with Five or Zope 3. I also don't think it's a mistake to get rid of the amazing code-duplication that Zope2 and Zope3 together holds. Almost the only component that is not duplicated is the ZODB. Why should we have two publishers to maintain? And two webservers with two WebDav implementations and two of everything else? One good reason: because the old one works and hundreds if not thousands, if not tens of thousands already use it, and there is *no immediate benefit* for them to switch to something different. The majority has agreed that the path forward for Zope is to make it possible for people to use Zope3 technologies without having to rewrite everything from scratch. The majority has been pretty sheltered so far, IMO. I'm still struggling to explain the concept of *Python scripts* to some of my customers. The changes you see in Zope2 are a direct effect of that. You should only get upgrade problems if you skip several versions. Other than that, it should pretty much just work. So don't worry about it is your opinion? I don't think that's a reasonable position. But then again, what do I know, I'm only a dumb end user I suppose. And who wants all those pesky end users anyway? - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists -
Re: [Zope-dev] Re: Time-based releases a good idea?
On 6/14/06, Max M [EMAIL PROTECTED] wrote: But the problem is that I don't fix bugs that doesn't exist for my customers. So deprecation warnings are ignored, until the product sponsor chooses upgrade. Very reasonable. If this is how OSS generally works, as I expect, then deprecations will break stuff that just doesn't get fixed. I'm not sure I follow you here. Deprecations in themselves break nothing, of course, so I assume you mean that the changes break stuff that doesn't get updated. This is true, but that is true for any non-backwards-compatible change. And every single major Zope version have had some sort of non-backwards-compatible change. That is, in fact, the whole definition of the major version. Otherwise it would be a bugfix. :) And new user will find it impossible to get all the products they need to work together, in the latest version. This is true, and a problem. And the more modules you have the worse it gets, as you get big compatibility matrices going on. But there is only one answer to that, and that is to update the software. It doens't mean *you* have to do so. But somebody has, reasonably whoever needs the update. That's OSS. :) Things get REALLY complex if you try to keep several version bugfree at the same time, which I guess is one of the reasons Chris stays on 2.8 so far. He doesn't want to have two branches, one 2.8 and one 2.9 compatible, and keep them both bugfree. This is very reasonable, and the reason for the deprecation period. The deprecation period gives you, in effect, 18 months notice. After 18 months, in the worst case, the feature you used is not any longer in any supported version of Zope. I think that's very reasonable. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
On Wed, 2006-06-14 at 14:09 +0200, Wichert Akkerman wrote: No matter what period we decide on it will always be too short for some and too long for others. With the current setup the deprecation period is a year, which seems like a decent middle ground. A year suits me fine if it were the *actual* deprecation period, rather than the six-month deprecation cycle as is the case with zLOG and the eight-month deprecation cycle as is the case with 'methods'. Currently adding a deprecation in a release doesn't automatically equate to a year's grace period, because people seem to assume they can deprecate a feature in a very late point release of the current stable branch and deprecate it exactly two releases later. Which in a time-based cycle is always shorter than a year, because the point release of the stable branch happens concurrently with development of the next major release. - C ___ 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 )
[Zope-dev] Re: Time-based releases a good idea?
Hi Chris! Chris McDonough wrote: On Wed, 2006-06-14 at 14:09 +0200, Wichert Akkerman wrote: No matter what period we decide on it will always be too short for some and too long for others. With the current setup the deprecation period is a year, which seems like a decent middle ground. A year suits me fine if it were the *actual* deprecation period, rather than the six-month deprecation cycle as is the case with zLOG and the eight-month deprecation cycle as is the case with 'methods'. As the person who added the deprecation warning for 'methods': If you calculate the deprecation cycle from the day the warning was added I agree it is too short. Reading the sources I had the impression that the fact there was no warning for the deprecated feature was a bug and I did consider my change a bugfix. Without warning it was already deprecated for many years. I'm fine with extending the deprecation period by one more release cycle. Cheers, Yuppie ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
Previously Chris McDonough wrote: A year suits me fine if it were the *actual* deprecation period, rather than the six-month deprecation cycle as is the case with zLOG and the eight-month deprecation cycle as is the case with 'methods'. I haven't kept track of zLOG (I'm still new to this world) so I don't know if that went according to the normal schedule or not. Currently adding a deprecation in a release doesn't automatically equate to a year's grace period, because people seem to assume they can deprecate a feature in a very late point release of the current stable branch and deprecate it exactly two releases later. Which in a time-based cycle is always shorter than a year, because the point release of the stable branch happens concurrently with development of the next major release. If I understand this correctly the problem you are seeing is this that you develop against an unreleased Zope version, so worst case your deprecation period starts just before the first beta of release x when someone adds a deprecation and ends at the time trunk opens for development for release x+2 and the deprecated feature is removed, which can be 6 months. I don't think that's a very fair method of measuring deprecation time: for stable releases which almost everyone uses the deprecation time will have been the full year. Wichert. - -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
On Wed, 2006-06-14 at 15:44 +0200, Wichert Akkerman wrote: Previously Chris McDonough wrote: A year suits me fine if it were the *actual* deprecation period, rather than the six-month deprecation cycle as is the case with zLOG and the eight-month deprecation cycle as is the case with 'methods'. I haven't kept track of zLOG (I'm still new to this world) so I don't know if that went according to the normal schedule or not. Actually, it will (or at least pretty close), since we aren't removing it until 2.11 (I computed 6 months based on 2.10, sorry). If I understand this correctly the problem you are seeing is this that you develop against an unreleased Zope version, so worst case your deprecation period starts just before the first beta of release x when someone adds a deprecation and ends at the time trunk opens for development for release x+2 and the deprecated feature is removed, which can be 6 months. No, actually, that's not what I mean. I don't think that's a very fair method of measuring deprecation time: for stable releases which almost everyone uses the deprecation time will have been the full year. Hmmm. Then I think someone needs to explain this: http://www.zope.org/Wikis/DevSite/Projects/Zope2.10/CurrentStatus (Final release late June/early July 2006) vs. http://svn.zope.org/Zope/branches/Zope-2_8-branch/lib/python/OFS/Application.py?rev=39882r1=39762r2=39882 (fixup checkin made Nov. 4, 2005, the earliest checkin for these deprecations was Oct. 31 2005). I'm no math genius, but that sure seems like about 8 months to me end-to-end. - C ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
--On 14. Juni 2006 10:40:05 -0400 Chris McDonough [EMAIL PROTECTED] wrote: Hmmm. Then I think someone needs to explain this: http://www.zope.org/Wikis/DevSite/Projects/Zope2.10/CurrentStatus (Final release late June/early July 2006) You know that the project wikis were always vapourware wikis (find it good or not)...lots of plans before the next release but only a small number of plans will make it into the final release. Likely the dates above were added before we changed to the June/December release cycle. -aj pgpOGKFkrurCx.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 )
[Zope-dev] Re: Time-based releases a good idea?
On Wed, 2006-06-14 at 15:42 +0200, yuppie wrote: If you calculate the deprecation cycle from the day the warning was added I agree it is too short. Whew, I'm not nuts then. ;-) Reading the sources I had the impression that the fact there was no warning for the deprecated feature was a bug and I did consider my change a bugfix. Without warning it was already deprecated for many years. That is the case for meta_types and __ac_permissions__ but I think you mistook the fact that methods followed a comment that said handle old-style product data for the fact that it was deprecated. But it never was officially deprecated, nor did it ever need to be. It just *happened* to follow that comment, lumped in with meta_types and __ac_permissions__. The deprecation warning is nonsensical there. please use registerClass instead is a non-sequitur as a deprecation warning, because registerClass will not help you do what methods does. I'm fine with extending the deprecation period by one more release cycle. That's fine for __ac_permissions__ and meta_types, but can't we just leave 'methods' in? IMO, deprecating it was a simple mistake, and that's OK. We don't need to make another mistake by actually removing it for the sake of being consistent with the earlier mistake. - C ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
So... you're saying that 2.10 isn't going to be released until December 2006, then? That would indeed make the deprecation period longer than 1 year, which seems to have been the intent. But wouldn't that make Zope's a yearly release cycle, given that the first beta of 2.9 was released *last* December? Now I'm really confused. On Wed, 2006-06-14 at 16:46 +0200, Andreas Jung wrote: --On 14. Juni 2006 10:40:05 -0400 Chris McDonough [EMAIL PROTECTED] wrote: Hmmm. Then I think someone needs to explain this: http://www.zope.org/Wikis/DevSite/Projects/Zope2.10/CurrentStatus (Final release late June/early July 2006) You know that the project wikis were always vapourware wikis (find it good or not)...lots of plans before the next release but only a small number of plans will make it into the final release. Likely the dates above were added before we changed to the June/December release cycle. -aj ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
--On 14. Juni 2006 10:59:09 -0400 Chris McDonough [EMAIL PROTECTED] wrote: So... you're saying that 2.10 isn't going to be released until December 2006, then? huh? The wiki says June/July...we are just running a bit late with the beta releases because Philikon needed some time for the ZPT integration..so why December? That would indeed make the deprecation period longer than 1 year, which seems to have been the intent. This makes no sense to me. Andreas pgpETOOh3GN7G.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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
On Wed, 2006-06-14 at 17:03 +0200, Andreas Jung wrote: --On 14. Juni 2006 10:59:09 -0400 Chris McDonough [EMAIL PROTECTED] wrote: So... you're saying that 2.10 isn't going to be released until December 2006, then? huh? The wiki says June/July...we are just running a bit late with the beta releases because Philikon needed some time for the ZPT integration..so why December? Buh oh geez, let's just forget it. ;-) That would indeed make the deprecation period longer than 1 year, which seems to have been the intent. This makes no sense to me. Let's start clean here. What interval of time is reasonable for the period between a to-be-removed piece of code emitting a deprecation warning and that code's removal? If you think 8 months is reasonable, it would make sense, for example, that the code in OFS.Application that looks for a module-scope '__ac_permissions__' in all products would be removed for 2.10 (as its deprecation warning currently states). If you think that's too short a time, then it's broken. Personally I think 8 months is too short a time, and I think it should be at least one year and I think most folks agree with this. I don't remember what the official policy is nor would I know where to find it. But if you agree with this, in order to have a full year's deprecation period, as far as I can tell, we'd need to make a policy that deprecations can only be done in in .0 releases. That would ensure at least a full year between the first deprecation and the code removal. Any other policy does not make sense if the goal is to have full-year-long deprecation periods. And at this point, IMO, a feature isn't really deprecated until it emits a warning. Older releases didn't emit deprecation warnings (partly because there was no warnings module), so basically *we tried not to deprecate anything* and we always strove (but only partially succeeeded) at full-bore backwards compatibility, cruft-be-damned. Things are better now, so we can deprecate stuff, but we still need to be consistent about how we do it. - C ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
On 6/14/06, Chris McDonough [EMAIL PROTECTED] wrote: That is the case for meta_types and __ac_permissions__ but I think you mistook the fact that methods followed a comment that said handle old-style product data for the fact that it was deprecated. But it never was officially deprecated, nor did it ever need to be. It just *happened* to follow that comment, lumped in with meta_types and __ac_permissions__. The deprecation warning is nonsensical there. please use registerClass instead is a non-sequitur as a deprecation warning, because registerClass will not help you do what methods does. Ah, well, then we have two overlapping issues that causes this problemo: 1. We did not use deprecation warnings years ago. 2. methods issue deprecation warnings by mistake. (In fact, 2 is an effect of 1, as the warning comes because it was unclear what was deprecated.) This means that we in any case definitely should NOT remove methods until 2.11, if at all. :) So this is not a problem with deprecation period, time based releases or anything else, then. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
On Jun 14, 2006, at 12:32 PM, Lennart Regebro wrote: On 6/14/06, Chris McDonough [EMAIL PROTECTED] wrote: That is the case for meta_types and __ac_permissions__ but I think you mistook the fact that methods followed a comment that said handle old-style product data for the fact that it was deprecated. But it never was officially deprecated, nor did it ever need to be. It just *happened* to follow that comment, lumped in with meta_types and __ac_permissions__. The deprecation warning is nonsensical there. please use registerClass instead is a non-sequitur as a deprecation warning, because registerClass will not help you do what methods does. Ah, well, then we have two overlapping issues that causes this problemo: 1. We did not use deprecation warnings years ago. 2. methods issue deprecation warnings by mistake. (In fact, 2 is an effect of 1, as the warning comes because it was unclear what was deprecated.) This means that we in any case definitely should NOT remove methods until 2.11, if at all. :) +1 to not at all from me ;-) So this is not a problem with deprecation period, time based releases or anything else, then. There are problems with the deprecation period, but only for __ac_permissions__ and meta_types assuming we choose not to deprecate 'methods'. If we were naive, we'd change the deprecation warning messages for __ac_permissions__ and meta_types in 2.9.4 from will disappear in 2.10 to will disappear in 2.11. But since we decided (in another offshoot of this thread) that it only makes sense to deprecate things in .0 releases, what *should* happen is that we should forget about all of this and add will disappear in 2.12 to what will become 2.10.0. - C ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
On Jun 14, 2006, at 1:09 PM, Lennart Regebro wrote: On 6/14/06, Chris McDonough [EMAIL PROTECTED] wrote: There are problems with the deprecation period, but only for __ac_permissions__ and meta_types assuming we choose not to deprecate 'methods'. The problem in this case being that we didn't use to issue deprecation warnings. ;) Yup, can't change history. In any case, I personally don't care if it's removed in 2.10 or 2.11. But since we decided (in another offshoot of this thread) that it only makes sense to deprecate things in .0 releases, what *should* happen is that we should forget about all of this and add will disappear in 2.12 to what will become 2.10.0. I don't understand that logic. Zope 2.9.0 issued deprecation warnings for these. Why should we not remove it in 2.11.0? That is two major versions later. You're right, sorry. I didn't realize the deprecations made it into 2.9.0; I thought they went in to 2.8.5+ and 2.9.1+ . Removing these in 2.11.0 is fine then. The 2.9 branch's deprecation warnings will continue to will say that all of these things will be removed in 2.10, which will be a lie. But that's OK, people will tolerate misleading deprecation warnings as long as what we do is actually more conservative than what it says we're going to do. - C ___ 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
Paul Winkler wrote: On Wed, Jun 14, 2006 at 11:47:13AM -0400, Chris McDonough wrote: I think that's the sanest policy. So it's OK if bullshit gets called on people putting deprecation warnings into any .1, .2, etc through .9 releases, then? This seems like the only thing that can work. We can't expect people to upgrade to stable point releases (e.g. 2.8.5 from 2.8.4 or earlier) just to be able to see deprecation warnings. That makes perfect sense to me. +1 to no new deprecation warnings in stable third-dot releases. +1 to that too. No new deprecation warnings outside feature releases. Regards, Martijn ___ 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 )
[Zope-dev] Re: Time-based releases a good idea?
Hi yuppie... On Jun 14, 2006, at 1:00 PM, yuppie wrote: Hi Chris! Chris McDonough wrote: On Wed, 2006-06-14 at 15:42 +0200, yuppie wrote: Reading the sources I had the impression that the fact there was no warning for the deprecated feature was a bug and I did consider my change a bugfix. Without warning it was already deprecated for many years. That is the case for meta_types and __ac_permissions__ but I think you mistook the fact that methods followed a comment that said handle old-style product data for the fact that it was deprecated. But it never was officially deprecated, nor did it ever need to be. It just *happened* to follow that comment, lumped in with meta_types and __ac_permissions__. The deprecation warning is nonsensical there. please use registerClass instead is a non-sequitur as a deprecation warning, because registerClass will not help you do what methods does. It's not that simple. registerClass has an optional 'legacy' argument that does something quite similar. It just monkey patches ObjectManager instead of Folder. So at least for some use cases registerClass *will* help you. That would be helpful if I had a class to register. If I don't, it's an even worse hack than methods is. This is the case for External Editor. It has no addable types. And switching over to use something named legacy seems silly. How long until that's deprecated under the new clean-up-the-cruft-or-die regime? I might be wrong, but it looks like the 'legacy' argument was added exactly for that one purpose: Providing a migration path for 'methods'. I doubt it was ever good practice to use 'methods' for something else than factory methods. Don't know how many products out there use 'methods' for something else. But so far the only product mentioned is ExternalEditor. PsycoPG-DA does, MySQLDA does, one of my products named ZopeMailArchive does. Even in the core ZClasses/__init__.py still uses it. And these are only the products I have on my hard disk. No idea how many others use it. BTW: The name and comments in the code of the 'legacy' argument make clear that using these legacy methods is deprecated as well. I'm fine with extending the deprecation period by one more release cycle. That's fine for __ac_permissions__ and meta_types, but can't we just leave 'methods' in? IMO, deprecating it was a simple mistake, and that's OK. We don't need to make another mistake by actually removing it for the sake of being consistent with the earlier mistake. If adding deprecation warnings for 'methods' was a mistake it was not a simple mistake. I still believe it should be removed. I believe the Hippocratic Oath should be followed in subjective cases like this. First, do no harm. If we do deprecate it, we will need to have the deprecation warning *at least* say something better than use registerClass, because that's meaningless. Maybe it should give a URL that has content that explains how to monkey patch OFS.Folder. But in that case, it just seems dumb to deprecate; we know methods works. Maybe we can provide a utility method that does the same thing as 'methods' does? You ignored my argument regarding the shorter deprecation period. But if there is a consensus that old deprecations without explicit deprecation message don't count I'm fine with extending the period for __ac_permissions__ and meta_types as well. I did not mean to ignore it, I thought I had acknowledged it in another mail, sorry. - C ___ 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 )
Re: [Zope-dev] Re: OFS.Application deprecations for Zope 2.10
Florent Guillaume wrote at 2006-6-13 22:13 +0200: ... Yes but the deprecation has been there for a while, and the third party product developers have been ignoring the warning. Their loss. Interestingly, it is usually not the loss for the third party product developers (as they usually gain nothing from their products) -- but for the people using the product. Personally, I will simply blame Zope when one of my products breaks for some stupid BBB incompatibility (such as removing zLOG or methods support in initialization modules) introduced by some Zope release. I will fix them only, when I myself upgrade to a newer Zope and hit the problems (only then, I can reproduce the problem and check that the fix really fixes). I am slowly upgrading (still using Zope 2.8). Unlike Nuxeo, I do not get money (or other rewards) for keeping my products in sync with the current Zope releases. -- Dieter ___ 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 )
Re: [Zope-dev] Time-based releases a good idea?
Chris Withers wrote at 2006-6-14 07:32 +0100: ... Would be interested to know what other people think... I like time based releases but I hate deprecations for cosmetic annoyances (term stolen from Andreas). I have the feeling that most deprecations so far have been for cosmetics only. -- Dieter ___ 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 )
Re: [Zope-dev] Re: OFS.Application deprecations for Zope 2.10
On 14 Jun 2006, at 22:06, Dieter Maurer wrote: Florent Guillaume wrote at 2006-6-13 22:13 +0200: Yes but the deprecation has been there for a while, and the third party product developers have been ignoring the warning. Their loss. Interestingly, it is usually not the loss for the third party product developers (as they usually gain nothing from their products) -- but for the people using the product. When users repeatedly bitch to the developer because a product doesn't work with a newer Zope version, it's a loss of time for the developer. He would have gained time by doing the correction in advance of the users discovering the problem. Personally, I will simply blame Zope when one of my products breaks for some stupid BBB incompatibility (such as removing zLOG or methods support in initialization modules) introduced by some Zope release. I will fix them only, when I myself upgrade to a newer Zope and hit the problems (only then, I can reproduce the problem and check that the fix really fixes). I am slowly upgrading (still using Zope 2.8). Unlike Nuxeo, I do not get money (or other rewards) for keeping my products in sync with the current Zope releases. Nuxeo isn't getting money from using Zope 2.10, for instance, it's just that we believe that any improvements is worth putting back into Zope itself (if only so that maintenance is shared and peer-reviewed) and not kept in our own tree. Being interested in improving the framework means that we have to work with it, and it's better to work with something clean than with something that has accumulated years and years of cruft. So we're interested in cleaning up the framework. This means deprecating broken, old or dirty stuff at some point. Florent -- Florent Guillaume, Nuxeo (Paris, France) Director of RD +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ 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 )
[Zope-dev] Re: Time-based releases a good idea?
Hi Chris! Chris McDonough wrote: On Jun 14, 2006, at 1:00 PM, yuppie wrote: It's not that simple. registerClass has an optional 'legacy' argument that does something quite similar. It just monkey patches ObjectManager instead of Folder. So at least for some use cases registerClass *will* help you. That would be helpful if I had a class to register. If I don't, it's an even worse hack than methods is. This is the case for External Editor. It has no addable types. And switching over to use something named legacy seems silly. How long until that's deprecated under the new clean-up-the-cruft-or-die regime? AFAICS the Right Way to modernize ZopeMailArchive and ExternalEditor would be using adapters. I don't recommend to abuse registerClass instead of 'methods'. And using a monkey patch is only the more obvious way of doing the wrong thing. I might be wrong, but it looks like the 'legacy' argument was added exactly for that one purpose: Providing a migration path for 'methods'. I doubt it was ever good practice to use 'methods' for something else than factory methods. Don't know how many products out there use 'methods' for something else. But so far the only product mentioned is ExternalEditor. PsycoPG-DA does, MySQLDA does, one of my products named ZopeMailArchive does. Even in the core ZClasses/__init__.py still uses it. And these are only the products I have on my hard disk. No idea how many others use it. The obsolete ZPsycopgDA 1.1 just uses it for factory methods, ZPsycopgDA 2.0 doesn't use it. The last ZMySQLDA release is 5 years old. It also uses it for factory methods. These 2 examples show that some very old products still use 'methods' instead of registerClass. They can easily be updated. ZClasses is no product and unless some other magic uses 'methods' it is ignored anyways. If adding deprecation warnings for 'methods' was a mistake it was not a simple mistake. I still believe it should be removed. I believe the Hippocratic Oath should be followed in subjective cases like this. First, do no harm. Cruft does harm. It discourages people who want to understand and improve Zope. And it encourages people to stick to bad coding habits. If we do deprecate it, we will need to have the deprecation warning *at least* say something better than use registerClass, because that's meaningless. Maybe it should give a URL that has content that explains how to monkey patch OFS.Folder. But in that case, it just seems dumb to deprecate; we know methods works. Maybe we can provide a utility method that does the same thing as 'methods' does? Why do you want to have special support for monkey patching Folder? Which use cases justify to pollute the Folder API in that way? You ignored my argument regarding the shorter deprecation period. But if there is a consensus that old deprecations without explicit deprecation message don't count I'm fine with extending the period for __ac_permissions__ and meta_types as well. I did not mean to ignore it, I thought I had acknowledged it in another mail, sorry. No problem. And meanwhile you answered this in another mail. While I still believe there was a good reason to differentiate between new and historical deprecations I now see that it is hard to communicate the difference and all the confusion it caused is not worth the shorter warning period. So I'm fine with starting new deprecation periods for all code that was deprecated the old way (not using warnings). Of course new deprecation periods have to start in a .0 release. Cheers, Yuppie ___ 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 )
