Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Max M wrote: Anyone who complains about upgrades that takes a day should be forced to upgrade sites between Plone versions as punishment ;-) Anyone who choose to use Plone gets the punishment they deserve ;-) (sorry, I just really couldn't resist *grinz*) Chris - donning asbestos trousers right now! -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 as a reliable platform?!?
Lennart Regebro wrote: Well What is "a lot". Migrating software from 3.1 to 3.3 shouldn't take much more than a day or so, since the incompatibilities should be mostly BBB marked. Once you have figured out how do move one specific API use or ZCML statement changing the reast of the same type is quick. Anyone who complains about upgrades that takes a day should be forced to upgrade sites between Plone versions as punishment ;-) -- 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 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
On 9/5/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: > And therefore, we really need to make an > overview over all API changes from 3.0.0 so you can see what happened > (this in addition to the more detailed "whats new in vX" pages. > > Maybe somebody can start such a page somewhere, and we can fill it in > gradually? http://kpug.zwiki.org/WhatIsNewInZope33 That only covers 3.2->3.3. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Martijn Faassen wrote: Just to give some real data on this from someone who actually spent time updating applications: the churn is there, but it's not like this causes absolutely massive amounts of work, and the deprecation warnings are usually pretty helpful. OK. What's your experience with updating your Zope 3 projects, Chris? I don't have any, reason being that this constant churn has scared me off trying to use Zope 3 for anything "real". That said, since the churn is invading Zope two now, I'm slowly being forced to deal with it. Yeah, it's probably ok if you have a team of very experienced Zope deveopers who work on the codebase all the time, but what about smaller projects which get developed and then may not have any work done on them for a couple of years. If you want to track security releases, for example, then the customer has to find someone to make all the necessary changes so the code can track recent releases. That feels a bit smelly to me :-S Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Stephan Richter wrote: > On Wednesday 06 September 2006 12:05, Christian Theune wrote: >> So I'd probably estimate that the cost of upgrading was about 2-3k EUR >> for this one project (including the overhead of learning about the new >> changes.) > > Not bad, I think. Money wisely spent. Now your developers know the new API > that will save them multiples of that time in the long runI am talking > about the CA improvements here. You're right. On the first view this sounds like a lot, but it is a major upgrade, and I do embrace the changes to the CA. Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: OpenPGP digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
On Wednesday 06 September 2006 12:05, Christian Theune wrote: > So I'd probably estimate that the cost of upgrading was about 2-3k EUR > for this one project (including the overhead of learning about the new > changes.) Not bad, I think. Money wisely spent. Now your developers know the new API that will save them multiples of that time in the long runI am talking about the CA improvements here. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
On Wednesday 06 September 2006 11:41, Martijn Faassen wrote: > Just to give some real data on this from someone who actually spent time > updating applications: the churn is there, but it's like this causes > absolutely massive amounts of work, and the deprecation warnings are > usually pretty helpful. That has been my experience too. It usually takes a couple of hours; but I always think they are well-spent, only if I automatically learned the new features. ;-) Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Christian Theune wrote: What's your experience with updating your Zope 3 projects, Chris? I'll also jump in here: We had to try twice to upgrading a commercial project based on Zope 3.2 when using the 3.3 beta1, because so much stuff was actually broken in the release. As you suggest yourself, those problems were due to the beta status of the release. You can't blame these (packaging) bugs in Zope 3.3 on the deprecation process. And I agree that we should've made a beta2 much earlier; though you guys also could've simply used a checkout ot do the upgrading, like Martijn seems to have done. Beta2 took probably about one to two days to get all developers up to speed, make their code work and write generations. As Martijn said, generations seem to suggest you changed the data schema of your application as well. That can't be attributed to Zope's deprecation policy. So I'd probably estimate that the cost of upgrading was about 2-3k EUR for this one project (including the overhead of learning about the new changes.) I wonder what's there to "learn". If the deprecation warnings aren't clear enough, there's clearly something wrong with them. I tried really hard to make the warnings self-explanatory, so if they're missing something, please tell me so we can fix that. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Martijn Faassen wrote: Chris Withers wrote: Lennart Regebro wrote: I agree. And as long as you move from one version to the next, it's not a problems, since we have BBB-code. I'm sorry, I don't buy this. BBB code goes away, that means you have to deal with the churn at some point. It's the churn that's the problem... Just to give some real data on this from someone who actually spent time updating applications: the churn is there, but it's like this causes absolutely massive amounts of work, and the deprecation warnings are usually pretty helpful. I meant to write "it's *not* like this causes absolutely massive amounts of work". That said, in my case I didn't have to worry about upgrading content very much. Upgrading a ZODB is probably the most painful of it all - this is what Christian Theune seems to refer to with his reply mentioning generations. Upgrading content is also the most painful part of any Silva upgrade. I imagine it may be similarly difficult for upgrading, say, Plone, too. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Hi, Martijn Faassen wrote: > Chris Withers wrote: >> Lennart Regebro wrote: >>> I agree. And as long as you move from one version to the next, it's >>> not a problems, since we have BBB-code. >> >> I'm sorry, I don't buy this. BBB code goes away, that means you have >> to deal with the churn at some point. It's the churn that's the >> problem... > > Just to give some real data on this from someone who actually spent time > updating applications: the churn is there, but it's like this causes > absolutely massive amounts of work, and the deprecation warnings are > usually pretty helpful. > > It took me a few hours to get the DocumentLibrary code ported from Zope > 3.2 to Zope 3.3, for instance. > > I also was involved in making Schooltool run with Zope 3.3. This was > actually following the trunk, but there was a massive change when the > component-architecture refactoring + moving modules branch landed. I > think it took me a full afternoon, perhaps a day, to get up to speed on > that. Schooltool is an exceptionally massive Zope 3 project though > that's been developed for a long time, so probably not representative of > most codebases. Usually it should be easier. > > What's your experience with updating your Zope 3 projects, Chris? I'll also jump in here: We had to try twice to upgrading a commercial project based on Zope 3.2 when using the 3.3 beta1, because so much stuff was actually broken in the release. Beta2 took probably about one to two days to get all developers up to speed, make their code work and write generations. So I'd probably estimate that the cost of upgrading was about 2-3k EUR for this one project (including the overhead of learning about the new changes.) Christian -- gocept gmbh & co. kg - forsterstraße 29 - 06112 halle/saale - germany www.gocept.com - [EMAIL PROTECTED] - phone +49 345 122 9889 7 - fax +49 345 122 9889 1 - zope and plone consulting and development signature.asc Description: OpenPGP digital signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Chris Withers wrote: Lennart Regebro wrote: I agree. And as long as you move from one version to the next, it's not a problems, since we have BBB-code. I'm sorry, I don't buy this. BBB code goes away, that means you have to deal with the churn at some point. It's the churn that's the problem... Just to give some real data on this from someone who actually spent time updating applications: the churn is there, but it's like this causes absolutely massive amounts of work, and the deprecation warnings are usually pretty helpful. It took me a few hours to get the DocumentLibrary code ported from Zope 3.2 to Zope 3.3, for instance. I also was involved in making Schooltool run with Zope 3.3. This was actually following the trunk, but there was a massive change when the component-architecture refactoring + moving modules branch landed. I think it took me a full afternoon, perhaps a day, to get up to speed on that. Schooltool is an exceptionally massive Zope 3 project though that's been developed for a long time, so probably not representative of most codebases. Usually it should be easier. What's your experience with updating your Zope 3 projects, Chris? Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Chris Withers wrote: Philipp von Weitershausen wrote: Because it's clutter. I call BS on that :-S And because there should preferrably be only one way to do things. Indeed, but why break existing code unnecessarilly? Call it "BS" or "unnecessary". The reason why I think breaking existing code *eventually* is a good thing is still quoted here: Theuni was recently very confused about the difference between three different APIs that do exactly the same thing (registering a utility). If we had deprecated at least the most confusing one of them (ztapi) already, it would probably have been much clearer. Yeah, I see your point, but I agree with Jim's later in this thread ;-) I don't think my point and Jim's are exclusive. In fact, I agree with Jim. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Chris Withers wrote: Jim Fulton wrote: I don't think it's a matter of being "bad". It's a matter of learning from experience. We broke a lot of new ground in Zope 3 and often got things wrong because we hadn't done them before. Okay, we're 5 years down the line now, I think it's time to start differentiating between "good enough" and "bad" rather than polishing stuff that is basically okay by rewriting it ;-) +1 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Philipp von Weitershausen wrote: Because it's clutter. I call BS on that :-S And because there should preferrably be only one way to do things. Indeed, but why break existing code unnecessarilly? Theuni was recently very confused about the difference between three different APIs that do exactly the same thing (registering a utility). If we had deprecated at least the most confusing one of them (ztapi) already, it would probably have been much clearer. Yeah, I see your point, but I agree with Jim's later in this thread ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Jim Fulton wrote: I don't think it's a matter of being "bad". It's a matter of learning from experience. We broke a lot of new ground in Zope 3 and often got things wrong because we hadn't done them before. Okay, we're 5 years down the line now, I think it's time to start differentiating between "good enough" and "bad" rather than polishing stuff that is basically okay by rewriting it ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Lennart Regebro wrote: I agree. And as long as you move from one version to the next, it's not a problems, since we have BBB-code. I'm sorry, I don't buy this. BBB code goes away, that means you have to deal with the churn at some point. It's the churn that's the problem... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Philipp von Weitershausen wrote: No, only if you want to upgrade to newer Zope versions. And even then you have a year, not half a year, to upgrade. This deprecation period was voted on once and I think it's a good compromise. I think the deprecation period is fine, it's the amount of deprecation and code churn that's the issue. You make it sound like we change every single bit of Zope 3 in every release. It does feel like that sometimes ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Stephan Richter wrote: That's what we do. In fact, I am not even using releases. As soon as a change happens in the trunk, I migrate the code base I am working on and schedule updates for the other code I have. Normal people don't have time or energy to track the trunk. Nor should they have to... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 as a reliable platform?!?
On 9/5/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: So, in the end, a new style guide would only apply to new packages or new APIs, which are mostly outside of the Zope 3 core nowadays anyways. Yes; this I understand. My point was that there's no reason to change the Z3 style guide, even just for new code/packages. Sounds like that's what was agreed on in #zope3-dev as well, so we're ok. -Fred -- Fred L. Drake, Jr. "Every sin is the result of a collaboration." --Lucius Annaeus Seneca ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 as a reliable platform?!?
Fred Drake wrote: On 9/5/06, Dieter Maurer <[EMAIL PROTECTED]> wrote: When I remember right, then I read an important sentence in the Python style guide -- something along the lines: "This is a guide: you should follow it but there are occasions when you may not do so with good reasons." I don't know if this means you agree or not. I don't think this paragraph really applies to this discussion. Jim suggested that we change the Z3 style guide, and I'm suggesting that that's counter-productive. Clearly, existing code isn't affected immediately, and APIs can't be changed anyway. Jim suggested changing the style guide to match PEP008, but PEP008 also says that existing code should preferrably not be changed and that existing APIs should be kept consistent. So, in the end, a new style guide would only apply to new packages or new APIs, which are mostly outside of the Zope 3 core nowadays anyways. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 as a reliable platform?!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stephan Richter wrote: > On Tuesday 05 September 2006 07:39, Marcus J. Ertl wrote: >> And I realy don't know, what I would think, if I had Zope3 in use on a >> productiv system? Schould I really change all packages each half a >> year to reflect changes in Zope3? > > That's what we do. In fact, I am not even using releases. As soon as a change > happens in the trunk, I migrate the code base I am working on and schedule > updates for the other code I have. And if you do that, then life is not that > bad. In my opinion it is more difficult to upgrade between major releases. That is a damning indictment of our process, if so. We should be managing our release process such that the "normal" path is straightforward (trivial upgrades between third dot releases to fix bugs, well-documented upgrades between second-dot releases at well-planned intervals to take advantage of new features). We should make this so even at the cost of making life harder on the core developers. Unless, of course, we don't expect anyone but the core developers ever to run Zope3 in production environments (which is very nearly the case today). Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE/bQM+gerLs4ltQ4RAuc8AJwLhm/0O31jj+YzulX3hvJ5+gd7KQCglanD tf48bDO+aNHYf6gmcSewwK8= =BvhO -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Lennart Regebro wrote: On 9/5/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: Because they'll go away. Why? Because it's clutter. And because there should preferrably be only one way to do things. If we left all the old ways around indefinitely, we'd have code that uses two or more ways of doing the same thing all over the place. It would set bad examples, to begin with. Theuni was recently very confused about the difference between three different APIs that do exactly the same thing (registering a utility). If we had deprecated at least the most confusing one of them (ztapi) already, it would probably have been much clearer. I agree. And as long as you move from one version to the next, it's not a problems, since we have BBB-code. It does become a problem when you skip versions, though. And therefore, we really need to make an overview over all API changes from 3.0.0 so you can see what happened (this in addition to the more detailed "whats new in vX" pages. Maybe somebody can start such a page somewhere, and we can fill it in gradually? http://kpug.zwiki.org/WhatIsNewInZope33 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
On 9/5/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote: Because they'll go away. Why? Because it's clutter. And because there should preferrably be only one way to do things. If we left all the old ways around indefinitely, we'd have code that uses two or more ways of doing the same thing all over the place. It would set bad examples, to begin with. Theuni was recently very confused about the difference between three different APIs that do exactly the same thing (registering a utility). If we had deprecated at least the most confusing one of them (ztapi) already, it would probably have been much clearer. I agree. And as long as you move from one version to the next, it's not a problems, since we have BBB-code. It does become a problem when you skip versions, though. And therefore, we really need to make an overview over all API changes from 3.0.0 so you can see what happened (this in addition to the more detailed "whats new in vX" pages. Maybe somebody can start such a page somewhere, and we can fill it in gradually? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Tuesday, September 5, 2006, 2:06:09 PM, you wrote: Hello, > Marcus J. Ertl wrote: > I think you're over-dramatizing. Nearly all of the code in the example > application of my book still works with Zope 3.2, so it can't be that bad. Hmm, for the simple things, it's still good, right. But much of the "trickier things", not mentioned in the book, aren't that good! Perhabs it's silly me, forgetting to much of what I have learned before? But each version of Zope I try give me the feeling of starting from a new! > No, only if you want to upgrade to newer Zope versions. I think of upgrading as a "must" on public reachable systems, because of security fixes. Maybe there are no at the moment, but when they come, upgrades must go fast and smooth. Without recoding. > Wow, that's a lot of exclamation marks. Oh, sorry! Don't want do call out loud! > You make it sound like we change every single bit of Zope 3 in every > release. We all know that's not the case. Applications that use Zope 3 > components such as Plone 2.5, for example, work both with Zope X3 3.0 > packages and Zope 3.2 packages. So again, it can't be that bad. Then, I must have done something wrong. But if I look at the changelogs, all the ZCML-Changes, and API changes, it can't be that few. If I want to get on a state without any deprecation warnings, I have more to do then I like. It's very good to see, Zope3 ist developing, but now it's time, to get it stable too! Perhabs I'm not the right audience for Zope3? I'm working for a small company, doing the web stuff is just an unimportant part of my work. So each change I have to do is one to much. I would even love to use Zope for my privat homepage. But it's hobby, there's not much time to do even small changes. For larger environments (like Lexware) this may be no problem, there is time and money for incooperating changes in homemade packages. Bye Marcus -- Cat, n.: Lapwarmer with built-in buzzer. LARP-Welt, das LARP-Portal: http://www.larp-welt.de/ Coloful-Sky, meine kleine Drachenseite: http://www.colorful-sky.de/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
On Sep 5, 2006, at 5:21 AM, Chris Withers wrote: I refuse to believe that all the Zope 3 developers are that bad that they get it wrong in ways which need deprecating so often ;-) I don't think it's a matter of being "bad". It's a matter of learning from experience. We broke a lot of new ground in Zope 3 and often got things wrong because we hadn't done them before. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
On Tuesday 05 September 2006 07:39, Marcus J. Ertl wrote: > And I realy don't know, what I would think, if I had Zope3 in use on a > productiv system? Schould I really change all packages each half a > year to reflect changes in Zope3? That's what we do. In fact, I am not even using releases. As soon as a change happens in the trunk, I migrate the code base I am working on and schedule updates for the other code I have. And if you do that, then life is not that bad. In my opinion it is more difficult to upgrade between major releases. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
On Tuesday 05 September 2006 05:21, Chris Withers wrote: > > That is unfortunate example of obviously bad deprecation. Deprecation is > > hard and it requires a great deal of thought. But it can be manageable > > in many cases. > > Still feels like there's too much fo it happening in the Zope 3 world. > > I refuse to believe that all the Zope 3 developers are that bad that > they get it wrong in ways which need deprecating so often ;-) No, we not so bad programmers; we are just better at admitting mistakes and adjusting to new requirements. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
On Sep 2, 2006, at 1:03 PM, Tres Seaver wrote: Insulating non-core developers from this kind of churn is what the "façade" module 'zapi' was orignally for. That isn't my recollection. zapi was introduced as an experiment to make imports simpler. This was done in the days when we used contxt wrappers heavily and there were a whole lot of context-wrapper related APIs that had to be used. When we got rid of the context wrappers, there were fw methods in zapi that were used anymore. Most of those were the component APIs and getting those from zope.component rather than ztapi made the code less Zope dependent, which was a good thing. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 as a reliable platform?!?
Marcus J. Ertl wrote: tests. We *did* have changes that generated deprecation warnings. But that's something else. Not really, that for me is a non-backwards-compatible change, 'cos it requires me to rethink and recode, if not now then at some point in the future... Me too! That's a real problem for me too! Each time I revisit Zope3, it has changed very dramaticly! Old code, I wrote for learning Zope3 didn't work at all, I have do relearn Zope3 for new! I think you're over-dramatizing. Nearly all of the code in the example application of my book still works with Zope 3.2, so it can't be that bad. And I realy don't know, what I would think, if I had Zope3 in use on a productiv system? Schould I really change all packages each half a year to reflect changes in Zope3? No, only if you want to upgrade to newer Zope versions. And even then you have a year, not half a year, to upgrade. This deprecation period was voted on once and I think it's a good compromise. Don't get me wronge, Zope3 is realy great, it has many good ideas, a clean design, IMHO it is the best application server out there. But it still changes to much to be usefull for smaller companies, or even people like me, for someone just want to use it for hobby! I would not consider the API as stable! Two much changes! Shure, they all make things better, but it isn't stable! Wow, that's a lot of exclamation marks. You make it sound like we change every single bit of Zope 3 in every release. We all know that's not the case. Applications that use Zope 3 components such as Plone 2.5, for example, work both with Zope X3 3.0 packages and Zope 3.2 packages. So again, it can't be that bad. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Tuesday, September 5, 2006, 1:27:12 PM, you wrote: Hello! I was interessted in Zope3 at the early beginning, at still revisit it each half a year! But... >>> tests. We *did* have changes that generated deprecation warnings. But >>> that's something else. >> Not really, that for me is a non-backwards-compatible change, 'cos it >> requires me to rethink and recode, if not now then at some point in the >> future... Me too! That's a real problem for me too! Each time I revisit Zope3, it has changed very dramaticly! Old code, I wrote for learning Zope3 didn't work at all, I have do relearn Zope3 for new! And I realy don't know, what I would think, if I had Zope3 in use on a productiv system? Schould I really change all packages each half a year to reflect changes in Zope3? Don't get me wronge, Zope3 is realy great, it has many good ideas, a clean design, IMHO it is the best application server out there. But it still changes to much to be usefull for smaller companies, or even people like me, for someone just want to use it for hobby! I would not consider the API as stable! Two much changes! Shure, they all make things better, but it isn't stable! Sorry! Just my two cents! Bye Marcus -- Nothing is illegal until you get caught. LARP-Welt, das LARP-Portal: http://www.larp-welt.de/ Coloful-Sky, meine kleine Drachenseite: http://www.colorful-sky.de/ ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
> Why? Because they'll go away. Why? Because it's clutter. And because there should preferrably be only one way to do things. If we left all the old ways around indefinitely, we'd have code that uses two or more ways of doing the same thing all over the place. It would set bad examples, to begin with. +1 I'm not a zope3 core developer, just a zope3 newbie and one of the things that's annoyed me the most is the confusing feeling I get that there are different ways to apparently do the same thing. Kill kill kill all the duplicates! -- Peter Bengtsson, work www.fry-it.com home www.peterbe.com hobby www.issuetrackerproduct.com ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Chris Withers wrote: Philipp von Weitershausen wrote: tests. We *did* have changes that generated deprecation warnings. But that's something else. Not really, that for me is a non-backwards-compatible change, 'cos it requires me to rethink and recode, if not now then at some point in the future... being, just pointing to the zope packages via deferred imports. Of course, the deferred imports generate deprecation warnings when executed. Why? Because they'll go away. Why? Because it's clutter. And because there should preferrably be only one way to do things. If we left all the old ways around indefinitely, we'd have code that uses two or more ways of doing the same thing all over the place. It would set bad examples, to begin with. Theuni was recently very confused about the difference between three different APIs that do exactly the same thing (registering a utility). If we had deprecated at least the most confusing one of them (ztapi) already, it would probably have been much clearer. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Chris Withers wrote: Philipp von Weitershausen wrote: That is unfortunate example of obviously bad deprecation. Deprecation is hard and it requires a great deal of thought. But it can be manageable in many cases. Still feels like there's too much fo it happening in the Zope 3 world. I refuse to believe that all the Zope 3 developers are that bad that they get it wrong in ways which need deprecating so often ;-) I think there are many things that we didn't get right the first time, or even the second time. Jim always says that when you don't really understand things, you tend to overengineer them. I think that's what happened a lot of the times. Zope 3 was pioneer land and we needed time to understand how it works best. Nearly all of the large refactorings that Zope 3 had in the last couple of years were major simplifications, such as a flatter package structure, an easier Component Architecture, an easier local Component Architecture, a simpler approach to skinning, etc. I think if the API conservatism gets too high, we'll end up with something like Zope 2 again and its unmanageable constructs like the one you presented earlier in this thread. We'll need to find the right balance. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Philipp von Weitershausen wrote: tests. We *did* have changes that generated deprecation warnings. But that's something else. Not really, that for me is a non-backwards-compatible change, 'cos it requires me to rethink and recode, if not now then at some point in the future... being, just pointing to the zope packages via deferred imports. Of course, the deferred imports generate deprecation warnings when executed. Why? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Dieter Maurer wrote: But you probably would not prefer if these "straight-forward APIs" were continously changing. I prefer a slightly suboptimal stable API over one that is optimized in each version in a non backward compatible way. EXACTLY! I do see the gain of moving out general purpose functions from "zope.app" into "zope". But, I would do it in a backward compatible way -- even when "zope.app" then contains quite a few trivial packages redirecting to the relocated packages. Also true... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Philipp von Weitershausen wrote: That is unfortunate example of obviously bad deprecation. Deprecation is hard and it requires a great deal of thought. But it can be manageable in many cases. Still feels like there's too much fo it happening in the Zope 3 world. I refuse to believe that all the Zope 3 developers are that bad that they get it wrong in ways which need deprecating so often ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 as a reliable platform?!?
Dieter Maurer wrote: Philipp von Weitershausen wrote at 2006-9-4 16:49 +0200: ... I for one prefer exceptions over manual error handling. And I prefer straight-forward APIs over unnecessarily complicated constructs. But you probably would not prefer if these "straight-forward APIs" were continously changing. I prefer a slightly suboptimal stable API over one that is optimized in each version in a non backward compatible way. Backwards incompatible changes are bad, I absolutely agree. I don't think we've done many BBB incompatible changes in the past, though, thanks to the "checkin" police who's watching over checkins and the tests. We *did* have changes that generated deprecation warnings. But that's something else. I do see the gain of moving out general purpose functions from "zope.app" into "zope". But, I would do it in a backward compatible way -- even when "zope.app" then contains quite a few trivial packages redirecting to the relocated packages. This is how we did it. The packages remain in zope.app for the time being, just pointing to the zope packages via deferred imports. Of course, the deferred imports generate deprecation warnings when executed. Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 as a reliable platform?!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dieter Maurer wrote: > Philipp von Weitershausen wrote at 2006-9-4 16:49 +0200: >> ... >> I for one prefer exceptions over manual error handling. And I prefer >> straight-forward APIs over unnecessarily complicated constructs. > > But you probably would not prefer if these "straight-forward APIs" > were continously changing. > I prefer a slightly suboptimal stable API over one that is > optimized in each version in a non backward compatible way. > > > I do not want to say that this is happening in Zope3 land. > I do not yet use Zope3 in earnest and see what is happening > more from the mailing list than from my own experience. > >>> So, for me, it would be great if developers would take more time to >>> weigh up the "what does this new feature or refactoring bring" against >>> the "how much of a PITA is it going to be for everyone else to relearn >>> this"... > > I like new features but often could not see the gain of refactorings. > Many refactorings in Zope 2 land were just silly, e.g. whitespace > refactoring such as: > > from X.Y.Z import a, b, c > > refactored to > > from X.Y.Z import a > from X.Y.Z import b > from X.Y.Z import c I might be the perpetrator, but surely such a change has no impact on code which imports the module. Does this affect you because it breaks patches you maintain? > I do see the gain of moving out general purpose functions from > "zope.app" into "zope". But, I would do it in a backward > compatible way -- even when "zope.app" then contains quite > a few trivial packages redirecting to the relocated packages. As I said earlier, I actually *like* the insulation provided by a "façade" package: it leaves the "internal" location free to change wildly, without propagating the churn from that change out to those who are clients of the code. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE/HSr+gerLs4ltQ4RAiLGAJ490R2aiQAAeuVELa90QzjLNYszxwCfa4Bq ccve4CXAHlKBRgoTl+FVYuY= =BPQx -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Philipp von Weitershausen wrote at 2006-9-4 16:49 +0200: > ... >I for one prefer exceptions over manual error handling. And I prefer >straight-forward APIs over unnecessarily complicated constructs. But you probably would not prefer if these "straight-forward APIs" were continously changing. I prefer a slightly suboptimal stable API over one that is optimized in each version in a non backward compatible way. I do not want to say that this is happening in Zope3 land. I do not yet use Zope3 in earnest and see what is happening more from the mailing list than from my own experience. >> So, for me, it would be great if developers would take more time to >> weigh up the "what does this new feature or refactoring bring" against >> the "how much of a PITA is it going to be for everyone else to relearn >> this"... I like new features but often could not see the gain of refactorings. Many refactorings in Zope 2 land were just silly, e.g. whitespace refactoring such as: from X.Y.Z import a, b, c refactored to from X.Y.Z import a from X.Y.Z import b from X.Y.Z import c I do see the gain of moving out general purpose functions from "zope.app" into "zope". But, I would do it in a backward compatible way -- even when "zope.app" then contains quite a few trivial packages redirecting to the relocated packages. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
baiju m-2 wrote: > > This document is maintained as a wiki page, so anyone can edit it. > http://kpug.zwiki.org/WhatIsNewInZope33 This is great! It's probably exactly what we need. Martin -- View this message in context: http://www.nabble.com/Zope-3-as-a-reliable-platform-%21--tf2207550.html#a6137481 Sent from the Zope3 - dev forum at Nabble.com. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 as a reliable platform?!?
Chris Withers wrote:
For me, the irony is that when Zope 2's development process was at its
worst, this problem was at its best as there was so little change,
enabling people to gather more knowledge without having to stop to
re-learn their old knowledge.
It is my impression that it was Zope 2's obscenity towards API stability
which provoked the Zope 3 rewrite. We are only doing now what could have
been done (over the course of 4 to 5 years) much earlier. After all, the
"new religion" idea (Component Architecture) dates as far back as 2001.
Sure, having to do:
to_change = {}
if obj.hasProperty(x):
to_change[x]=x_value
else:
obj.manage_addProperty(x,x_value,x_type)
obj.manage_changeProperties(**to_change)
...and remembering that manage_editProperties is BAD isn't that pretty,
but it's been stable for so long that I can write it from memory now,
and that's a big win.
Well, prettiness (or rather ugliness) aside, I'm having a problem
letting that argument count. C programmers could easily use the same
line of argumentation to say that manual error handling via return codes
may be more complicated than dealing with exceptions, but they've been
doing it for so many years that they can write it from memory now.
I for one prefer exceptions over manual error handling. And I prefer
straight-forward APIs over unnecessarily complicated constructs.
So, for me, it would be great if developers would take more time to
weigh up the "what does this new feature or refactoring bring" against
the "how much of a PITA is it going to be for everyone else to relearn
this"...
Agreed.
Philipp
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 as a reliable platform?!?
Dieter Maurer wrote: Tres Seaver wrote at 2006-9-2 13:03 -0400: ... I'm OK with having "in-tree" code not use zapi, but I don't see a win in propagating all the mess out to the rest of the world. I'll also note that "janitorial deprecation" is way too common in the tree today: people decide they don't like the name a method was given, and deprecate it in favor of the "better" name. The ongoing cost of that deprecation is then borne by everyone else. I have the feeling that almost the complete Python community is abusing deprecations. I was hit by deprecations in the "email" package: The deprecation told me to use a different method, but this method was not a full replacement for the old one and failed in my use case. In the next release, my old method was removed -- but fortunately, I know how to recreate methods and silence stupid deprecations. That is unfortunate example of obviously bad deprecation. Deprecation is hard and it requires a great deal of thought. But it can be manageable in many cases. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Tres Seaver wrote: I'm OK with having "in-tree" code not use zapi, but I don't see a win in propagating all the mess out to the rest of the world. I'll also note that "janitorial deprecation" is way too common in the tree today: people decide they don't like the name a method was given, and deprecate it in favor of the "better" name. The ongoing cost of that deprecation is then borne by everyone else. +10 Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
>>> What I'm worried about is that we have to come up with a *MUCH* better >>> way to tell people "What is *the single* way to do this or that?" and >>> "Hey, we used to do it *this* way, but HEADSUP, now it's *that* way!". >> I'd welcome any constructive suggestions. I, for one, suggested a >> "What's new in Zope 3.X" article. Baiju M started such an article >> (google it) and I contributed a few things here and there to it. (Thanks >> to Baiju, btw!!!) > > Ah. I think I saw that on the list once as a work in progress or > proposal. I hadn't had time back than to look into this. I just found > the URL and skimmed over it. I think this is probably exactly what I > would love to see for major releases. I think I'll start translating > that to german until the final release of 3.3. Perhaps we should get the English version up to shape first. I don't think it's completely finished yet. This document is maintained as a wiki page, so anyone can edit it. http://kpug.zwiki.org/WhatIsNewInZope33 I welcome your changes, especially this section: "Local component management simplification". Regards, Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Tres Seaver wrote at 2006-9-2 13:03 -0400: > ... >I'm OK with having "in-tree" code not use zapi, but I don't see a win in >propagating all the mess out to the rest of the world. I'll also note >that "janitorial deprecation" is way too common in the tree today: >people decide they don't like the name a method was given, and deprecate >it in favor of the "better" name. The ongoing cost of that deprecation >is then borne by everyone else. I have the feeling that almost the complete Python community is abusing deprecations. I was hit by deprecations in the "email" package: The deprecation told me to use a different method, but this method was not a full replacement for the old one and failed in my use case. In the next release, my old method was removed -- but fortunately, I know how to recreate methods and silence stupid deprecations. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
Christian Theune wrote: I partially agree on that. This obviously is one issue if you're living on the trunk or a pre-release branch. It's not clear when to re-read, so following the checkins is required here. Yup. But as you said, that's because you're living on the edge. That's probably my fault because I didn't digg deep enough to verify the truth whether zope.component.provideUtility works against the thread local component registry or not. Dig deep enough? How about digging ALL THE WAY (sorry, being ironic here) to zope.component.interfaces and reading the declaration of provideUtility: def provideUtility(component, provides=None, name=u''): """Register a utility globally ... Again, you're right. The information is there, but I didn't *expect* that the docstring contains any important information (for me at this point in time and when I was looking for the correct signature of the method). If had expected that change, I would probably have read the docstring. What are you saying here? You don't expect interfaces to "contain any important information"? I hope I'm misunderstand you here... In fact, I think I am because I don't really understand what you're trying to say with this paragraph ;). How is that not clear? If you don't read interfaces for what we provide them (declarative documentation), then I'm running out of ideas on how to satisfy you. I read them. This is a bit of psychology turning against me here, I was looking at the line above, but failed to read the line below because my expectation didn't include that the docstring has any additional information to what I was looking for. Sigh, if only we could make things appear in red :). Seriously, you said you were looking at the method signature but complaining you had to dig deep to find out about the function's behaviour... That seems totally unreasonable to me. By the way, a lot of time we have to rely on docstrings to document behaviour. Let's take class IAttributeAnnotatable(IAnnotatable): ... Without a docstring, this teeny-weeny declaration is absolutely meaningless. What I'm worried about is that we have to come up with a *MUCH* better way to tell people "What is *the single* way to do this or that?" and "Hey, we used to do it *this* way, but HEADSUP, now it's *that* way!". I'd welcome any constructive suggestions. I, for one, suggested a "What's new in Zope 3.X" article. Baiju M started such an article (google it) and I contributed a few things here and there to it. (Thanks to Baiju, btw!!!) Ah. I think I saw that on the list once as a work in progress or proposal. I hadn't had time back than to look into this. I just found the URL and skimmed over it. I think this is probably exactly what I would love to see for major releases. I think I'll start translating that to german until the final release of 3.3. Perhaps we should get the English version up to shape first. I don't think it's completely finished yet. Those things deserver a lot more visibility than they get right now. I agree. Hopefully the new zope.org website will handle that. I've volunteered to look into that. And I agree. Again, maybe I'm only hitting this all the time because I'm living most of my live on pre-release-branches or the trunk, but still. I think if Zope 3 shall be used by many people, this is a major obstacle. Whether it's many or just few people... RTFMing is all it takes for them to get started. I've written a whole friggen book for them, for cryin' out loud :) Sure, but that doesn't hold up for 3.3 Hey, unfair! I'm working on a 2nd edition! Additionally RTFMing with Zope is hard because: - - there is no TFM APIDoc can be considered *a* FM. It includes all the major .txt files and you can browse APIs and look at docstrings. I think that's pretty darn good. - - I (and I think quite some other people too) don't even have the expectation anymore to find something in the FM because e.g. "The Zope book" had only two or three sentences that I came back to (via google) for references and was always barely up to date. That's a historical problem that we can't do anything about except improve in the future. I think we already have improved, but we can't rewire people's heads. Your brain seems to be wired a lot towards Zope 2 and its bad state of documentation :). - - When I don't know that something changed or is different than I think (and it doesn't seem to behave wrong in the first place) I don't start looking into the code. And you shouldn't have to. Remember the other day when you barfed at me about the directive gone? You barfed at me without even having googled the proposal. I'm sure you could've found it easily. Again, I agree that I could be much more on the hook if I - - read all proposals - - read all checkins - - follow and participate in all zope3-dev discussions That is probably only necessary if you're running bleeding edge (then again, yo
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
One thing that would be good is an overview of all API changes that have happened and in which version it happened. I guess that would be quite a bit of work, but a page like that would be very helpful if you wanna port an old app forward and skip a couple of versions. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Zope 3 as a reliable platform?!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Christian Theune wrote: > Hi, > > this is a rant. I don't want to be destructive or disruptive, but I feel > like I need to turn this up right now. > > Let's start with something positive: I love Zope 3. I do. I know it > almost since the beginning and I see how it works out. > > But to be honest, I too often get the feeling that something in the > process is wrong and we are failing to acknowledge it or work on it. > > I think we make it way to hard for people who want to use Zope 3 as > developers making applications with Zope 3. > > Why? Because we keep changing stuff and don't tell people in VERY LARGE > LETTERS about it. > > What worries me most is that I, although I'm contributing to Zope 3 > every now and then, even fall into this quite often and I'm getting > tired of it. > > I can't read every proposal or every commit message or every post on the > mailing list. I try to, but I can't. And I think that normal developers > shouldn't have to try to. > > When Philipp explained the zope.component thing in an earlier post I got > annoyed again because I was relying on information that obviously was > false. That's probably my fault because I didn't digg deep enough to > verify the truth whether zope.component.provideUtility works against the > thread local component registry or not. When I saw that > zope.*app*.component does that I got scared because it's so similar and > maybe hard to distinguish. > > What I'm worried about is that we have to come up with a *MUCH* better > way to tell people "What is *the single* way to do this or that?" and > "Hey, we used to do it *this* way, but HEADSUP, now it's *that* way!". > > Again, maybe I'm only hitting this all the time because I'm living most > of my live on pre-release-branches or the trunk, but still. > > I think if Zope 3 shall be used by many people, this is a major obstacle. > > I hope I don't annoy anybody, but I had to get that off my mind. Insulating non-core developers from this kind of churn is what the "façade" module 'zapi' was orignally for. Folks who were writing application code would have a reliable location in which to find the "public" API, and would not be exposed to the deprecation dance caused by tree refactorings: instead, the person who did the tree refactoring would just adjust the 'zapi' imports, and everyone else's code would Just Work (tm). That module would also be the logical place for lots of the BBB code now scattered around the tree. I'm OK with having "in-tree" code not use zapi, but I don't see a win in propagating all the mess out to the rest of the world. I'll also note that "janitorial deprecation" is way too common in the tree today: people decide they don't like the name a method was given, and deprecate it in favor of the "better" name. The ongoing cost of that deprecation is then borne by everyone else. Tres. - -- === Tres Seaver +1 202-558-7113 [EMAIL PROTECTED] Palladion Software "Excellence by Design"http://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE+blG+gerLs4ltQ4RAhEEAJ9/CLYNqlrPFWh+3UnPwaraMMLs7QCfVYYp 1fiertpiMU2/pFhAe6ovbQk= =esi5 -END PGP SIGNATURE- ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Zope 3 as a reliable platform?!?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, Philipp von Weitershausen wrote: > Reading the changelog should be enough. I partially agree on that. This obviously is one issue if you're living on the trunk or a pre-release branch. It's not clear when to re-read, so following the checkins is required here. >> I try to, but I can't. And I think that normal developers >> shouldn't have to try to. > > They read the changelog. That's why we do it, right? If no-one reads it > and doesn't find it useful, we might just as well not do it at all. It's definitely detailed and all the information is in there, however, the change log for Zope 3.3 in comparison to the last 3.2 release is approximately 410 lines mostly 2-3 liners, so about 90-100 change entries. That's a lot of information that nobody can read and instantly remember. I'd love to see a more weighted report for people who come from 3.3 (see below) >> When Philipp explained the zope.component thing in an earlier post I got >> annoyed again because I was relying on information that obviously was >> false. > > You were just making a wrong assumption. You THOUGHT things were like X > but they were Y. I don't know what led you to the assumption, but it > can't be Zope's fault if you make it :). > >> That's probably my fault because I didn't digg deep enough to >> verify the truth whether zope.component.provideUtility works against the >> thread local component registry or not. > > Dig deep enough? How about digging ALL THE WAY (sorry, being ironic > here) to zope.component.interfaces and reading the declaration of > provideUtility: > > def provideUtility(component, provides=None, name=u''): > """Register a utility globally > ... Again, you're right. The information is there, but I didn't *expect* that the docstring contains any important information (for me at this point in time and when I was looking for the correct signature of the method). If had expected that change, I would probably have read the docstring. > How is that not clear? If you don't read interfaces for what we provide > them (declarative documentation), then I'm running out of ideas on how > to satisfy you. I read them. This is a bit of psychology turning against me here, I was looking at the line above, but failed to read the line below because my expectation didn't include that the docstring has any additional information to what I was looking for. >> When I saw that >> zope.*app*.component does that I got scared because it's so similar and >> maybe hard to distinguish. > > Is this a rant about our development process or about the complexity of > zope.app.component? It's all about process right now. I can deal with the complexity of zope.app.component. I think. ;) >> What I'm worried about is that we have to come up with a *MUCH* better >> way to tell people "What is *the single* way to do this or that?" and >> "Hey, we used to do it *this* way, but HEADSUP, now it's *that* way!". > > I'd welcome any constructive suggestions. I, for one, suggested a > "What's new in Zope 3.X" article. Baiju M started such an article > (google it) and I contributed a few things here and there to it. (Thanks > to Baiju, btw!!!) Ah. I think I saw that on the list once as a work in progress or proposal. I hadn't had time back than to look into this. I just found the URL and skimmed over it. I think this is probably exactly what I would love to see for major releases. I think I'll start translating that to german until the final release of 3.3. Those things deserver a lot more visibility than they get right now. Hopefully the new zope.org website will handle that. >> Again, maybe I'm only hitting this all the time because I'm living most >> of my live on pre-release-branches or the trunk, but still. >> >> I think if Zope 3 shall be used by many people, this is a major obstacle. > > Whether it's many or just few people... RTFMing is all it takes for them > to get started. I've written a whole friggen book for them, for cryin' > out loud :) Sure, but that doesn't hold up for 3.3 and I don't carry it around with me. Additionally RTFMing with Zope is hard because: - - there is no TFM - - I (and I think quite some other people too) don't even have the expectation anymore to find something in the FM because e.g. "The Zope book" had only two or three sentences that I came back to (via google) for references and was always barely up to date. - - When I don't know that something changed or is different than I think (and it doesn't seem to behave wrong in the first place) I don't start looking into the code. Again, I agree that I could be much more on the hook if I - - read all proposals - - read all checkins - - follow and participate in all zope3-dev discussions So, I agree that "normal" developers might not have the same problem as I do, because they get the benefit of having a fixed point in time where they get the release and then just read the change log and can be hap
[Zope3-dev] Re: Zope 3 as a reliable platform?!?
Christian Theune wrote: But to be honest, I too often get the feeling that something in the process is wrong and we are failing to acknowledge it or work on it. I think we make it way to hard for people who want to use Zope 3 as developers making applications with Zope 3. Why? Because we keep changing stuff and don't tell people in VERY LARGE LETTERS about it. Huh? When I changed stuff, I wrote proposals, asked for feedback, provided deprecation messages and CHANGES.txt entries... What else do you want? What worries me most is that I, although I'm contributing to Zope 3 every now and then, even fall into this quite often and I'm getting tired of it. I can't read every proposal or every commit message or every post on the mailing list. Reading the changelog should be enough. I try to, but I can't. And I think that normal developers shouldn't have to try to. They read the changelog. That's why we do it, right? If no-one reads it and doesn't find it useful, we might just as well not do it at all. When Philipp explained the zope.component thing in an earlier post I got annoyed again because I was relying on information that obviously was false. You were just making a wrong assumption. You THOUGHT things were like X but they were Y. I don't know what led you to the assumption, but it can't be Zope's fault if you make it :). That's probably my fault because I didn't digg deep enough to verify the truth whether zope.component.provideUtility works against the thread local component registry or not. Dig deep enough? How about digging ALL THE WAY (sorry, being ironic here) to zope.component.interfaces and reading the declaration of provideUtility: def provideUtility(component, provides=None, name=u''): """Register a utility globally ... How is that not clear? If you don't read interfaces for what we provide them (declarative documentation), then I'm running out of ideas on how to satisfy you. When I saw that zope.*app*.component does that I got scared because it's so similar and maybe hard to distinguish. Is this a rant about our development process or about the complexity of zope.app.component? What I'm worried about is that we have to come up with a *MUCH* better way to tell people "What is *the single* way to do this or that?" and "Hey, we used to do it *this* way, but HEADSUP, now it's *that* way!". I'd welcome any constructive suggestions. I, for one, suggested a "What's new in Zope 3.X" article. Baiju M started such an article (google it) and I contributed a few things here and there to it. (Thanks to Baiju, btw!!!) Again, maybe I'm only hitting this all the time because I'm living most of my live on pre-release-branches or the trunk, but still. I think if Zope 3 shall be used by many people, this is a major obstacle. Whether it's many or just few people... RTFMing is all it takes for them to get started. I've written a whole friggen book for them, for cryin' out loud :) I hope I don't annoy anybody, but I had to get that off my mind. Sure. Grab a cool beer, cool off and start improving the situation tomorrow (and tell me how so I can do it in the future too) :) Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
