[Zope-dev] Re: Clarification re: Zope X3.1, 2.8 - svn usage

2005-03-31 Thread Wolfgang Langner
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

2005-03-31 Thread Tres Seaver
-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

2005-03-31 Thread Martijn Faassen
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

2005-03-31 Thread Tres Seaver
-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

2005-03-30 Thread Tres Seaver
-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

2005-03-29 Thread Tim Peters
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

2005-03-29 Thread Andreas Jung

--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

2005-03-29 Thread Tim Peters
[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

2005-03-29 Thread Tim Peters
...

[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

2005-03-29 Thread Tim Peters
[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

2005-03-21 Thread Florent Guillaume
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

2005-03-20 Thread Lennart Regebro
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

2005-03-19 Thread Martijn Faassen
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

2005-03-18 Thread Brian Lloyd
 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

2005-03-18 Thread Chris McDonough
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 )