April 2004 - Zope-Dev

RE: [Zope-dev] Reflections on the Zope 2 to Zope 3 transition
by Jean-Francois.Doyon＠CCRS.NRCan.gc.ca 22 Apr '04

22 Apr '04

I know I'm new here, but I think this may work to my benefit in this case ... +1 on everything Jim just said! Unlike some others it seems, I look at Zope almost uniquely as "framework" for building web applications. An API or SDK if you will. As such, I think it's internal software desing and architecture has to be priority number one. Otherwise anything you layer on top of it is doomed from the start. To those people that just want an application server that works, such as CPS or Plone, this should still be a very good thing. Having a much higher quality base will mean better end-user usable products in the long run ... Personally, I'm fully expecting to do a full re-design of my code for Zope 3. And that's fine, I like the idea. Given the radical changes in design, I would want to make sure my applications/products take full advantage of the new features. I'm actually counting on several of them to do things like proper multi-lingual support, workflow and publishing control. I might actually NOT bother with migrating slowly through 2.8 and 2.9, that seems dangerous to me ... the potential for kludges and nasty work arounds seems great. We'll have to see. Can't wait for ExtensionClass to go though!! In the mean time, I'll be trying to give back to the Zope community by working on my Subversion storage idea :) Thanks, J.F. -----Original Message----- From: zope-dev-bounces(a)zope.org [mailto:zope-dev-bounces@zope.org]On Behalf Of Jim Fulton Sent: April 22, 2004 10:47 AM To: zope-dev(a)zope.org Cc: zope3-dev(a)zope.org Subject: [Zope-dev] Reflections on the Zope 2 to Zope 3 transition Philipp von Weitershausen wrote: > Jim Fulton wrote: > >>> 2. Especially Andreas expressed his worries about the current release >>> policy in Zope 2 and its future regarding maintainance and support. I >>> have to say that I share some of his skepticism regarding Zope 2. I >>> personally have never fully understood ZC's reasons for the release >>> roadmap as it is. I might not see the big picture, but I know I would >>> have done it differently. I've always tried to make that clear in the >>> past. >> >> >> I'm surprised to read this. Could you be more specific about your >> concerns? > > > I should have said "the release roadmap as it WAS". I was very skeptical > about the original plans to make Zope3 backward compatible. I am still > very skeptical about the ability to add conversion scripts. They would > be incredibly tedious painful to write and I personally would rather > migrate code manually than trust a script. After all, the paradigms have > changed a lot. > > I see it as realistic as Stephan. There is no sane migration to Zope3 > than the one of refactoring code. Now, in order for that to happen, we > need the CA in Zope2, so people can start asap. My only criticism has > been and still is that the CA hasn't been introduced to Zope2 earlier. > Now, I know that a) the CA has been refactored a lot since its invention > (and IMO only for the good) and b) there was a lack of resources to do > that actual integration. That's why I've never declared anyone guilty > for it (which is why you may be surprised by this). > > It sure would have been nice if Gary had shared his experience with > FrankenZope a little earlier. I remember Martijn being quite eager to > experiment with it, too. But that's the only constructive criticism I have. So your concerns are really about the Z2 to Z3 transition plan, not about the Zope release process. Before I get into the main topic of my response, I'll note that I'm a good bit more optimistic about backward compatability than you are. I just have an intuition that we'll be able to do much more than you or Stephan expect. It's an intuition, not a promise. I can't prove it. Only time will tell. :) I know that lots of people are concerned by the uncertainlty about the future transition. This is a tough situation. I made a number of tradeoffs that put us in this situtaion. I think they were the right tradeoffs and I'd make them again. But, as with any tradeoff, we've had to balence positives and negatives. Let me explain: Zope 3 has always been a relatively small project. Within Zope Corporation, I'm the only one that has worked on Zope 3 full time for any length of time. As CTO, even my time on Zope 3 is not truly full time, but it's closer than for anyone else at ZC. Customer work (Zope 2), important community issues (like this thread, or like the security issues we uncovered last fall) take precedent. Other people working on Zope 3 have "day" jobs. They have to go to school or or do customer work (usually in Zope 2) to make a living. (Of course, you know this Philipp. :) I'm not complaining. This is reality and a reality we planned for. I made two choices that were controversial: 1. I decided not to be encumbered by backward compatability. This was refactoring mercelessly" applied in the extreme. This had the result that, except in a few areas, we did start from scratch. Pros: We had freedom to think abstracty about how Zope should work, and how we could make the experience for the developer as good as possible. The premise of not being backward compatible with Zope 2, also made us realize that we didn't have to be backward compatible with our own Zope 3 work. We were free to try things out, see how they worked and often, totally change them to make them better. Many core parts of Zope 3 have been redone, some more than once. This wouldn't have been possible if we had been trying to be backward compatible. Cons: We're not backward compatible. Will we ever be? I'm confident that we will have a decent transition. I don't know what shape that will take but I am still confident. Will there be bumps along the way? Definately. The recent issue with the conflicts between the "Zope" and "zope" package is a good example. While many might not agree with me, I am glad I made this decision. I would make it again. It was the right decision for Zope. If we had a lot more resources, we might have been able to pay more attention to Zope 2 compatability, although I'm not sure that that would have been the right thing to do. 2. I decided not to think much about the transition until Zope 3 has gotten farther along. The transition is a road from where we are to where we're going. It's awfully hard to build a road when the destination is changing. This means that, as the Zope Pope and CTO of Zope Corporation, I can promise that the road will be built, but I can't tell you what precise route the road will take or what it will be like. I can only give a general direction. Frankly, the destination has been well enough defined for a while now that we could begin defining the transition, but we just don't have enough resources to do so. Pros: We didn't waste time planning transition to a moving target. We ere able to focus scarce resources on getting a Zope 3 baseline. Cons: Fear, uncertainty and doubt Do I regret the decision not to define the transition better sooner? No. Not given available resources. I know that this puts the community in a tough spot, but I don't know what else I can do. Fortunately, I think we're pretty close to a time where we can provide a lot more attention to the transition and I think that much more clarity will emerge over coming months. My main regret is so badly underestimating how long it would take to reach where we are. There are a lot of reasons for being so far off. One important reason is that we created a different culture, one that is far more quality driven. We are being very picky about what we put in the Zope 3 baseline. We're willing to take the time to get it right, or at least as right as we can make it. We couldn't do this if it wasn't for Zope 2. Ultimately, I think that this cultural shift will provide us with great benefits. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org _______________________________________________ Zope-Dev maillist - Zope-Dev(a)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 )

1 0

Re: [Zope3-dev] Re: Proposal: Rename zope package
by Jim Fulton 22 Apr '04

22 Apr '04

Philipp von Weitershausen wrote: > Why would they switch to Zope 2.8 if not for the component architecture? To stay current? To get MVCC? To get new-style extension classes, and thus access to many modern Python features. Later releases will provide benefits beyond just the Z3 features. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org

2 2

Zope Bug Day Next Thursday (April 29)
by Casey Duncan 22 Apr '04

22 Apr '04

I proposed this yesterday, but I wanted to make sure that everyone say it. I think we should have a bug day, we're long overdue. I'm proposing we hold it on Thursday, April 29. We'll convene on the #zope-dev irc channel. -Casey

1 0

On a constructive note: Zope 2.8
by Martijn Faassen 22 Apr '04

22 Apr '04

Hey there, I understand from: http://dev.zope.org/Wikis/DevSite/Projects/Zope2.8/MilestonePlan Zope 2.8 is now planned for june. If Zope 2.8 is indeed released by june this could fit fairly well with my own (also delayed :) plans for using this facility in Silva. The obvious area I could try to contribute is in integrating Zope 3 interfaces in Zope 2. Have interfaces stabilized enough to start this work, or should I wait until next month (may is indicated on the planning). What steps need to be taken concretely before such integration is considered completed? I know the package rename discussion rename (zope to z) in Zope 3 is related to this. Regards, Martijn

2 4

Re: [Zope-dev] [Q] Pickle support for C wrapper and ZEO
by Ames Andreas (MPA/DF) 22 Apr '04

22 Apr '04

Hello Martin, kretschmar(a)infoman.de (Martin Kretschmar) writes: putting this back on list, hope it's ok with you. > Hello, > > I was once debugging an application which usually > crashed after 2-3 days during load tests. It was > doing a lot of database operations. The access > was to a Microsoft SQL Server. > > There has been once a warning, that constantly > creating and deleting CDatabase-Objects leeds to > memory leaks. So the application had been written > to reuse a given CDatabase object. > > The occasional crashes, shown to be somewhere in > the ODBC code, were gone, when each Thread got back > exactly his last CDatabase object in use. > > In this sense my definition of threadsafe is not > always the way Microsoft sees it. > > Regards, > Martin Thanks for the hint, but I won't use MFC in my code (portability). I'm currently using unixODBC to get started and hope to be able to preserve source code compatibility with MS's ODBC Driver Manager (and eventually iODBC if needed). If there are bugs in the platform code then these will bother me not before some time from now because I'm still wrapping all (or rather a subset of) those SQL... functions which live in sql[ext].h. Currently my own refcount leaks are much worse than any driver manager's memory leaks could ever be ;-). cheers, andreas

1 0

Re: [Zope3-dev] Re: Proposal: Rename zope package
by Troy Farrell 22 Apr '04

22 Apr '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Philipp von Weitershausen wrote: |> Troy Farrell wrote: |> |> -1 on alternative 4. This lurker is with Tres. This is a Z3 |> challenge. I wonder how many part-time Zope 2 admins will be happy |> about making this change and having to retest code they've inherited |> from some contract developer. | | Why would they switch to Zope 2.8 if not for the component architecture? | So, if you just "inherited" some code for maintainance, this will | unlikely break your program. In fact, it won't even break your program | when the rename is effective, since we'll keep a facade Zope package | around. Philipp, not everyone follows well-planned, ideal upgrade practices. Often, upgrades come when they can be had, and even more frequently when there is a security hole and the fix is only available for the latest version or two. I'm remembering this: http://securityfocus.com/bid/9400/ This was the occasion for my upgrade to 2.7, which proved to be a learning experience. Fortunately, I used a test instance for my upgrade :) Deprecation errors are nice, but usually admins take one of two approaches to them, neither of which is ideal: 1) Ignore them since everything seems to work alright 2) See the apocalypse horsemen headed their direction - this results in "URGENT!!! HELP ME PLAESE RIGHT NOW" email on the zope(a)zope.org list. This will cause many a shock when the occasion for upgrade to 2.9 comes around. ~ At 2 A.M. As for moving to CA, I'm trying it right now. I'm working through buddydemo and trying to wrap my head around the verbosity that is Zope 3. My plan is that starting mid-May, all new projects will be on Zope 3 sans the backward compatibility stuffs. My personal preference is for option 1 or option 3. Troy -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAhnF8AykmMtO9ylMRAh31AJ9EmIAtssh9k/CiNFGGMMQRxK0WSACeIRms 1iq79Ikc982nJvp/X15oETE= =5Kuy -----END PGP SIGNATURE-----

2 3

List of bugs which can be closed
by Maik Jablonski 22 Apr '04

22 Apr '04

2 1

Zope 2.6 branch "closed for bugfixes"?
by Chris Withers 21 Apr '04

21 Apr '04

Tres Seaver wrote: > Chris, > > I would call the 2.6 branch "closed except for serious security bugs"; > please don't check in new features or minor bugfixes there. How come? and was this announced anywhere? I don't see what harm applying minor bugfixes to any release branch could do... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

4 3

Re: Proposal: Rename zope package
by Tres Seaver 21 Apr '04

21 Apr '04

Jim Fulton wrote: > Tres Seaver wrote: > >> Jim Fulton wrote: >> >>> Jim Fulton wrote: >>> >>>> Based on recent discussions, I've created a proposal: >>>> >>>> http://dev.zope.org/Zope3/RenameTheZopePackage >>>> >>>> to rename the "zope" package to "z". Unless there are strong >>>> objections, we'll do this after we move the Zope repository head to >>>> subversion at the end of the month. >>> >>> >>> >>> >>> I've gotten enough negative feedback to "z", that I've added an >>> alternative 4 >>> to the proposal: >>> >>> 4. Rename the Zope package to Zope2 and provide a legacy Zope >>> package >> >> >> >> -1, for reasons I've stated before. > > > > Before you said: > > the amount of third-party code which we would break is incalculable. > > >> we *can't* inflict the pain on the large set of installed production >> servers to favor "cleanliness" for the one only installed by >> arrow-backed pioneers. We would be *much* better off with the status >> quo ante than with such a "solution". > > > I tried to address your concerns. The proposal should *not* inflict > pain on installed production servers. Is your complaint that: > > - There will be deprecation warnings or that > > - We would not enable this by default in 2.9, Sorry for the misunderstanding, which was mine: given the current deprecation scheme, I am only -0 on the notion. Tres. -- =============================================================== Tres Seaver tseaver(a)zope.com Zope Corporation "Zope Dealers" http://www.zope.com

1 0

Re: [Zope-dev] Re: The bleak Future of Zope?!
by kretschmar＠infoman.de 21 Apr '04

21 Apr '04

Hello, > Jim, > > we native german speakers tend to be much more direct > and phrase dings more bluntly the you americans do. > In german I read Maik's statement as a strong opinion > but never as an insult. > > Since I am the one who asked Mike to speak up I would > feel bad if it created any bad feelings. > > Robert Robert is 100% right! Mikes oppion contains no real insults at all, not even really bad phrases, at least not in the original german version. German insults look quite different, and we tend to recognize them when we read them. In this sense I was somewhat careless in my instant translation and I want to apologize for it. Martin

1 0