[Zope-dev] Re: Clarification re: Zope X3.1, 2.8 - svn usage
Hello, Tres Seaver wrote: When you use 'svn:externals', the referenced package itself is *not* part of the containing checkout; it is managed separately by the svn client (sort of like ESI and page fragments). Yes this is true. But the differences between svn:externals and a copy are not so big. (the user nearly gets the same) With both you can get enough trouble. Even with svn:externals it's possible that someone checks something in to a tagged version. Subversion misses the feature to make tags read only and thats what you need in both cases. Tim points out that there are a number of these external dependencies, including ZConfig and zdaemon, which are not directly part of ZODB either: it depends on them in the same way that Zope depends on ZODB. My company uses subversion extensively, we have one rule: If we are in the same repository, we try to make a copy. If we have to different repositories and there are dependencies, we use svn:externals. Because there is one big Problem with svn:externals: If the repository is closed source and not available over Internet it is not possible to work at home with ssh checkouts. Hope this helps a little bit. bye by Wolfgang ___ 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: Clarification re: Zope X3.1, 2.8 - svn usage
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Wolfgang Langner wrote: Hello, Tres Seaver wrote: When you use 'svn:externals', the referenced package itself is *not* part of the containing checkout; it is managed separately by the svn client (sort of like ESI and page fragments). Yes this is true. But the differences between svn:externals and a copy are not so big. (the user nearly gets the same) Copies are forks. We have a lot of experience over the past year with the pain those forks cause. With both you can get enough trouble. Even with svn:externals it's possible that someone checks something in to a tagged version. Subversion misses the feature to make tags read only and thats what you need in both cases. Note that the Zope SVN repository does not allow write access via 'svn:' URLs, so we can get the read-only effect by exploiting that. We should proabably also see what can be done to make commits into the 'tags' tree disallowed; I'm not sure if that is possible in a 'svn+ssh:' setup. Tim points out that there are a number of these external dependencies, including ZConfig and zdaemon, which are not directly part of ZODB either: it depends on them in the same way that Zope depends on ZODB. My company uses subversion extensively, we have one rule: If we are in the same repository, we try to make a copy. If we have to different repositories and there are dependencies, we use svn:externals. Because there is one big Problem with svn:externals: If the repository is closed source and not available over Internet it is not possible to work at home with ssh checkouts. Doesn't obtain here. Hope this helps a little bit. Tres. - -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation Zope Dealers http://www.zope.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCTBKVGqWXf00rNCgRAioQAJ9gVzrxEkcqx8CsyOgN7+A21f/cfwCgouY4 hH3OLrh5fpQFCXq217DCWA0= =WekI -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Clarification re: Zope X3.1, 2.8
Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Martijn Faassen wrote: [snip] Right, lib/python/zope is actually Zope X3.0.0, and we didn't expect we'd need to *update* Zope X3.0 in order for it to work with Zope 2.8. The new ZODB version is having some repercussions there. Zope X3.0 was released against an older version of ZODB. I'm really at a loss at what to do there. Perhaps we should make a X3.0.1. This is fairly long overdue anyway. Alternatively, we could make a branch for use in 2.8. I don't think this would really be a problem. We already have one: it was needed in order to remove the excess packages (the ones tagged as being in X3.0, without actually being installed by the zpkg stuff). You want to do the get_transaction() changes on that then, and not on the ZopeX3.0 branch proper? I can spend time trying to shut up Zope X3 I guess, if that is the only option... Adding the required methods to the zope.app.mail.delivery thingy should take less than an hour, I think. I'm not following this. What required methods with what zope.app.mail.delivery? I thought we were talking about ZODB 3.4 related changes here. 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] Re: Clarification re: Zope X3.1, 2.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Tres Seaver wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jim Fulton wrote: Martijn Faassen wrote: [snip] Right, lib/python/zope is actually Zope X3.0.0, and we didn't expect we'd need to *update* Zope X3.0 in order for it to work with Zope 2.8. The new ZODB version is having some repercussions there. Zope X3.0 was released against an older version of ZODB. I'm really at a loss at what to do there. Perhaps we should make a X3.0.1. This is fairly long overdue anyway. Alternatively, we could make a branch for use in 2.8. I don't think this would really be a problem. We already have one: it was needed in order to remove the excess packages (the ones tagged as being in X3.0, without actually being installed by the zpkg stuff). You want to do the get_transaction() changes on that then, and not on the ZopeX3.0 branch proper? Depends. If somebody has an appetite for making a 3.0.1 release (not me!) then make the branch compatible with ZODB 3.4. We can then re-branch to create the 2.8 extract (probably by merging the changes from our current branch). I can spend time trying to shut up Zope X3 I guess, if that is the only option... Adding the required methods to the zope.app.mail.delivery thingy should take less than an hour, I think. I'm not following this. What required methods with what zope.app.mail.delivery? I thought we were talking about ZODB 3.4 related changes here. ZODB 3.4 updates the transaction.IDataManager contract (documents what was always the real contract), which causes a test in that package to fail. Again, we can fix it on the 3.0 branch, if a release is planned there, or else just fix it on our own branch. Tres. - -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation Zope Dealers http://www.zope.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCTB4iGqWXf00rNCgRAlSCAJ9DpgI3a0xMUR9XJK+dWmQb7eb2xQCfVDmY mIH6sohjv/H5c+j1hlD+fpg= =YZSP -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Clarification re: Zope X3.1, 2.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Florian Schulze wrote: On Tue, 29 Mar 2005 18:12:51 -0500, Tim Peters [EMAIL PROTECTED] wrote: [Tres] - ZODBGuru uses 'svn rm' to zap the current ZODB on the trunk, replacing it with an 'svn:external' link to your ZODB 3.4 tag; and then tests it (could be an 'svn cp', but I don't see any benefit to maintaining a Zope-specific fork). My problem. It will certainly be done via 9 svn switchs on my local machine first. As explained elsewhere, there are several other possible sources of integration problems here, and I can't know about those before actually trying it. It's possible, e.g., that I'll need to change ZODB 3.4 to worm around them, or switch ZODB to using a different ZConfig, etc. Can't predict here. [snip] - ReleaseMaker uses 'svn cp' to create the release tag for Zope 2.8a2 (whatever it is being called). Check. When you use svn:external, it will be copied as is to the tag, so when the external files change, the files in the tag change as well. So a svn cp would be better I guess. I don't think so. The point is that each released version of Zope (already) depends on a specific, released version of ZODB; we don't *want* to be copying ZODB into the Zope tree in the repository, because that implicitly creates a fork (i.e., people check into the ZODB copy inside the Zope tree, which is Evil (TM).) When you use 'svn:externals', the referenced package itself is *not* part of the containing checkout; it is managed separately by the svn client (sort of like ESI and page fragments). Tim points out that there are a number of these external dependencies, including ZConfig and zdaemon, which are not directly part of ZODB either: it depends on them in the same way that Zope depends on ZODB. Tres. - -- === Tres Seaver[EMAIL PROTECTED] Zope Corporation Zope Dealers http://www.zope.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCSy2lGqWXf00rNCgRArecAJ9yZDl7hLH+cAO1eYeIePUB6JzbZQCeJjX7 wXM+tv0oKKpcDFpZd6CQPRI= =Cb8U -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: Clarification re: Zope X3.1, 2.8
Before I vanished for PyCon about two weeks ago, I was under the impression that merging Zope/branches/five-integration into Zope/trunk was imminent -- a matter of days, if not hours. Perhaps I was mistaken in that. Regardless, what's the current status of this? Last I saw, Andreas announced a plan to release 2.8a2 this coming Friday evening (according to my clock wink), but AFAICT the five-integration branch is still distinct from the trunk. Is it the plan to release 2.8a2 without merging this in? If not, what's the plan/schedule for merging five-integration? ZODB 3.4 requires some Zope3 packages, so there are potential integration headaches in two directions: (1) possible problems for ZODB due to five-integration using versions of those packages older than the ones ZODB 3.4 has been using; and, (2) code in five-integration that runs afoul of changes in ZODB 3.4. I can't predict these without trying the actual code. A possible example of #2 is that I rewrote hundreds of instances of get_transaction() in Zope trunks yesterday, because get_transaction() is officially deprecated in ZODB 3.4 and I don't want to release a Zope that raises DeprecationWarning in its internals. Perhaps the five-integration code has more instances of this that need to be changed. A clarification, because some have been confused about this (and it is confusing!): a ZODB trunk checkout stitches in its own copies of the Zope3 packages it needs, same as it stitches in copies of zdaemon and ZConfig. The process of stitching a ZODB into a Zope does *not* stitch those packages into that Zope: Zope uses its own copies of zdaemon, ZConfig, and Zope3 code. From Zope 2.8's POV, ZODB means exactly these 9 directories (these, and no others, get stitched in from a ZODB tag): Under lib/python/: ZODB ZEO persistent transaction BTrees ThreadedAsync Persistence ZopeUndo Under utilities/: ZODBTools (this is a renamed copy of ZODB's src/scripts/). I always expected (and still do) to do the ZODB stitching on Zope trunk, but since stitching in a ZODB does not include anything other than those 9 directories, I can't do it before at least the Zope3 packages are stitched in from the five-integration branch. Note that it's also possible we'll hit integration snags due to mismatches in the versions of zdaemon and ZConfig in use (the ones Zope trunk uses versus the ones ZODB has been using). ___ 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: Clarification re: Zope X3.1, 2.8
--On Dienstag, 29. März 2005 14:07 Uhr -0500 Tim Peters [EMAIL PROTECTED] wrote: Regardless, what's the current status of this? Last I saw, Andreas announced a plan to release 2.8a2 this coming Friday evening (according to my clock wink), but AFAICT the five-integration branch is still distinct from the trunk. Right. My plan was to post a reminder that 2.8a2 is scheduled for this weekend. So all Five related integration work should be finished very soon otherwise I am going to reschedule a2. ZODB 3.4 requires some Zope3 packages, so there are potential integration headaches in two directions: (1) possible problems for ZODB due to five-integration using versions of those packages older than the ones ZODB 3.4 has been using; and, (2) code in five-integration that runs afoul of changes in ZODB 3.4. I can't predict these without trying the actual code. I hope that the people doing the Five integration should have their stuff ready in time but there is no need to hurry with a release just for the sake of making a release. Means: if you need more time you weill get the time of course. Andreas pgpUS8tIK6Z1c.pgp Description: PGP signature ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Re: Clarification re: Zope X3.1, 2.8
[Tres Seaver] ... Most of that work has been done on the trunk. The 'five-integration' branch changes consist largely of: - Setting up an 'svn:external' link to the Zope X3 3.0 repository (which is on a branch, pruned to include only the packages which were actually released with 3.0). Just noting that this may create new but short-lived problems for developers on Windows (can't tell for sure until I try it; has to do with PuTTY's symbolic names, and the unlikelihood that any Windowshead has svn.zope.org set up as a symbolic name now). - Importing the Five product. - Un-monkey-fying Five's monkey patches. As soon as we settle the question of how ZODB gets stitched in (I prefer the 'svn:external' mode myself, but that is just a preference), that branch should be easily merged. Since Zope doesn't own ZODB, I don't see how merging the branch has anything to do with how ZODB gets stitched in. Stitching in a _new_ ZODB is my problem, after the branch is merged ( I need the merge to happen first, so that Zope3 (lib/python/zope) packages show up on the trunk -- ZODB 3.4 can't work without them). AFAICT, no stitching of ZODB took place when five-integration branch was created. For example, the log message for Zope/branches/five-integration/lib/python/ZODB just says it was copied from Zope/trunk:29468. IOW, it just copied over the version of ZODB that happened to be in Zope trunk at the time the five-integration branch was created. If people then made _changes_ to ZODB code on five-integration, they should not have, and it will create problems. But if they didn't, the ZODB code on five-integration branch and Zope trunk should still be identical, in which case no code in any of the 9 ZODB directories should have any effect on the merge. IOW, ignore ZODB entirely: if the tests pass on the branch, they should continue to pass on the trunk after the merge, since the ZODBs on branch and trunk should be exactly the same right now. ___ 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: Clarification re: Zope X3.1, 2.8
... [Tres] - Setting up an 'svn:external' link to the Zope X3 3.0 repository (which is on a branch, pruned to include only the packages which were actually released with 3.0). [Tim] Just noting that this may create new but short-lived problems for developers on Windows (can't tell for sure until I try it; has to do with PuTTY's symbolic names, and the unlikelihood that any Windowshead has svn.zope.org set up as a symbolic name now). Bit o' good news: there doesn't appear to be a Windows problem here (might have been if we were using svn+ssh:, but not with plain svn: access). ... IOW, ignore ZODB entirely: if the tests pass on the branch, they should continue to pass on the trunk after the merge, since the ZODBs on branch and trunk should be exactly the same right now. Using a fresh checkout: five\lib\python$ svn log -rHEAD:0 -v --stop-on-copy ZODB ZEO ^ persistent transaction BTrees ThreadedAsync ^ Persistence ZopeUndo r29469 | efge | 2005-03-15 06:23:03 -0500 (Tue, 15 Mar 2005) | 2 lines Changed paths: A /Zope/branches/five-integration (from /Zope/trunk:29468) Branch where integration of Five will take place. five\lib\python$ cd ..\..\utilities five\utilities$ svn log -rHEAD:0 -v --stop-on-copy ZODBTools r29469 | efge | 2005-03-15 06:23:03 -0500 (Tue, 15 Mar 2005) | 2 lines Changed paths: A /Zope/branches/five-integration (from /Zope/trunk:29468) Branch where integration of Five will take place. IOW, no changes have been checked in to any ZODB code on five-integration branch, so it should indeed be identical to the ZODB code still on Zope trunk. The same appears true of zdaemon and ZConfig too, and AFAIK that covers all the external code stitched in to Zope apart from new external code introduced on the five-integration branch. ___ 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: Clarification re: Zope X3.1, 2.8
[Tres] ... I'll have to take your word for that; are you saying that 'svn:external' doesn't work by default in the windows SVN clients? Crossed in the mail; no problem here. ... OK, that works for me. AFAIK, the branch should be ready to merge whenever; all the recent work on it has been to merge fixes which had already been applied on the trunk. How does this sound for a recipe: - ReleaseMaker merges the 'five-integration' branch to the trunk, and tests it. Check. - ZODBGuru uses 'svn rm' to zap the current ZODB on the trunk, replacing it with an 'svn:external' link to your ZODB 3.4 tag; and then tests it (could be an 'svn cp', but I don't see any benefit to maintaining a Zope-specific fork). My problem. It will certainly be done via 9 svn switchs on my local machine first. As explained elsewhere, there are several other possible sources of integration problems here, and I can't know about those before actually trying it. It's possible, e.g., that I'll need to change ZODB 3.4 to worm around them, or switch ZODB to using a different ZConfig, etc. Can't predict here. - ReleaseMaker updates changelog, version.txt, etc. and checks in. Check. - ReleaseMaker uses 'svn cp' to create the release tag for Zope 2.8a2 (whatever it is being called). Check. The goal for that branch was to do *only* stuff which had to do with landing Five / ZopeX3.0; no other changes were supposed to land there. Any non-Five-specific work was supposed to happen on the trunk. Crossed in the mail again; I confirmed this is so for the zdaemon, ZConfig and nine ZODB directories. ... Just ran the five-integration branch tests on Windows. Two failures, which are repeats of longstanding trunk failures on Windows: http://www.zope.org/Collectors/Zope/1728 ___ 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: Clarification re: Zope X3.1, 2.8
Chris McDonough [EMAIL PROTECTED] wrote: Brian Lloyd wrote: A lot of time was spent talking about these (legitimate) concerns - unfortunately it will probably take a little time to distill all of that communication to the community. But let me take a shot ;) There are several different groups, with different goals and concerns, who are involved here: A: Z2 developers that don't care right now about Z3 B: Z2 developers that care about Z3, but can't effectively use anything Z3 related right now because it is not practical or possible to switch wholesale and there is no bridge to Z3 that doesn't require throwing away existing investments in Z2 C: Z3 developers that don't care about Z2 anymore, often because they dont have existing investments in Z2 There are a significant and growing number of people in group B. Yup, that makes sense. Are these assumed to also be the folks who will try to make sure that new Z3 releases make it in to Z2 via Five? I guess what I'm driving at is that I'd hate to eventually have a very old version of Z3 sitting inside of Zope 2 due to insufficient bandwidth on the part of those developers to keep up with Z3 releases. Those developers (I'm part of them) have every interest in keeping code working and up to date, because their incentive in doing this bridge is to eventually to use Zope 3 proper. [...] Please correct me if I'm wrong here but I get the sense that Five is less of a migration path from Z2 to Z3 than a way to integrate Z3 technologies (like views and adapters) into Z2 right now. Obviously allowing Z2 developers to use these things will give them a some needed familiarity with Z3 if they decide to switch but the migration path to straight Z3 will always be more or less a rewrite, no? No. Here at Nuxeo we are writing products with Five with the express goal of being able to port them rapidly to pure Zope 3 when we have enough Zope 3 components to build a proper CMS. Views and adapters, together with a few core utilities, make up 95% of what most products need from their framework. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, 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 )
Re: [Zope-dev] RE: Clarification re: Zope X3.1, 2.8
Chris McDonough wrote: Yup, that makes sense. Are these assumed to also be the folks who will try to make sure that new Z3 releases make it in to Z2 via Five? I guess what I'm driving at is that I'd hate to eventually have a very old version of Z3 sitting inside of Zope 2 due to insufficient bandwidth on the part of those developers to keep up with Z3 releases. That will only be an issue when Zope3 has matured so much that new releases do not give people significant benefits to bother upgrading Zope2. ;) But is there and available, so people can begin to plot their own migration paths based on their own situations. Please correct me if I'm wrong here but I get the sense that Five is less of a migration path from Z2 to Z3 than a way to integrate Z3 technologies (like views and adapters) into Z2 right now. Obviously allowing Z2 developers to use these things will give them a some needed familiarity with Z3 if they decide to switch but the migration path to straight Z3 will always be more or less a rewrite, no? Well, what you can do is write Zope2 products that can be easily migrated to zope 3. Is that a migration path? maybe not... ___ 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: Clarification re: Zope X3.1, 2.8
Chris McDonough wrote: [snip] Please correct me if I'm wrong here but I get the sense that Five is less of a migration path from Z2 to Z3 than a way to integrate Z3 technologies (like views and adapters) into Z2 right now. Obviously allowing Z2 developers to use these things will give them a some needed familiarity with Z3 if they decide to switch but the migration path to straight Z3 will always be more or less a rewrite, no? It will be far *less* of a rewrite. Evolution is not easy, but we have had some success at the sprint at converting Five-based code to pure Zope 3 based code, and vice versa. Five is very much intended to be a migration path. Once you are using views and adapters, schema and forms, and so on, in your code, and slowly move your existing code to use these technologies, porting the code over to straight Zope 3 will be more and more easy. Muc of Five ZCML just literally works in Zope 3; the views work virtually the same, for instance. Evolution, not revolution. [snip] For now, I think it is a huge win to make some Z3 avenues available to people who want to use them, without forcing everyone to drink the kool-aid at once ;) Yup... I'm still a bit skeptical but if other folks are committed to maintenance I'd be less so. I'll repeat that I'm committed to this. 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: Clarification re: Zope X3.1, 2.8
Chris wrote: I assume these caveats are spelled out here because Z3 developers don't want to slow down Z3 development to test/maintain Z2 compatibility. I know a lot about Z2 code, but I know very little about Z3 code. I'd like that to change, but it's likely that I'll just not have the bandwidth to make sure Z3-inside-Z2 works. If that just means I can't use Z3 features but nothing else breaks, it's probably fine, but if Z3 integration actively breaks Z2, it's likely I'll just need for some extended period of time to continue to use and maintain 2.7. It'd be great if active Z3 developers could actually help make new releases of Z2 once Five is integrated but the above makes it sound like a we'll throw it over the wall and you make it work sort of thing. If it's the latter, maybe as devil's advocate, I need to ask what the point is here? It appears there is an assumption that merging Z2 and Z3 code within Z2 itself is an unmitigated good thing, but IMHO, each is complicated enough in their own right that I'd personally prefer to be dealing with one or the other at any given time and not both. This isn't exactly idle whining either, I need to do this when I maintain Z4I code, and it's definitely not a walk in the park; it's moderately difficult to do and also difficult find people who have the skills to help too. Does anyone else share this skepticism or am I about to get shouted down? ;-) - C A lot of time was spent talking about these (legitimate) concerns - unfortunately it will probably take a little time to distill all of that communication to the community. But let me take a shot ;) There are several different groups, with different goals and concerns, who are involved here: A: Z2 developers that don't care right now about Z3 B: Z2 developers that care about Z3, but can't effectively use anything Z3 related right now because it is not practical or possible to switch wholesale and there is no bridge to Z3 that doesn't require throwing away existing investments in Z2 C: Z3 developers that don't care about Z2 anymore, often because they dont have existing investments in Z2 There are a significant and growing number of people in group B. At the paris sprint, we were looking for a way to: - Allow folks in group B to start taking advantage of (and developing an interest in and contributing to!) Zope 3 technologies - Make sure that group A would not be 'forced' to do anything they don't want to do - Make sure that group C would not be 'forced' to do anything they don't want to do I feel that the approach of integrating Five into Zope officially does a pretty good job of meeting those goals. We added the Five product and a snapshot of Zope X3.0 into the core so that people could have a reliable baseline 'out of the box'. That integration touched almost nothing in the Z2 code (one or two things that were previously done as monkey patches were un-monkeyed, but that's about it). The Z3 code (and the Five code) just sits there unused unless you choose to use it, so Zope3 code breaking Z2 apps is not really a concern. But is there and available, so people can begin to plot their own migration paths based on their own situations. Like other areas of Z2 (and Z3, for that matter), contributors tend to develop areas of expertise. A new area of expertise for Z2 going forward will be the Five/Z3 integration, and there will be a set of devs who will likely focus on that aspect. I don't expect that the fact that Five and Z3 integration exists will make life any harder for someone who focuses on purely Z2 aspects of the core anytime soon. So the short answer is, we tried really hard to make sure to take an approach where z3 integration would not actively break zope2 in any way or force people into any particular direction. I *do* expect these (good) questions to recur in future Z2 releases, as integration and ability to use Z3 technologies increases, but we'll have plenty of time to work those out. For now, I think it is a huge win to make some Z3 avenues available to people who want to use them, without forcing everyone to drink the kool-aid at once ;) Brian Lloyd[EMAIL PROTECTED] V.P. Engineering 540.361.1716 Zope Corporation http://www.zope.com ___ 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: Clarification re: Zope X3.1, 2.8
On Fri, 2005-03-18 at 13:45, Brian Lloyd wrote: A lot of time was spent talking about these (legitimate) concerns - unfortunately it will probably take a little time to distill all of that communication to the community. But let me take a shot ;) There are several different groups, with different goals and concerns, who are involved here: A: Z2 developers that don't care right now about Z3 B: Z2 developers that care about Z3, but can't effectively use anything Z3 related right now because it is not practical or possible to switch wholesale and there is no bridge to Z3 that doesn't require throwing away existing investments in Z2 C: Z3 developers that don't care about Z2 anymore, often because they dont have existing investments in Z2 There are a significant and growing number of people in group B. Yup, that makes sense. Are these assumed to also be the folks who will try to make sure that new Z3 releases make it in to Z2 via Five? I guess what I'm driving at is that I'd hate to eventually have a very old version of Z3 sitting inside of Zope 2 due to insufficient bandwidth on the part of those developers to keep up with Z3 releases. While it wouldn't be the end of the world or anything, I suspect some dependencies will inevitably creep into the Zope 2 core on Zope 3 packages, and maintaining an older codebase can be pretty painful. The testing requirements for making sure that changes that Z2 coders make to Z3 work both in Z2 and Z3 is a pretty high bar, just as vice versa. In the past, I've seen efforts like this turn into an effective fork as a result. At the paris sprint, we were looking for a way to: - Allow folks in group B to start taking advantage of (and developing an interest in and contributing to!) Zope 3 technologies - Make sure that group A would not be 'forced' to do anything they don't want to do - Make sure that group C would not be 'forced' to do anything they don't want to do I feel that the approach of integrating Five into Zope officially does a pretty good job of meeting those goals. We added the Five product and a snapshot of Zope X3.0 into the core so that people could have a reliable baseline 'out of the box'. That integration touched almost nothing in the Z2 code (one or two things that were previously done as monkey patches were un-monkeyed, but that's about it). The Z3 code (and the Five code) just sits there unused unless you choose to use it, so Zope3 code breaking Z2 apps is not really a concern. That's good to know. But is there and available, so people can begin to plot their own migration paths based on their own situations. Please correct me if I'm wrong here but I get the sense that Five is less of a migration path from Z2 to Z3 than a way to integrate Z3 technologies (like views and adapters) into Z2 right now. Obviously allowing Z2 developers to use these things will give them a some needed familiarity with Z3 if they decide to switch but the migration path to straight Z3 will always be more or less a rewrite, no? Like other areas of Z2 (and Z3, for that matter), contributors tend to develop areas of expertise. A new area of expertise for Z2 going forward will be the Five/Z3 integration, and there will be a set of devs who will likely focus on that aspect. I don't expect that the fact that Five and Z3 integration exists will make life any harder for someone who focuses on purely Z2 aspects of the core anytime soon. So the short answer is, we tried really hard to make sure to take an approach where z3 integration would not actively break zope2 in any way or force people into any particular direction. Excellent, that's what I was hoping. I *do* expect these (good) questions to recur in future Z2 releases, as integration and ability to use Z3 technologies increases, but we'll have plenty of time to work those out. For now, I think it is a huge win to make some Z3 avenues available to people who want to use them, without forcing everyone to drink the kool-aid at once ;) Yup... I'm still a bit skeptical but if other folks are committed to maintenance I'd be less so. - 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 )