[Zope-dev] Re: Time-based releases a good idea?
Dieter Maurer wrote: 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. Hmm, then we have different perspectives on why we would evolve (since evolvement is typically the cause of BBB code and hence deprecation warnings). I think there are two main driving factors: * cutting down the amount of code duplication and duplicated frameworks. We've had two ZPT implementations, now we have to maintain only one. We had our own logging framework, now we can simply use Python's, etc. These changes may seem cosmetic to the outside developer (he has to use different APIs), but they're essential to us as to how much code we want to have maintained or, in the worst case, bitrotting in our source tree. I'll note that even the outside developer may benefit from our using more standard libraries, because they might already been known to him. Even more so, they're already documented by someone else. (Was zLOG ever documented? I don't think so. But the 'logging' module is.) * moving to more Zope 3 technology. We've managed to introduce Zope 3 technology in a couple of isolated areas in Zope 2, e.g. i18n, views, object events. So far, we've only seen deprecation warnings in the field of events where the old manage_* methods have been deprecated. Zope 3's event system is superior to the methhod overriding in Zope 2, hence we're evolving Zope 2. People *want* to use Zope 3 technology in Zope 2 more and more and currently the framework it's stopping them in many ways. Five, on the other hand, is just a (very large by now) compatibility layer (with lots of code duplication) to which the first point shall also apply: we should try to make code in Five smaller by evolving Zope 2. I agree with Tres, Chris, Andreas and Dieter that we've seen some spurious deprecation warnings in the Zope 2.9 release. I think things got deprecated in Zope 2.9 that were scheduled for deprecation in Zope 2.10 (e.g. zLOG). There might have been other cases. I also agree that we can't deprecate anything as long as Zope code is still using it. I think there are some deprecation fouls like that in Zope 2.9, too. This was all unfortunate. What we can do about it now is fix it and learn from it for future release cycles. I also agree with Dieter on cosmetic annoyances. But I don't think we're deprecating only for cosmetics. I think a deprecation warning should satisfy at least one of the above points. Otherwise it wouldn't be worth it. Chris put this nicely, we need to pick our battles. I do stand behind evolving Zope 2 and exploring synergies with standard Python software. That's my battle :). Philipp ___ 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?
Tres Seaver wrote: Lennart Regebro wrote: 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. Bzzt. Five is a *major* culprit for us (Chris and I are often working together). The lookup order BBB foul in 2.9.2 is one of the major reasons for sticking to 2.8. I think we've been over this. It's not really a BBB foul because I classified it as a bug when I found out about the issue (http://codespeak.net/pipermail/z3-five/2006q1/001186.html). The rationale behind this thinking is being closer to Zope 3's behaviour where folder/foo would first look up the 'foo' item in the folder, then the @@foo view. I think we've also come to an agreement to make this pluggable. I don't remember anything happening, though. For all I care, we can go back to the old behaviour with the only exception that ObjectManagers are traversed attributes-first-views-later. Views should not shadow contained items. Philipp ___ 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?
Andreas Jung wrote: 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. That sends a pretty bad message. It's not really acceptable for a stable (ie: non-beta) point release to emit deprecation warnings. It's a sign that time-based releases are forcing releases that aren't ready to become production releases :-( right...I did not think that we deprecated and removed something without having a reasonable replacement...or did we? I think the timeframes feel to short. If we really must have time based releases (and I'm really starting to feel like they're a bad idea...) then 9 months or a year would be better between new feature releases. Personally, I find non-time-based releases a much nicer prospect: you only need to move to the next major version when it's ready and because it contains big new features you really want. cheers, 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?
Andreas Jung wrote: 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. Yes, I noticed your name in svn praise ;-) 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?
Jens Vagelpohl wrote: 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) Indeed, this seems to be purely an artifact of time-based releases. I'm sure I'm not the only one who routinely has projects that see no maintenance for over a year, and doesn't like moving major zope versions without a compelling reason. The hops most of my projects seemed to have made are 2.5-2.6--2.7-2.9, but I'm only just getting onto 2.9 and people are talking about 2.11 already. So, that means if I want to fix a bug for one of my non-moved projects, I need to patch the 2.7, 2.8, 2.9, 2.10 and 2.11 branches, as well as the trunk. Anyone else think that's completely insane?! 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. Yeah, I have been, but I've hit exactly the problem described above. I fixed one chunk of zLOG warning on 2.9, and found they'd been fixed by someone else on the trunk in a different fashion. Pretty annoying :-( 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?
Chris McDonough wrote: 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. ...and how! And why the should the core emit a deprecation warning? Amen. the goal here? Removing zLOG is (at least by any sane measure) totally gratuitous in the first place, Actually, I don't agree, zLOG is a PITA... So, anyway, I have a really significant number of released products that make use of zLOG. Loose 'zLOG', sub in a generic X for some feature I've relied on (History copy, etc) and I'm totally with you... 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. Ditto. 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. Amen, again... 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. *rounds of cheering* 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 vs Bugfixing
Wichert Akkerman wrote: Previously Max M wrote: 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. But until then you don't upgrade and the changes made in later Zope versions are not relevant. If and when you do an upgrade you will have update your products to reflect that Zope (and other products) have evolved. That will always be true for upgrades. Okay, 2 point: 1. That's all well and good until you _need_ some feature like MVCC and are then forced to do an upgrade which breaks prettymuch every one of your products. 2. Yeah, we all know that bugs should get fixed on all stable branches, but that becomes less and less likely the more stable branches there are. Time based releases seem to be making this problem much much worse. cheers, 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] You can always document...
yuppie wrote: 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. As far as methods goes, I call bullshit on this. Simple documentation of what methods is used for probably would have sufficed... Why do you want to have special support for monkey patching Folder? Which use cases justify to pollute the Folder API in that way? This is Zope 2, namespace polution is _not_ something that's going to get fixed... cheers, 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 vs Open Source
Max M wrote: 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. Exactly. And having to go to much more effort to get a product working with a 3 or 4 stable branches is just too much damned work. 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] methods et al
yuppie wrote: If adding deprecation warnings for 'methods' was a mistake it was not a simple mistake. I still believe it should be removed. I think you're in the minority here. I suspect you could remove the legacy thing without much problem, but it feels like methods has a genuine need for existence... 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. Sounds like a plan... 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] Re: Time-based releases a good idea?
Lennart Regebro wrote: So this is not a problem with deprecation period, time based releases or anything else, then. No, but the slew of deprecation warnings, proliferation of branches that need to be supported (regardless of whether they're officially production or not) and sheer amount of change you now HAVE (rather than 'can choose') to deal with seems a sign, at least to me, that time-based releases were a nice experiment, but maybe it's time to think again? 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] Zope 2 bugday, today (the 15th)!
Join #zope-dev on freenode.net and help make 2.10 the best Zope 2 ever! :) -- 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] Zope 2 bugday, today (the 15th)!
--On 15. Juni 2006 11:29:11 +0200 Lennart Regebro [EMAIL PROTECTED] wrote: Join #zope-dev on freenode.net and help make 2.10 the best Zope 2 ever! :) Unfortunately the email collector notification does not seem to work...anyone to slap zope.org? Andreas pgpp7hSAyzVwD.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 vs Bugfixing
On 6/15/06, Chris Withers [EMAIL PROTECTED] wrote: 2. Yeah, we all know that bugs should get fixed on all stable branches, but that becomes less and less likely the more stable branches there are. Time based releases seem to be making this problem much much worse. Only because we have more stable releases, now than we had during 2002-2005. That in turn was because the development effort was directed at Zope3 during this period. Before that, we has stable releases around twice a year too: Between 2.1 and 2.2 there was 225 days Between 2.2 and 2.3 there was 196 days Between 2.3 and 2.4 there was 178 days Between 2.4 and 2.5 there was 186 days Between 2.5 and 2.6 there was 266 days All pretty much once every six months. What happened then, during 2.6 to 2.8 was that the development of Zope was done on Zope3, and Zope2 development suffered from this. So this is not a fault of time based releases. The difference is this: 1. That's all well and good until you _need_ some feature like MVCC and are then forced to do an upgrade which breaks prettymuch every one of your products. And the difference is that this didn't happen very often during 2.6 to 2.8, because there were no new features to _need_. That's not a good thing. Zope2 development stood pretty much still for several years. We are no picking up the slack, and yes, that means loads of rapid changes. The alternative is stagnation and ultimately death. -- 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] buildbot failure in Zope branches 2.9 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope branches 2.9 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 6131 Blamelist: alecm,andreasjung,efge,faassen,jim,jinty,mgedmin,srichter,yuppie BUILD FAILED: failed test sincerely, -The Buildbot ___ 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] buildbot failure in Zope branches 2.10 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope branches 2.10 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 6130 Blamelist: alecm,andreasjung,efge,faassen,jim,jinty,mgedmin,srichter,yuppie BUILD FAILED: failed test sincerely, -The Buildbot ___ 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] buildbot failure in Zope branches 2.10 2.4 Windows 2000 zc-bbwin2
The Buildbot has detected a failed build of Zope branches 2.10 2.4 Windows 2000 zc-bbwin2. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 6130 Blamelist: alecm,andreasjung,efge,faassen,jim,jinty,mgedmin,srichter,yuppie BUILD FAILED: failed failed slave lost sincerely, -The Buildbot ___ 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: You can always document...
Hi Chris! Chris Withers wrote: yuppie wrote: 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. As far as methods goes, I call bullshit on this. Simple documentation of what methods is used for probably would have sufficed... This is how 'methods' is documented in OFS.Application:: # Look for an 'initialize' method in the product. If it does # not exist, then this is an old product that has never been # updated. In that case, we will analyze the product and # build up enough information to do initialization manually. [...] # Support old-style product metadata. Older products may # define attributes to name their permissions, meta_types, # constructors, etc. [followed by the code that interprets the 'methods' attribute] So 'methods' is BBB code for constructors. Other use cases might work, but they were never officially supported. Note that using 'methods' was already 'old-style' 6 years ago. Why do you want to have special support for monkey patching Folder? Which use cases justify to pollute the Folder API in that way? This is Zope 2, namespace polution is _not_ something that's going to get fixed... There were many attempts to fix this and the pollution would be much worse without those attempts. 'methods' was replaced by 'registerClass' to give constructors their own namespace: manage_addProduct. 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 )
[Zope-dev] Re: Time-based releases vs Bugfixing
Lennart Regebro wrote: Zope2 development stood pretty much still for several years. We are no picking up the slack, and yes, that means loads of rapid changes. The alternative is stagnation and ultimately death. Well, I must say that I enjoyed that. Being able to add new functionality in peace, instead of fixing already working stuff. But then again, my interrest is in user functionality. Not in core development. -- 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 )
Re: [Zope-dev] Re: Time-based releases a good idea?
Chris Withers wrote: Lennart Regebro wrote: So this is not a problem with deprecation period, time based releases or anything else, then. No, but the slew of deprecation warnings, proliferation of branches that need to be supported (regardless of whether they're officially production or not) and sheer amount of change you now HAVE (rather than 'can choose') to deal with seems a sign, at least to me, that time-based releases were a nice experiment, but maybe it's time to think again? I disagree completely. I think time based releases were a factor in rescuing at least Zope 2 from complete stagnation. I also think that time based releases have helped getting a lot more Zope 3 to everybody much faster than before. They have encouraged people to actually contribute to the core, as they know the fix or feature will be in there in a few months, at a predictable time, not years in the indefinitey future as it was before. Overall I think time based releases have been overwhelmingly *successful*. And yes, porting applications to new releases takes time and is frequently painful. If the alternative is stagnation or having to write code against old APIs that I know have better alternatives somewhere in subversion but don't know when they'll ever get released, I'll gladly take that pain. That said, of course things have to be done carefully. Stick with the release policy we all should be following anyway: don't deprecate anything in a bugfix release. Carefully consider backwards compatibility. Back out of changes that are too damaging. I'm curious to hear what alternative you'd prefer. I didn't like the old release policy much: from 2.6 to 2.7 took over a year and a half. The alpha for 2.7 was released almost a *year* before 2.7 was finally released. It then took a year for 2.8 to be released. Nobody knew what was going to happen when, and Zope 2 development was pretty stagnant for huge spans of time (not discounting the wonderful work that *was* done in that period). People were building piles of framework code on top of Zope that should've gone into the core where we could all share it, but people avoided the core. Now, Zope 2 is alive again. 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 )
Re: [Zope-dev] Time-based releases a good idea?
Chris Withers wrote: [snip] Personally, I find non-time-based releases a much nicer prospect: you only need to move to the next major version when it's ready and because it contains big new features you really want. Who is going to develop these big features? What's the motivation? I'm not going to develop major features if I know it might be a year or more before I can actually get to use them. 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?
On Jun 15, 2006, at 3:13 AM, Philipp von Weitershausen wrote: We've had two ZPT implementations, now we have to maintain only one. We had our own logging framework, now we can simply use Python's, etc. These changes may seem cosmetic to the outside developer (he has to use different APIs), but they're essential to us as to how much code we want to have maintained or, in the worst case, bitrotting in our source tree. I'll note that even the outside developer may benefit from our using more standard libraries, because they might already been known to him. Even more so, they're already documented by someone else. (Was zLOG ever documented? I don't think so. But the 'logging' module is.) The zLOG removal will break far more third-party code than any other API change we've talked about so far. The cost of each API change needs to be weighed against its benefit. This is one of those cases where backwards compatibility was free; the code was already there. zLOG was just a tiny shim that called into the logging module. Removing it is gratuitous. In general, this change is the definition of cosmetic. For what it's worth, maybe there's some middle ground here. Just because something is deprecated doesn't need it needs to have a hard date to be removed. Why don't we just have the first use of zLOG in each module generate a deprecation warning and just leave it there forever? People will get sick of seeing the warnings, and they'll eventually change it, but there's just no reason to *force* them to change it on our time schedule. And if they don't, who cares? People who don't want to see the warnings can filter them out. I'm also for reducing duplication, but only to the point that it does not large amounts of break running code. We have yet to see what the real fallout of changing to the Z3 ZPT implementation is. It may be a pure win, but I wouldn't declare victory just yet, at least until we have some empirical evidence that it doesn't break large existing codebases. * moving to more Zope 3 technology. We've managed to introduce Zope 3 technology in a couple of isolated areas in Zope 2, e.g. i18n, views, object events. So far, we've only seen deprecation warnings in the field of events where the old manage_* methods have been deprecated. Zope 3's event system is superior to the methhod overriding in Zope 2, hence we're evolving Zope 2. People *want* to use Zope 3 technology in Zope 2 more and more and currently the framework it's stopping them in many ways. Five, on the other hand, is just a (very large by now) compatibility layer (with lots of code duplication) to which the first point shall also apply: we should try to make code in Five smaller by evolving Zope 2. There are reasons we are bothering to change the Zope 2 APIs at this point instead of all of us moving to Zope 3 wholesale. One reason is because we've figured out that in the real world backwards compatibility and familiarity are primary drivers for take-up of technology. Let's please not forget that again, and let's be careful. - 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?
Chris McDonough wrote: On Jun 15, 2006, at 3:13 AM, Philipp von Weitershausen wrote: We've had two ZPT implementations, now we have to maintain only one. We had our own logging framework, now we can simply use Python's, etc. These changes may seem cosmetic to the outside developer (he has to use different APIs), but they're essential to us as to how much code we want to have maintained or, in the worst case, bitrotting in our source tree. I'll note that even the outside developer may benefit from our using more standard libraries, because they might already been known to him. Even more so, they're already documented by someone else. (Was zLOG ever documented? I don't think so. But the 'logging' module is.) The zLOG removal will break far more third-party code than any other API change we've talked about so far. The cost of each API change needs to be weighed against its benefit. This is one of those cases where backwards compatibility was free; the code was already there. zLOG was just a tiny shim that called into the logging module. Removing it is gratuitous. In general, this change is the definition of cosmetic. Well, except that the actual, formal deprecation of zLOG finally made everyone aware of the logging module and a few things like logging levels that no one had thought about till then. So I wouldn't say the benefit was exactly zero... whether it ways out agianst the costs I don't think I can say at this point. For what it's worth, maybe there's some middle ground here. Just because something is deprecated doesn't need it needs to have a hard date to be removed. Why don't we just have the first use of zLOG in each module generate a deprecation warning and just leave it there forever? Or make it available optionally. After all, it's just a Python module. Perhaps we should put up the latest version from Zope 2.10 as a separate egg on the cheeseshop. People can then just ez_install it if their product still happens to need it... People will get sick of seeing the warnings, and they'll eventually change it, but there's just no reason to *force* them to change it on our time schedule. And if they don't, who cares? People who don't want to see the warnings can filter them out. I'm also for reducing duplication, but only to the point that it does not large amounts of break running code. We have yet to see what the real fallout of changing to the Z3 ZPT implementation is. It may be a pure win, but I wouldn't declare victory just yet, at least until we have some empirical evidence that it doesn't break large existing codebases. Oh, I absolutely agree. Zope 2.10 will need strong testing mostly because the ZPT implementation. This was a pretty major change, the few heavy discussions we had so far already are good evidence of that (e.g. the one on empty path expressions). Given all that, it's still a thing we wanted to do and are happy to do. I agree, we can't declare victory on the whole war yet, but at least on a few battles... :) * moving to more Zope 3 technology. We've managed to introduce Zope 3 technology in a couple of isolated areas in Zope 2, e.g. i18n, views, object events. So far, we've only seen deprecation warnings in the field of events where the old manage_* methods have been deprecated. Zope 3's event system is superior to the methhod overriding in Zope 2, hence we're evolving Zope 2. People *want* to use Zope 3 technology in Zope 2 more and more and currently the framework it's stopping them in many ways. Five, on the other hand, is just a (very large by now) compatibility layer (with lots of code duplication) to which the first point shall also apply: we should try to make code in Five smaller by evolving Zope 2. There are reasons we are bothering to change the Zope 2 APIs at this point instead of all of us moving to Zope 3 wholesale. One reason is because we've figured out that in the real world backwards compatibility and familiarity are primary drivers for take-up of technology. Let's please not forget that again, and let's be careful. I agree. This is why we need watch each other's steps and discuss the things. This has coined the term checkin police in Zope 3. We already have it in Zope 2, but somehow it has failed this time... This whole discussion has uncovered lots of stacked up frustration, it seems; it could have been held a lot earlier, I guess (from both sides). Philipp ___ 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 15 Jun 2006, at 16:09, Philipp von Weitershausen wrote: Chris McDonough wrote: People will get sick of seeing the warnings, and they'll eventually change it, but there's just no reason to *force* them to change it on our time schedule. And if they don't, who cares? People who don't want to see the warnings can filter them out. I'm also for reducing duplication, but only to the point that it does not large amounts of break running code. We have yet to see what the real fallout of changing to the Z3 ZPT implementation is. It may be a pure win, but I wouldn't declare victory just yet, at least until we have some empirical evidence that it doesn't break large existing codebases. Oh, I absolutely agree. Zope 2.10 will need strong testing mostly because the ZPT implementation. This was a pretty major change, the few heavy discussions we had so far already are good evidence of that (e.g. the one on empty path expressions). Given all that, it's still a thing we wanted to do and are happy to do. I agree, we can't declare victory on the whole war yet, but at least on a few battles... :) FWIW the CPS 4 trunk (in development for now) works fine with the new zpt implementation, provided you use only unicode everywhere, which we do. Thanks Philip for the move to z3 zpt! 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?
On Jun 14, 2006, at 5:30 PM, yuppie wrote: 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. OK. I still think this is wrong, but I don't have the time to argue anymore. 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. Nope. Sorry. It's the stinky glue that keeps everything running. I have a sense that you don't appreciate the full negative impact of these kinds of changes because you haven't really thought about the impact to the third-party dependency graph very much. 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? We can't rely on browser view lookup here. I'm will not break third- party code that relies on being able to look up EE's externalEditLink_ by asking for it against any folder via getattr. At least not when there's google hits for that string that point into silva, Zelenium, Axiom, Plone, CPS, and zpydoc. That would be dumb, because some of these products might not have even been updated to run against Zope 2.8+, and thus which would not be able to use Five even if they wanted to. So Florent has already changed EE on the trunk to do its own monkey- patch of Folder, which will stay. EE will start to break in 2.11 if I (or someone else) haven't gotten the time by then to make a new release of EE with that code. So be it. 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. OK. - 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?
On Jun 15, 2006, at 10:09 AM, Philipp von Weitershausen wrote: Well, except that the actual, formal deprecation of zLOG finally made everyone aware of the logging module and a few things like logging levels that no one had thought about till then. So I wouldn't say the benefit was exactly zero... whether it ways out agianst the costs I don't think I can say at this point. If you can't say, it means you're not sure if there's a clear win, and if thats the case I think you gotta be on the side of not removing it under Hippocratic rules. For what it's worth, maybe there's some middle ground here. Just because something is deprecated doesn't need it needs to have a hard date to be removed. Why don't we just have the first use of zLOG in each module generate a deprecation warning and just leave it there forever? Or make it available optionally. After all, it's just a Python module. Perhaps we should put up the latest version from Zope 2.10 as a separate egg on the cheeseshop. People can then just ez_install it if their product still happens to need it... Yeah. Or just leave it in. ;-) There are reasons we are bothering to change the Zope 2 APIs at this point instead of all of us moving to Zope 3 wholesale. One reason is because we've figured out that in the real world backwards compatibility and familiarity are primary drivers for take-up of technology. Let's please not forget that again, and let's be careful. I agree. This is why we need watch each other's steps and discuss the things. This has coined the term checkin police in Zope 3. We already have it in Zope 2, but somehow it has failed this time... This whole discussion has uncovered lots of stacked up frustration, it seems; it could have been held a lot earlier, I guess (from both sides). Yup, see my mea culpa in my first message to this thread. I don't like needing to take a hard line on these issues, and I gotta admit to being extremely sympathetic to wanting to rip out all of this stuff in a perfect world, but my first allegiance is to my customers, who have completely different goals than the people who want rapid change. - 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: OFS.Application deprecations for Zope 2.10
Hi Chris! Chris McDonough wrote: For what it's worth, maybe there's some middle ground here. Just because something is deprecated doesn't need it needs to have a hard date to be removed. Why don't we just have the first use of zLOG in each module generate a deprecation warning and just leave it there forever? People will get sick of seeing the warnings, and they'll eventually change it, but there's just no reason to *force* them to change it on our time schedule. And if they don't, who cares? People who don't want to see the warnings can filter them out. This sounds like a good compromise. At least for 'methods'. I don't know if we should leave it there forever, but we could keep it at least until it gets in the way of code improvements. Nobody complained about removing '__ac_permissions__' and 'meta_types' support, so I guess they can be removed in Zope 2.11. 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 )
[Zope-dev] buildbot failure in Zope trunk 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 6153 Blamelist: dominikhuber,jim,jinty,regebro,shh,tseaver BUILD FAILED: failed test sincerely, -The Buildbot ___ 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] buildbot failure in Zope branches 2.10 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope branches 2.10 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 6152 Blamelist: dominikhuber,jim,jinty,regebro,shh,tseaver BUILD FAILED: failed test sincerely, -The Buildbot ___ 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] buildbot failure in Zope trunk 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope trunk 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 6158 Blamelist: alecm,shh BUILD FAILED: failed test sincerely, -The Buildbot ___ 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?
Chris McDonough wrote at 2006-6-14 14:50 -0400: ... PsycoPG-DA does, MySQLDA does, one of my products named ZopeMailArchive does. CCSQLMethods does (because until very recently ZSQLMethods did, hopefully changed now). -- 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 )
[Zope-dev] buildbot failure in Zope branches 2.10 2.4 Linux zc-buildbot
The Buildbot has detected a failed build of Zope branches 2.10 2.4 Linux zc-buildbot. Buildbot URL: http://buildbot.zope.org/ Build Reason: changes Build Source Stamp: 6168 Blamelist: alecm,shh,tseaver BUILD FAILED: failed test sincerely, -The Buildbot ___ 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] Nasty error message with obscure bug
Hi All, Got this weird error message: Module TAL.TALInterpreter, line 701, in translate Module Products.PageTemplates.TALES, line 261, in translate Module Products.Five.i18n, line 51, in translate Module Products.PageTemplates.GlobalTranslationService, line 33, in translate TypeError: expected string or buffer ...and eventually tracked it down to this code: meta name=description content=blah i18n:attributes=description/ The bug, of course, is that the i18:attributes should be content, not description, which doesn't exist. This results in a None msgid, which PTS used to do something (I don't know whether it was sane or not, no errors) with but which raises the rather obscure error above. I don't know if anything should be done here. Obviously it'd be nice if the error message was a bit nicer (i18:attributes specified attribute 'description', which did not exist on tag 'meta' in /standard_template.pt) but it's a pretty obscure error. If anyone with greater knowledge could implement the above without much pain, that'd be great. In any case, hopefully Google will catch this some time and save the next weary traveller who bumps into it a couple of hours ;-) cheers, 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 )
