Re: [Zope-dev] ZPT: defer expression fix
Christian Heimes <[EMAIL PROTECTED]> wrote: > PageTemplates have an undocumented features called defer:. It's a kind > of lazy initialization of variables. > > I've fixed to issues in my tiran-zpt-pydefer branch (svn): > > * DeferWrappers weren't working inside a python expression because > PythonExpr didn't know about them > > * DeferWrapper didn't cache the result of the expression like ordinary > vars do. > > I would like to merge my branch into 2.7 and 2.8 if I get an ok. I had trouble finding your branch because you put it in Zope/tiran-zpt-pydefer instead of Zope/branches/tiran-zpt-pydefer. Could you move it ? Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED] ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Re: [Zope-Coders] Re: Question about procedures
[moved from -coders to -dev]
First off: I will go with Lennart's suggestion of branches;
I fundamentally agree; I have just never worked on a project where
branches for such petty things aren't overkill. I guess Zope is
a number of magnitudes larger. :)
Now sorry for the noise on zope-coders when this should have been on
zope-dev in the first place.
Now for some of the things that Florent pointed out:
also sprach Florent Guillaume <[EMAIL PROTECTED]> [2005.03.24.1814 +0100]:
> > -if RESPONSE is not None:
> > +if RESPONSE is not None and ob:
>
> You should check 'and ob is not None' too.
... but ob is false when it is None, no?
> But why could it be None ? What's the point (sorry I don't have
> context).
Well, I was trying to guard against errors made in other parts of
the code. I know I should not do this. It made things a lot easier
while I was preparing some other patches. Anyway, good thing
I haven't committed. :)
> > +if not hasattr(ob, 'absolute_url'):
>
> Do not use hasattr for persistent objects. Use
>if getattr(ob, 'absolute_url', None) is None:
Can I read up on the rationale somewhere?
> > + raise TypeError('constructInstance did not return a CMF
> > object.')
>
> Also, check your indentation (should be 4 chars).
Woops.
> > -return ob.getId()
> > +return getattr(ob, 'id', None)
>
> Please don't do that, getId() is the proper API to call.
Another instance of "what to do when ob does not have an getId
method".. you are right, this is wrong.
also sprach Andreas Jung <[EMAIL PROTECTED]> [2005.03.25.0945 +0100]:
> For changes which are limited to a file or a subtree I do always
> prefer a patch instead of a branch.
I can create a branch and submit patches to you (this is when I wish
zope.org would be using GNU arch). Anyway, since it's probably best
for me not to make changes in the code at present time (being young
in the project and without an assigned field of responsibility),
where do I send potential patches? This list?
--
martin; (greetings from the heart of the sun.)
\ echo mailto: !#^."<*>"|tr "<*> mailto:"; [EMAIL PROTECTED]
invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver!
spamtraps: [EMAIL PROTECTED]
"next the statesmen will invent cheap lies, putting the blame upon the
nation that is attacked, and every man will be glad of those
conscience-soothing falsities, and will diligently study them, and
refuse to examine any refutations of them; and thus he will by and by
convince himself that the war is just, and will thank god for the
better sleep he enjoys after this process of grotesque
self-deception."
-- mark twain
signature.asc
Description: Digital 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: ZPT: defer expression fix
Florent Guillaume wrote: I had trouble finding your branch because you put it in Zope/tiran-zpt-pydefer instead of Zope/branches/tiran-zpt-pydefer. Could you move it ? Ups, done :) Christian ___ 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: [Zope-Coders] Re: Question about procedures
martin f krafft <[EMAIL PROTECTED]> wrote: > also sprach Florent Guillaume <[EMAIL PROTECTED]> [2005.03.24.1814 +0100]: > > > -if RESPONSE is not None: > > > +if RESPONSE is not None and ob: > > > > You should check 'and ob is not None' too. > > ... but ob is false when it is None, no? Yes but comparing to None is faster, and in some cases (REQUEST for instance), much much faster, than checking the boolean value. > > But why could it be None ? What's the point (sorry I don't have > > context). > > Well, I was trying to guard against errors made in other parts of > the code. I know I should not do this. It made things a lot easier > while I was preparing some other patches. Anyway, good thing > I haven't committed. :) > > > > +if not hasattr(ob, 'absolute_url'): > > > > Do not use hasattr for persistent objects. Use > >if getattr(ob, 'absolute_url', None) is None: > > Can I read up on the rationale somewhere? It was discussed at length on the zope lists. Basically hasattr tries to access the attribute and returns false if *any* exception is raised. This hides exceptions, which is bad in the case of persistent objects that can raise ConflictErrors. Florent -- Florent Guillaume, Nuxeo (Paris, France) CTO, Director of R&D +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: [Zope-Coders] Re: Question about procedures
Em Ter, 2005-03-29 às 17:21 +0200, Florent Guillaume escreveu: > martin f krafft <[EMAIL PROTECTED]> wrote: > > also sprach Florent Guillaume <[EMAIL PROTECTED]> [2005.03.24.1814 +0100]: > > > > -if RESPONSE is not None: > > > > +if RESPONSE is not None and ob: > > > > > > You should check 'and ob is not None' too. > > > > ... but ob is false when it is None, no? > > Yes but comparing to None is faster, and in some cases (REQUEST for > instance), much much faster, than checking the boolean value. And not every "False" object is None. A custom object could implement __len__() and be considered false if it's "empty", or it could implement __nonzero__() and be considered "false" even when you want to return it. Cheers, Leo -- Leonardo Rochael Almeida <[EMAIL PROTECTED]> ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Problems with zope 2.7.0 and ZODB (suse 9.1)
Hi all:
I get the next errors, when I try to add some of my Product Instances...
(In zope 2.5.0 works well...)
2005-03-29T18:52:47 INFO(0) ZODB Opening database for mounting:
'1110315472_1112115167.490661'
--
2005-03-29T18:52:47 PROBLEM(100) ZODB Failed to mount database.
exceptions.AttributeError ('NoneType' object has no attribute
'getVersion')
Traceback (most recent call last):
File "/opt/zope/lib/python/ZODB/Mount.py", line 168, in
_getOrOpenObject
conn, newMount, mcc = self._openMountableConnection(parent)
File "/opt/zope/lib/python/ZODB/Mount.py", line 142, in
_openMountableConnection
conn = db.open(version=jar.getVersion())
AttributeError: 'NoneType' object has no attribute 'getVersion'
--
2005-03-29T18:52:47 PROBLEM(100) ZODB Failed to mount database.
exceptions.AttributeError ('NoneType' object has no attribute
'getVersion')
Traceback (most recent call last):
File "/opt/zope/lib/python/ZODB/Mount.py", line 168, in
_getOrOpenObject
conn, newMount, mcc = self._openMountableConnection(parent)
File "/opt/zope/lib/python/ZODB/Mount.py", line 142, in
_openMountableConnection
conn = db.open(version=jar.getVersion())
AttributeError: 'NoneType' object has no attribute 'getVersion'
--
2005-03-29T18:52:47 PROBLEM(100) ZODB Failed to mount database.
exceptions.AttributeError ('NoneType' object has no attribute
'getVersion')
Traceback (most recent call last):
File "/opt/zope/lib/python/ZODB/Mount.py", line 168, in
_getOrOpenObject
conn, newMount, mcc = self._openMountableConnection(parent)
File "/opt/zope/lib/python/ZODB/Mount.py", line 142, in
_openMountableConnection
conn = db.open(version=jar.getVersion())
AttributeError: 'NoneType' object has no attribute 'getVersion'
What I'm doing wrong?
Thanks...
___
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 ), 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 ), 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 )
[Zope-dev] Re: Clarification re: Zope X3.1, 2.8
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Jung wrote: > > > --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 ), 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. 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). - 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. >> 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. 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 iD8DBQFCScNFGqWXf00rNCgRAixAAJwIHhVuNkhLzQsYK9UAzXeKrLTKhgCfeY/9 hBobU0eAnoBgZHdf91yMcfw= =dLdd -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] ... > 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tim Peters wrote: > [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). 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? >>- 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). 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. - 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). - ReleaseMaker updates changelog, version.txt, etc. and checks in. - ReleaseMaker uses 'svn cp' to create the release tag for Zope 2.8a2 (whatever it is being called). > 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. 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. > 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. They should be identical, as none of the checkins on the 'five-integration' branch touched anything under 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 iD8DBQFCSd2gGqWXf00rNCgRAkPkAJ4gZhGlb5sDAr0QlDtOPJ3N4BE+pQCfdf4W IUamIwQMwMO6HiD9YWdiVoI= =SyzX -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] ... > 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 switch"s 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 )
