Re: [Zope-dev] [Checkins] SVN: zope.dublincore/trunk/ Renamed the ``zope.app.dublincore.*`` permissions to ``zope.dublincore.*`.

2010-04-24 Thread Lennart Regebro
On Sat, Apr 24, 2010 at 00:14, Tres Seaver tsea...@palladion.com wrote:
 Maybe the short-term fix would be to add a shim package (reviving
 'zope.app.dublincore', maybe) whose only job in life is to make those
 permissions loadable.  Maybe the package ships with some code to help
 write the evolve script, or something.

This seems to be the correct way to me, if possible.

(How many letters I used to say +1. Why did I do that? It might be
some sort of existential crisis. Or it's just early in the morning and
I'm still half asleep. )
-- 
Lennart Regebro: http://regebro.wordpress.com/
Python 3 Porting: http://python-incompatibility.googlecode.com/
+33 661 58 14 64
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] [Checkins] SVN: zope.dublincore/trunk/ Renamed the ``zope.app.dublincore.*`` permissions to ``zope.dublincore.*`.

2010-04-24 Thread Marius Gedminas
On Fri, Apr 23, 2010 at 06:14:23PM -0400, Tres Seaver wrote:
 Jim Fulton wrote:
  On Fri, Apr 23, 2010 at 4:18 AM, Jacob Holm j...@improva.dk wrote:
  Hi Michael, Tres
 
  I agree a new major version is required due to the new feature of
  having new permission names, but there is no reason to break
  compatibility with code using the old names.
 
  IIRC the redefinePermission/ zcml-directive  is there exactly to
  provide backwards compatibility when renaming permissions.  Use like:
 
   redefinePermission
   from = no longer defined permisison id
   to = existing permission id
   /
 
  It is defined in zope.security:meta.zcml along with the permission/
  directive, so should be usable with any code that uses that.
  
  This only affects ZCML.  It caused declarations for the old permission
  to be mapped to the new one. It doesn't affect stored permissions.
 
 Maybe the short-term fix would be to add a shim package (reviving
 'zope.app.dublincore', maybe) whose only job in life is to make those
 permissions loadable.  Maybe the package ships with some code to help
 write the evolve script, or something.
 
 In the meanwhile, folks with persistent permissions should pin the
 version of zope.dublincore == 3.6.0.

*Please* mention this in the changelog in big fat letters.

People who upgrade, say, from the 3.4 KGS to BlueBream 1.0 won't
necessarily have read every zope-dev discussion for the last three
years.

Marius Gedminas
-- 
http://pov.lt/ -- Zope 3 consulting and development


signature.asc
Description: Digital signature
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] [Checkins] SVN: zope.dublincore/trunk/ Renamed the ``zope.app.dublincore.*`` permissions to ``zope.dublincore.*`.

2010-04-23 Thread Michael Howitz
Am 19.04.2010 um 22:21 schrieb Tres Seaver:
 Log message for revision 45:
  Renamed the ``zope.app.dublincore.*`` permissions to ``zope.dublincore.*`.
 
  Applications may need to fix up grants based on the old permissions.
 
   fixes lp:566724
 
 
 Changed:
  U   zope.dublincore/trunk/CHANGES.txt
  U   zope.dublincore/trunk/src/zope/dublincore/configure.zcml
 
 -=-
 Modified: zope.dublincore/trunk/CHANGES.txt
 ===
 --- zope.dublincore/trunk/CHANGES.txt 2010-04-19 20:19:54 UTC (rev 44)
 +++ zope.dublincore/trunk/CHANGES.txt 2010-04-19 20:21:52 UTC (rev 45)
 @@ -5,6 +5,9 @@
 3.6.1 (2010-04-19)
 ==
 
 +- Renamed the ``zope.app.dublincore.*`` permissions to ``zope.dublincore.*`.
 +  Applications may need to fix up grants based on the old permissions.

Hi Tres,

It's fine to rename these permissions, I like it.

But this change is so big that it requires a new major version of this package: 
it requires changes in other packages, too, as you already said in your log 
message.

Could you please:
- unmerge these changes from the 3.6 branch and re-release a new 3.6.3 without 
the permission renaming,
- do a new 3.7.0 release including the renaming and
- depend on the 3.7 release in the packages where you updated ftesting.zcml to 
use the new permissions (zope.app.file and zope.app.container)?

Thanks in advance.

Yours sincerely,
-- 
Michael Howitz · m...@gocept.com · software developer
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1
Zope and Plone consulting and development

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] [Checkins] SVN: zope.dublincore/trunk/ Renamed the ``zope.app.dublincore.*`` permissions to ``zope.dublincore.*`.

2010-04-23 Thread Jacob Holm
Hi Michael, Tres

I agree a new major version is required due to the new feature of
having new permission names, but there is no reason to break
compatibility with code using the old names.

IIRC the redefinePermission/ zcml-directive  is there exactly to
provide backwards compatibility when renaming permissions.  Use like:

  redefinePermission
  from = no longer defined permisison id
  to = existing permission id
  /

It is defined in zope.security:meta.zcml along with the permission/
directive, so should be usable with any code that uses that.


Best regards

 - Jacob


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] [Checkins] SVN: zope.dublincore/trunk/ Renamed the ``zope.app.dublincore.*`` permissions to ``zope.dublincore.*`.

2010-04-23 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jacob Holm wrote:
 Hi Michael, Tres
 
 I agree a new major version is required due to the new feature of
 having new permission names, but there is no reason to break
 compatibility with code using the old names.
 
 IIRC the redefinePermission/ zcml-directive  is there exactly to
 provide backwards compatibility when renaming permissions.  Use like:
 
   redefinePermission
   from = no longer defined permisison id
   to = existing permission id
   /
 
 It is defined in zope.security:meta.zcml along with the permission/
 directive, so should be usable with any code that uses that.

Thanks for pointing out that directive, whose existence I had forgotten.
 Assuming we put the 'redefinePermssion' directives in place on the
trunk, why shouldn't we leave the version number as is?  I consider the
rename a bugfix, not a feature, and if we make it backwared compatible,
there is no reason to bump the major version.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkvRnlwACgkQ+gerLs4ltQ5etgCg3UwAT0AGU+cu26+bLBbCRBp4
SG0AniEokjNlI9ReKVZu4Htu13wn2CQM
=c0vh
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] [Checkins] SVN: zope.dublincore/trunk/ Renamed the ``zope.app.dublincore.*`` permissions to ``zope.dublincore.*`.

2010-04-23 Thread Jacob Holm
Hi Tres

Tres Seaver wrote:
  Assuming we put the 'redefinePermssion' directives in place on the
 trunk, why shouldn't we leave the version number as is?  I consider the
 rename a bugfix, not a feature, and if we make it backwared compatible,
 there is no reason to bump the major version.

It's a (minor) public API change.  IIRC we don't allow that in minor
versions, even if it is just an addition.  This goes back to the whole
discussion of what kinds of version requirements to allow in setup.py.

 - Jacob
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] [Checkins] SVN: zope.dublincore/trunk/ Renamed the ``zope.app.dublincore.*`` permissions to ``zope.dublincore.*`.

2010-04-23 Thread Michael Howitz
Am 23.04.2010 um 15:19 schrieb Tres Seaver:
[...]
 Thanks for pointing out that directive, whose existence I had forgotten.
 Assuming we put the 'redefinePermssion' directives in place on the
 trunk, why shouldn't we leave the version number as is?  I consider the
 rename a bugfix, not a feature, and if we make it backwared compatible,
 there is no reason to bump the major version.

When it is fully backwards compatible I do not see a reason to bump the major 
version.
Otherwise it is required according to the ZTK steering group decisions[1].


[1] ... http://docs.zope.org/zopetoolkit/steeringgroup/decisions.html (sorry, 
there is no anchor for the list item I mean)


Yours sincerely,
-- 
Michael Howitz · m...@gocept.com · software developer
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1
Zope and Plone consulting and development

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] [Checkins] SVN: zope.dublincore/trunk/ Renamed the ``zope.app.dublincore.*`` permissions to ``zope.dublincore.*`.

2010-04-23 Thread Fred Drake
On Fri, Apr 23, 2010 at 3:08 PM, Tres Seaver tsea...@palladion.com wrote:
 Done.  The 3.6.3 release is up on PyPI:

I guess I should get out more; just noticed this thread.

Changing the stored permission names is a big deal.  If a permission
gets stored with zope.dublincore 3.6.3, then an instance running
3.6.(0|1) can't use it.  This creates a problem for rolling restarts,
where a permission stored by an instance with 3.6.3 may be accessed by
an instance using 3.6.1 (or an even older version).

Here's another possible approach:

- Keep the zope.app.dublincore.* permissions in 3.6.x, with
forward-compatibility adjustments in the ZCML, using

meta:redefinePermission
from=zope.dublincore.change
to=zope.app.dublincode.change
/

- Change the permission names and add backward compatible ZCML in 3.7.x:

meta:redefinePermission
from=zope.app.dublincode.change
to=zope.dublincore.change
/

 and the trunk is updated to indicate a forthcoming 3.7.0 release minus
 the BBB shims:

If this even needs to be done, I'd like to see it be 4.0.0, because
it's incompatible.

This just doesn't seem valuable to me.


  -Fred

-- 
Fred L. Drake, Jr.fdrake at gmail.com
Chaos is the score upon which reality is written. --Henry Miller
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] [Checkins] SVN: zope.dublincore/trunk/ Renamed the ``zope.app.dublincore.*`` permissions to ``zope.dublincore.*`.

2010-04-23 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Fred Drake wrote:
 On Fri, Apr 23, 2010 at 3:08 PM, Tres Seaver tsea...@palladion.com wrote:
 Done.  The 3.6.3 release is up on PyPI:
 
 I guess I should get out more; just noticed this thread.
 
 Changing the stored permission names is a big deal.  If a permission
 gets stored with zope.dublincore 3.6.3, then an instance running
 3.6.(0|1) can't use it.  This creates a problem for rolling restarts,
 where a permission stored by an instance with 3.6.3 may be accessed by
 an instance using 3.6.1 (or an even older version).
 
 Here's another possible approach:
 
 - Keep the zope.app.dublincore.* permissions in 3.6.x, with
 forward-compatibility adjustments in the ZCML, using
 
 meta:redefinePermission
 from=zope.dublincore.change
 to=zope.app.dublincode.change
 /
 
 - Change the permission names and add backward compatible ZCML in 3.7.x:
 
 meta:redefinePermission
 from=zope.app.dublincode.change
 to=zope.dublincore.change
 /
 
 and the trunk is updated to indicate a forthcoming 3.7.0 release minus
 the BBB shims:
 
 If this even needs to be done, I'd like to see it be 4.0.0, because
 it's incompatible.
 
 This just doesn't seem valuable to me.

I disagree, pretty strongly:  making code forever responsible for bad
old data is responsible for a lot of horrors in both Zope2 and Zope3
code bases.  Releasing the packages separately allows the folks who need
time to fix the data to have it, while still allowing development to
continue without the burden.

If you are running with a 3.6.x version of zope.dublincore, and you have
persisted the permissions somehow, then you need to *evolve the data*
before upgrading to 3.7.0.  That is why 3.7.0 got the bump from 3.6.x.
If you can't afford (yet) to evolve the data, then don't upgrade the
package until you can.  Running with 3.6.3 allows you to use either
permission, as the zope.app.dublincore versions get upgraded in place to
zope.dublincore equivalents.

Or are you saying that the way 3.6.3 uses meta:redefinePermission won't
work for persisted permissions?


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkvSF+oACgkQ+gerLs4ltQ7vVwCeMHD4uK8I60XpQ/ztWM9NJe/j
tPEAn0g2jp23wm+WM9aPlRBlaHeQXNgv
=i/iU
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] [Checkins] SVN: zope.dublincore/trunk/ Renamed the ``zope.app.dublincore.*`` permissions to ``zope.dublincore.*`.

2010-04-23 Thread Jim Fulton
On Fri, Apr 23, 2010 at 4:18 AM, Jacob Holm j...@improva.dk wrote:
 Hi Michael, Tres

 I agree a new major version is required due to the new feature of
 having new permission names, but there is no reason to break
 compatibility with code using the old names.

 IIRC the redefinePermission/ zcml-directive  is there exactly to
 provide backwards compatibility when renaming permissions.  Use like:

  redefinePermission
      from = no longer defined permisison id
      to = existing permission id
      /

 It is defined in zope.security:meta.zcml along with the permission/
 directive, so should be usable with any code that uses that.

This only affects ZCML.  It caused declarations for the old permission
to be mapped to the new one. It doesn't affect stored permissions.

Jim

-- 
Jim Fulton
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] [Checkins] SVN: zope.dublincore/trunk/ Renamed the ``zope.app.dublincore.*`` permissions to ``zope.dublincore.*`.

2010-04-23 Thread Jim Fulton
On Fri, Apr 23, 2010 at 5:58 PM, Tres Seaver tsea...@palladion.com wrote:
...
 I disagree, pretty strongly:  making code forever responsible for bad
 old data is responsible for a lot of horrors in both Zope2 and Zope3
 code bases.  Releasing the packages separately allows the folks who need
 time to fix the data to have it, while still allowing development to
 continue without the burden.

 If you are running with a 3.6.x version of zope.dublincore, and you have
 persisted the permissions somehow, then you need to *evolve the data*
 before upgrading to 3.7.0. That is why 3.7.0 got the bump from 3.6.x.

The bump to 3.7 would be due to a feature change. A backward-incompatible
change would require a bump to 4.

 If you can't afford (yet) to evolve the data, then don't upgrade the
 package until you can.  Running with 3.6.3 allows you to use either
 permission, as the zope.app.dublincore versions get upgraded in place to
 zope.dublincore equivalents.

No. The declarations you give in 3.6.3 cause the new names to be
mapped back to the old.

 Or are you saying that the way 3.6.3 uses meta:redefinePermission won't
 work for persisted permissions?

It will.  The redefinePermission change you propose for 3.7 won't,
which makes it
backward incompatible, which means it should be a 4.0 release.

Jim

-- 
Jim Fulton
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] [Checkins] SVN: zope.dublincore/trunk/ Renamed the ``zope.app.dublincore.*`` permissions to ``zope.dublincore.*`.

2010-04-23 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jim Fulton wrote:
 On Fri, Apr 23, 2010 at 4:18 AM, Jacob Holm j...@improva.dk wrote:
 Hi Michael, Tres

 I agree a new major version is required due to the new feature of
 having new permission names, but there is no reason to break
 compatibility with code using the old names.

 IIRC the redefinePermission/ zcml-directive  is there exactly to
 provide backwards compatibility when renaming permissions.  Use like:

  redefinePermission
  from = no longer defined permisison id
  to = existing permission id
  /

 It is defined in zope.security:meta.zcml along with the permission/
 directive, so should be usable with any code that uses that.
 
 This only affects ZCML.  It caused declarations for the old permission
 to be mapped to the new one. It doesn't affect stored permissions.

Maybe the short-term fix would be to add a shim package (reviving
'zope.app.dublincore', maybe) whose only job in life is to make those
permissions loadable.  Maybe the package ships with some code to help
write the evolve script, or something.

In the meanwhile, folks with persistent permissions should pin the
version of zope.dublincore == 3.6.0.



Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkvSG78ACgkQ+gerLs4ltQ4vsACfZA75jbybxkv+RZO4qW7R/6nO
djoAoK1aFiODO5/zr2pl1DIIITgYHkrj
=dEXv
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] [Checkins] SVN: zope.dublincore/trunk/ Renamed the ``zope.app.dublincore.*`` permissions to ``zope.dublincore.*`.

2010-04-23 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jim Fulton wrote:
 On Fri, Apr 23, 2010 at 5:58 PM, Tres Seaver tsea...@palladion.com wrote:
 ...
 I disagree, pretty strongly:  making code forever responsible for bad
 old data is responsible for a lot of horrors in both Zope2 and Zope3
 code bases.  Releasing the packages separately allows the folks who need
 time to fix the data to have it, while still allowing development to
 continue without the burden.

 If you are running with a 3.6.x version of zope.dublincore, and you have
 persisted the permissions somehow, then you need to *evolve the data*
 before upgrading to 3.7.0. That is why 3.7.0 got the bump from 3.6.x.
 
 The bump to 3.7 would be due to a feature change. A backward-incompatible
 change would require a bump to 4.
 
 If you can't afford (yet) to evolve the data, then don't upgrade the
 package until you can.  Running with 3.6.3 allows you to use either
 permission, as the zope.app.dublincore versions get upgraded in place to
 zope.dublincore equivalents.
 
 No. The declarations you give in 3.6.3 cause the new names to be
 mapped back to the old.

That was Fred, no me:  my declarations mapped the old names forward to
the new.

 Or are you saying that the way 3.6.3 uses meta:redefinePermission won't
 work for persisted permissions?
 
 It will.  The redefinePermission change you propose for 3.7 won't,
 which makes it
 backward incompatible, which means it should be a 4.0 release.

I didn't propose a redefinePermission change for 3.7:  I proposed to
drop the (misnamed) permissions altogether from zope.dublincore.

Why should zope.dublincore be carrying BBB-water for
zope.app.dublincore?  We have plenty of precedent for having the
zope.app. version of the package stick around *purely* for BBB:  let's
do that in this case.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkvSHt0ACgkQ+gerLs4ltQ4APQCgkC1Dc7+0ZANwfaTbE33a0WzS
jJoAoKggDdu2TWZ9byhTWPSH/vsyJHh5
=RcJB
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] [Checkins] SVN: zope.dublincore/trunk/ Renamed the ``zope.app.dublincore.*`` permissions to ``zope.dublincore.*`.

2010-04-23 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tres Seaver wrote:

 Why should zope.dublincore be carrying BBB-water for
 zope.app.dublincore?  We have plenty of precedent for having the
 zope.app. version of the package stick around *purely* for BBB:  let's
 do that in this case.

Even better:  sites with persietent permissions no longer supplied by
zope.dublincore can just add those permission declarations to their
site.zcml:  no software change involved, because ZCML is configuration /
policy.

The default configurations provided by packages like zope.dublincore
are just that, default, starting points.  Reusable policy is an oxymoron.



Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkvSZrUACgkQ+gerLs4ltQ6RzACgnM2iONhqjBH3uIHhDQn46DIL
k1AAnRXV9F+VjYyzBqTt34lxzDQ4OdNb
=9JjA
-END PGP SIGNATURE-

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )