from:"Hanno Schlichting"

Hi.

I released Zope 2.12.9 and Zope 2.13.0a2 today. Both contain a fix for
the missing browser:view permission support
(https://bugs.launchpad.net/zope2/+bug/578326). As this might affect
security of your applications, you are advised to upgrade. Zope 2
itself is not vulnerable. Thanks goes to Martin Aspeli for
implementing this support on short notice.

In other news Zope 2.13.0a2 now officially supports Python 2.7.
Special thanks to David Glick for performing the security audit of
RestrictedPython. You can read more about the changes at
http://docs.zope.org/zope2/releases/2.13/CHANGES.html.

All the best,
Hanno
___
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 )

[Zope-dev] Can ZTK 1.0 support Python 2.7?

Hi.

We have Python 2.7 final now and some work has begun on making ZTK
packages compatible with it. Currently we still see various test
failures in the zopeapp set though and nobody who steps up to fix
them.

Apart from that, we have made a promise to support Python 2.4 up to
2.6 for the ZTK 1.0 release. The ZODB 3.10 releases do no longer
support Python 2.4 but require 2.5. The ZODB 3.9.x releases are in
maintenance mode for a while and currently don't support Python 2.7. I
doubt that we can get official 2.7 support for the 3.9.x release line.

Given all of these, I'm leaning towards not supporting Python 2.7 for
a ZTK 1.0 release. A 1.1 can drop Python 2.4 support and we can try to
support 2.7 in addition.

What do others think about this?

Hanno

P.S. We talked about a rough timeline for a ZTK 1.0 release in the
release team. We are aiming to get a beta out in early August (once we
are all back from vacation). Test failures on any of the supported
platforms are blocking such a release. This includes any failures we
get on Windows. Hopefully more community members will step up and help
fix those.
___
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] Can ZTK 1.0 support Python 2.7?

On Tue, Jul 13, 2010 at 3:07 PM, Stephan Richter
srich...@cosmos.phy.tufts.edu wrote:
 On Tuesday, July 13, 2010, Hanno Schlichting wrote:
 What do others think about this?

 Based on what you wrote, I think this is the right solution. Python 2.4 is
 clearly important to the Zope 2 / Plone world.

Actually both Zope2 and Plone 4 (as a potential user of the ZTK) are
requiring Python 2.6 and don't even support Python 2.5 anymore.

It's BlueBream and direct ZTK consumers that asked for the Python 2.4
support ;-)

Anyways we decided to keep Python 2.4 for a ZTK release and codified
that at http://docs.zope.org/zopetoolkit/process/python-versions.html

Hanno
___
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] New releases of Zope2 (incl. a potential security fix)

On Tue, Jul 13, 2010 at 3:08 PM, Stephan Richter
srich...@cosmos.phy.tufts.edu wrote:
 On Tuesday, July 13, 2010, Hanno Schlichting wrote:
 In other news Zope 2.13.0a2 now officially supports Python 2.7.

 How can Zope 2.13 support Python 2.7, when the ZTK 1.0 does not?

Zope 2.13 only uses the ZTK core part and overrides the ZODB3
requirement to use a 3.10 release. All tests on Python 2.7 pass for
all the zope.* packages. It's only the zopeapp set and the ZODB which
aren't compatible.

So from a Zope2 perspective we can support Python 2.7 in addition to
2.6 rather easily. Since everything works, it doesn't make a lot of
sense to hold off official 2.7 support. The ZTK has more code and
other Python versions to support, so it's in a different position.

Hanno
___
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] Can ZTK 1.0 support Python 2.7?

On Tue, Jul 13, 2010 at 3:23 PM, Charlie Clark
charlie.cl...@clark-consulting.eu wrote:
 what's the time frame for ZTK 1.0?

I put that info into the post scriptum of my mail.

 Have I missed a mail with more failures? I would have thought getting
 those tests to pass for a release is a reasonable aim.

You have. It's only bin/test-ztk that passes. bin/test-zopeapp still
has a number of failures.

Hanno
___
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] Zope 2.12.9 broke ZMySQLDA in the middle of a stable release series

Hi.

On Tue, Jul 13, 2010 at 5:13 PM, Leonardo Rochael Almeida
leoroch...@gmail.com wrote:
The latest Zope 2.12.9 release broke the last release of Products.ZMySQLDA.

You are not by any chance interested in taking over maintenance of
ZSQLMethods, are you?

You'll get the following traceback:

Traceback (most recent call last):
File bin/py, line 107, in module
exec _val
File string, line 1, in module
File
/home/leo/opt/zmysqlda/eggs/Products.ZMySQLDA-3.1-py2.6.egg/Products/ZMySQLDA/__init__.py,
line 90, in module
import DA
File
/home/leo/opt/zmysqlda/eggs/Products.ZMySQLDA-3.1-py2.6.egg/Products/ZMySQLDA/DA.py,
line 243, in module
os.path.join('Shared','DC','ZRDB','www','DBAdapterFolder_icon.gif'))}
File
/home/leo/opt/zmysqlda/eggs/Zope2-2.12.9-py2.6-linux-x86_64.egg/App/ImageFile.py,
line 77, in __init__
stat_info = os.stat(path)
OSError: [Errno 2] No such file or directory:
'/home/leo/opt/zmysqlda/eggs/Zope2-2.12.9-py2.6-linux-x86_64.egg/Shared/DC/ZRDB/www/DBAdapterFolder_icon.gif'

The most trivial fix seems fairly obvious: ZMySQLDA should carry its
own icon, but in any case, Zope 2.12 should not break compatibility in
the middle of a stable series. I strongly suspect other Zope2 DB
adapters to suffer from the same problem.

We documented it pretty clearly in the Zope 2.12.0 release notes, that
you can no longer rely on software home or zope home. See for example
http://docs.zope.org/zope2/releases/2.12/WHATSNEW.html#fully-eggified

The code should have long been changed to import Shared.DC.ZRDB and
then os.path.join(ZRDB.__file__, 'www', 'DBAdapterFolder_icon.gif') or
better yet use its own icon. Both of these would have worked with all
2.12.x releases.

I'm not sure what the proper fix should be. App.ImageFile.ImageFile
could grow support for icons outside of software_home, or perhaps the
spinning-off of Shared.DC.ZRDB should be delayed to the 2.13 series
only, but in any case the 2.12 branch should be a safe upgrade for
third party code as much as reasonably possible.

We don't make guarantees on internals. Zope 2 always had a policy of
allowing minor changes and new features to occur in the stable release
series. It's not just pure bugfix releases.

I think in this case the code in Products.ZMySQLDA should be changed
to be compatible with Zope 2.12.

Hanno
___
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] Can ZTK 1.0 support Python 2.7?

On Tue, Jul 13, 2010 at 2:12 PM, Hanno Schlichting ha...@hannosch.eu wrote:
 Given all of these, I'm leaning towards not supporting Python 2.7 for
 a ZTK 1.0 release. A 1.1 can drop Python 2.4 support and we can try to
 support 2.7 in addition.

We discussed this in todays zope-dev IRC meeting. There was general
support for this approach.

The 1.1 release should follow the 1.0 release rather soon in this case.

I'll bring it up in the release team.

Thanks all,
Hanno
___
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] Zope 2.12.9 broke ZMySQLDA in the middle of a stable release series

On Tue, Jul 13, 2010 at 7:05 PM, Leonardo Rochael Almeida
leoroch...@gmail.com wrote:
 And I'm not disagreeing with the policy, but it can be argued that
 depending on the location of *data* files inside the Zope2 package is
 not necessarily relying on guarantees on internals.

I'd call anything that relies on a specific file system layout to be
internals. We only make guarantees on the semantics of the Python
import system, not how packages and modules are stitched together in
distributions and end up on the file system.

 Obviously. Still, App.ImageFile.ImageFile (and any other Zope2 APIs
 that do rely on software_home) should give a clear warning when
 software_home is assumed, since it is the one assuming it. The
 exception raised by the ImageFile call now gives no clue on what
 actually went wrong and what a developer should do about it.

I agree with that. I thought the call to software home was being made
inside ZMySQLDA and not in Zope 2 code.

Hanno
___
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] Changelog of differences between ztk 1.0a1 and 1.0a2?

2010-07-12 Thread Hanno Schlichting

On Mon, Jul 12, 2010 at 8:42 AM, Michael Howitz m...@gocept.com wrote:
 is there a change log showing the differences between versions 1.0a1 and the 
 lately released 1.0a2 of the ztk?

There's no changelog yet. Diff'ing the files from the tags is the best
you get right now.

We are planning to automatically generate one. The code for doing so
in out there, we just need to adjust it and put it in somewhere.
Probably into the script that generates
http://docs.zope.org/zopetoolkit/releases/packages-1.0a2.html.

Hanno
___
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] [zope2] Help needed with security checks and add views

2010-07-10 Thread Hanno Schlichting

On Sat, Jul 10, 2010 at 12:14 PM, Martin Aspeli
optilude+li...@gmail.com wrote:
 Fixed in r114488 (2.12 branch) and r114490 (trunk). I don't think I'm
 allowed to close the issue on Launchpad, but it should be fine now.

Awesome! You truly rock!

Much appreciated,
Hanno
___
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] [zope2] Help needed with security checks and add views

On Thu, Jul 8, 2010 at 3:02 PM, Martin Aspeli optilude+li...@gmail.com wrote:
 Ideally I'd love to add support for the permission attribute, as
 clearly people have been using it. But if there's nobody who can
 figure out how to do that, I'd at least like to clarify the add view
 case.

 Why can't we just copy the relevant code from the browser:page directive?

 The ViewSecurityGrokker in
 http://svn.zope.org/five.grok/trunk/src/five/grok/meta.py?rev=112163view=auto
 may be useful reading too. It should be doing the same thing, no?

It seems you have some idea about this code, so are you volunteering
to implement this?

Since we are dealing with a disclosed real security vulnerability
here, I need to have some resolution by next Tuesday. Either that is
disabling the functionality or protecting it with some security.

Hanno
___
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] zope.traversing's ILocation behavior

On Fri, Jul 9, 2010 at 2:03 PM, Martijn Faassen faas...@startifact.com wrote:
 [zope.traversing absolute URL behavior]

 I've applied the fix to zope.traversing and added a test as well. It's
 released as zope.traversing. I've also updated the ZTK to use this version.

Thanks!

 (initially I used checkversions to update a few other packages too,
 namely zope.dublincore, zope.index, zope.pagetemplate and zope.testing,
 but this *did* result in zopeapp breakages, so I reverted that quickly.
 Someone needs to look into this to see what can be upgraded and what
 causes the break later)

I think zope.dublincore causes the breakage in some zope.app packages.
zope.index and zope.pagetemplate should be upgraded. zope.testing
3.9.5 will throw deprecation warnings for not using zope.testrunner.
The release team decided to keep the current zope.testing /
zc.testrunner recipe for the ZTK 1.0 release, so we stick to
zope.testing 3.9.4 for the time being.

Hanno
___
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] audit of RestrictedPython for Python 2.7

Hi David,

awesome work!

Sidnei or Stephan, can one of you comment on David's approach or offer a review?

Cheers,
Hanno

On Fri, Jul 9, 2010 at 5:42 AM, David Glick davidgl...@groundwire.org wrote:
 I am done (as far as I can tell) evaluating RestrictedPython to see if
 changes are needed to support Python 2.7. This is the first time I have
 done this, so would appreciate if someone else can look over my work to
 make sure I'm not missing something important.  I'll describe my process
 and findings below.

 The basic summary is that Python 2.7 adds a small number of syntactic
 features and they are already handled adequately by RestrictedPython.  I
 added some tests for these on a branch,
 http://svn.zope.org/repos/main/RestrictedPython/branches/davisagli-python27,
 which I can merge once someone else has looked over them. In addition, I
 discovered the omission of a name check for the from x import y style
 import; this is also fixed on the branch.

 To go into detail...

 I started by reading RestrictedPython (henceforth referred to as RP) to
 familiarize myself with how it works. Next I read the What's New in
 Python 2.7 document and noted features that might require changes in
 RP. Then I went through each of these and looked at the corresponding
 changes in the Python compiler, bytecode generator and evaluator to
 further check on whether changes were needed. Here are the items I
 checked and my conclusions...

 - dict and set comprehensions: These need to use RP's safe _getitem_ to
 iterate. This was already taken care of because these new comprehensions
 use the same ListCompFor AST node that list comprehensions do.

 - set literals: These build a new set based on the result of evaluating
 other AST nodes that RP already protects, so should be safe.

 - multiple context managers in one with statement: I wrote a test to
 confirm that the existing name check for context managers still works
 when there are multiple ones.

 - the 'with' statement now uses a new opcode SETUP_WITH that does an
 unprotected lookup of the '__enter__' and '__exit__' methods of the
 context manager.  I don't think this is a problem, since methods
 starting with an underscore can't be defined in RP.

 - dictionary views: these don't introduce new builtins or syntax, so I
 don't think changes are necessary. To allow access to them in RP in Zope
 2 we would need to adjust the dict method whitelist in
 AccessControl.ZopeGuards to allow viewitems, viewkeys, and viewvalues.

 - new builtins memoryview, bytes, and bytearray: For now I punted and
 these are not included in RP's safe_builtins list. memoryview and
 bytearray should probably not be added. bytes is just a synonym for str
 in Python 2.7 afaict, so would probably be okay to add.

 - explicit relative imports (from .x import y): These are covered by the
 name check I added (as noted above in the summary) for from x import y
 imports in general.

 - except x as y: Added a test to show that this is already covered.

 Finally, to double-check my work I did diffs of Lib/compiler/ast.py and
 Python/ceval.c in the Python source to check for any new AST nodes or
 opcodes that I had overlooked above. This didn't yield any new concerns
 that I hadn't already considered.

 peace,
 David
___
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 )

[Zope-dev] Including Paste into the ZTK version list?

Hi.

I noticed that all three frameworks (BB, Grok, Zope2) have version
pins for Paste, PasteDeploy and PasteScript. Does anyone object to
including them into the ztk-versions.cfg under dependencies?

It's currently:

Paste = 1.7.4
PasteDeploy = 1.3.3
PasteScript = 1.7.3

Note that Paste 1.7.4 addresses a security issue [1], so you should
update it regardless.

Hanno

[1] 
http://pylonshq.com/articles/archives/2010/6/paste_174_released_addresses_xss_security_hole
___
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] [ZTK] toolchain versions

Hi.

On Fri, Jul 9, 2010 at 6:37 PM, Christophe Combelles cc...@free.fr wrote:
 http://svn.zope.org/zopetoolkit/trunk/ztk-versions.cfg?rev=114375view=auto

 is there any reason why the versions pinning of the toolchain are in the
 ztk-versions.cfg ?  Packages such as z3c.recipe.depgraph, mr.developer,
 z3c.checkversions have nothing to do with the final frameworks nor the ZTK.

 Shouldn't they be isolated to a [versions] section in the buildout?

We talked about this in one of our meetings :)

Having the toolchain inside the ztk-versions.cfg makes it easier to
extend the ZTK. Zope 2 just has to use a single extends= line and Grok
just two (for the additional zopeapp-versions.cfg).

Since we all use the toolchain anyways, we didn't see a point in
separating them out.

Hanno
___
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] Python 2.7 on the apfy buildbots

On Fri, Jul 9, 2010 at 9:04 PM, Christophe Combelles cc...@free.fr wrote:
 The afpy buildbots now all run a slave with Python 2.7 final
 http://buildbot.afpy.org/

Yeah!

Jan-Jaap and Sebastien, could you update your buildouts as well?
Python 2.7 should run for the ZTK trunk, zc.buildout and Zope 2 trunk.
I'm not sure about Grok.

Thanks,
Hanno
___
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] Python 2.7 on the apfy buildbots

On Fri, Jul 9, 2010 at 9:17 PM, Christophe Combelles cc...@free.fr wrote:
 However, the 2.7 slaves don't send any alert to the zope-tests list. Should I
 enable this?

The winbot already sends reports for Python 2.7, so I'd say go ahead
and spam us :) More blame might get someone to fix those two last
zope.app packages.

Hanno
___
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 )

[Zope-dev] [zope2] Looking for a maintainer for ZSQLMethods / Shared.DC.ZRDB

Hi.

Are you using Products.ZSQLMethods or DC.Shared.ZRDB? Are you
interested in maintaining it?

Starting with Zope 2.13 these packages are no longer part of the Zope
2 distribution. The code has moved to its own project, as the core
Zope 2 developers haven't had a strong interest in it anymore.

Please speak up if you want to take over maintenance of the code and
I'll gladly hand over the keys. The projects is registered on PyPi
at http://pypi.python.org/pypi/Products.ZSQLMethods, has a Launchpad
bug tracker at https://launchpad.net/products.zsqlmethods (including
some bugs moved over from the Zope2 project) and the code lives at
svn+ssh://svn.zope.org/repos/main/Products.ZSQLMethods/trunk.

Cheers,
Hanno
___
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] [zope2] Help needed with security checks and add views

2010-07-08 Thread Hanno Schlichting

Hi.

As a reminder: If nobody is able to help with this, I'll disable the
insecure view registration in Zope2 and release new versions Tuesday
13th.

From my understanding of the code, Zope 2 itself is not vulnerable, as
there's no registrations for IFactory utilities included. But in any
system that has such registrations, anonymous users should be able to
create any such content item in any location.

Hanno

On Sat, Jun 26, 2010 at 6:24 PM, Hanno Schlichting ha...@hannosch.eu wrote:
 recently MJ opened a security related bug and disclosed it to the
 public at https://bugs.launchpad.net/zope2/+bug/578326.

 In short Zope 2 never supported the permission attribute on ZCML
 browser:view declarations. It seems some people might have specified
 this attribute and assumed it would do something.

 I have added a warning message to Zope 2 (trunk + 2.12 branch) which
 warns about those cases. This is similar to how we handle other such
 cases like the unsupported require set_schema=.. / and require
 set_attributes=... / on class directives.

 But it turns out that Zope 2 itself is using this in one place, that
 looks like it ought to have a security declaration. The
 Products.Five.adding.ContentAdding class registered as an add view
 (+) has no working security declarations I can see, and only has
 such a non-functioning permission=zope2.ViewManagementScreens set.
 I'm not familiar enough with the add view concept to understand what
 this is doing. It also looks like both CMF and Plone use similar
 registrations for their add views.

 Ideally I'd love to add support for the permission attribute, as
 clearly people have been using it. But if there's nobody who can
 figure out how to do that, I'd at least like to clarify the add view
 case.
___
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] zope.traversing's ILocation behavior

2010-07-08 Thread Hanno Schlichting

On Thu, Jul 8, 2010 at 5:04 PM, Martijn Faassen faas...@startifact.com wrote:
 The fix in my code was to make my model provide ILocation itself, so
 that it would adapt itself and therefore avoid the proxy. I think that
 might be correct but at the same time is really obscure; in my code the
 __parent__ is provided by a completely different subsystem (traject).
 Models that didn't provide ILocation used to work, and now they fail. Do
 we really want to require everybody to start providing ILocation in all
 their models?

 I propose the following adjustment:

   try:
      container = context.__parent__
   except AttributeError:
      container = ILocation(context).__parent__

 So, try to find the __parent__ the old way first, without adapter
 lookup. If that fails because the attribute is missing, look up the
 adapter. That might get one the proxy again, but at least not when a
 __parent__ is actually available. Still, this deserves some commenting
 for future people trying to debug what's going on.

 I've verified that at least in my application this unbreaks the code.
 I'll also try to add a test that demonstrates the expected behaviors so
 that this doesn't get broken again.

 Opinions?

I think this sounds reasonable. In Zope 2 Acquisition wrappers provide
__parent__ pointers, but they don't implement ILocation either. I
think the presence of the __parent__ pointer is the established
protocol, independent of the ILocation interface.

Hanno

P.S. Acquisition wrappers don't have interfaces of their own, but
defer all lookups to the wrapped object, so letting them provide
ILocation without changing the model classes isn't easily possible.
___
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] Python 2.7 disables deprecation warnings by default

2010-07-07 Thread Hanno Schlichting

On Wed, Jul 7, 2010 at 12:55 PM, Jim Fulton j...@zope.com wrote:
 I'm not sure what the best way to handle this is.  My initial thought
 is that all test runners should enable deprecations by default.  This
 seems hard to enforce.

 Individual test modules can do this, but I'm uncomfortable having a
 test script make a global setting like this and the warning module
 doesn't seem to provide a way to capture the current state so it can
 be reset after running tests.

What about letting the testrunner (zope.testing / zope.testrunner)
enable deprecation warnings by default, but add a command line switch
to disable them or use the Python default?

The test.py script from Zope 2 used to have a --nowarn option to
disable all warnings.

I think developers should always care about deprecation warnings and
it's only developers who will run tests. I can understand why normal
users of a Python program shouldn't see deprecation warnings - they
usually cannot do anything about them. I also heard many reports from
people asking questions about those deprecation warnings in a Plone
context. Normal users don't know the difference between a deprecation
warning and a SyntaxError or any other warning for that matter. All
they see is a warning and get anxious.

Hanno
___
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] Zope Toolkit - 1.0a1 release

2010-07-06 Thread Hanno Schlichting

On Tue, Jul 6, 2010 at 4:54 PM, Fred Drake fdr...@acm.org wrote:
 I've yet to hear any response to my post about non-backward-compatible 
 classes:

    https://mail.zope.org/pipermail/zope-dev/2010-July/040898.html

 Is no one else concerned about the backward incompatibility introduced
 by zope.pluggableauth.plugins.session.SessionCredentialsPlugin?

Apparently not :)

But your proposal sounded good to me. Just go ahead.

Hanno
___
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] Python 2.7 and the ZTK - three test failures

2010-07-06 Thread Hanno Schlichting

Hi again.

On Mon, Jul 5, 2010 at 11:08 PM, Hanno Schlichting ha...@hannosch.eu wrote:
 with Python 2.7 final being released, I ran the ZTK tests against it.

 zope.exceptions, zope.formlib and zope.proxy all have one test output
 related failure.

I fixed all of those and released new versions. bin/test-ztk should
now pass under Python 2.7.

 RestrictedPython will need a security review.

I hear David Glick has started to look into this. Applause!

Running bin/test-zopeapp still gives failures in two packages:
zope.app.publisher and zope.app.wsgi.

I'm not familiar enough with that code to fix any of those.

Hanno

Full test output:

Running test-zopeapp-zope.app.publisher
test-zopeapp-zope.app.publisher failed with:
Running zope.app.publisher.testing.AppPublisherLayer tests:
  Set up zope.app.publisher.testing.AppPublisherLayer in 1.360 seconds.

Failure in test
/opt/eggs/zope.app.publisher-3.10.1-py2.7.egg/zope/app/publisher/xmlrpc/tests/../README.txt
Traceback (most recent call last):
  File /opt/python/parts/opt/lib/python2.7/unittest/case.py, line 318, in run
testMethod()
  File /opt/python/parts/opt/lib/python2.7/doctest.py, line 2153, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for README.txt
  File 
/opt/eggs/zope.app.publisher-3.10.1-py2.7.egg/zope/app/publisher/xmlrpc/tests/../README.txt,
line 0

--
File 
/opt/eggs/zope.app.publisher-3.10.1-py2.7.egg/zope/app/publisher/xmlrpc/tests/../README.txt,
line 65, in README.txt
Failed example:
proxy.contents()
Exception raised:
Traceback (most recent call last):
  File /opt/python/parts/opt/lib/python2.7/doctest.py, line 1248, in __run
compileflags, 1) in test.globs
  File doctest README.txt[7], line 1, in module
proxy.contents()
  File /opt/python/parts/opt/lib/python2.7/xmlrpclib.py, line
1224, in __call__
return self.__send(self.__name, args)
  File /opt/python/parts/opt/lib/python2.7/xmlrpclib.py, line
1570, in __request
verbose=self.__verbose
  File 
/opt/eggs/zope.app.testing-3.7.5-py2.7.egg/zope/app/testing/xmlrpc.py,
line 62, in request
return self._parse_response(
AttributeError: ZopeTestTransport instance has no attribute
'_parse_response'

[... snip lots more failures with the same problem ...]

  Ran 1 tests with 1 failures and 0 errors in 0.163 seconds.
Running zope.testing.testrunner.layer.UnitTests tests:
  Tear down zope.app.publisher.testing.AppPublisherLayer in 0.001 seconds.
  Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds.
  Ran 11 tests with 0 failures and 0 errors in 0.089 seconds.
Tearing down left over layers:
  Tear down zope.testing.testrunner.layer.UnitTests in 0.000 seconds.
Total: 12 tests, 1 failures, 0 errors in 1.791 seconds.



Running test-zopeapp-zope.app.wsgi
test-zopeapp-zope.app.wsgi failed with:
Running zope.app.wsgi.BrowserLayer tests:
  Set up zope.app.wsgi.BrowserLayer in 0.222 seconds.

Failure in test test_file_returns (zope.app.wsgi.tests)
Failed doctest test for zope.app.wsgi.tests.test_file_returns
  File /opt/eggs/zope.app.wsgi-3.9.2-py2.7.egg/zope/app/wsgi/tests.py,
line 61, in test_file_returns

--
File /opt/eggs/zope.app.wsgi-3.9.2-py2.7.egg/zope/app/wsgi/tests.py,
line 77, in zope.app.wsgi.tests.test_file_returns
Failed example:
browser.open('http://localhost/@@test-file-view.html')
Exception raised:
Traceback (most recent call last):
  File 
/opt/eggs/zope.testing-3.9.4-py2.7.egg/zope/testing/doctest/__init__.py,
line 1355, in __run
compileflags, 1) in test.globs
  File doctest zope.app.wsgi.tests.test_file_returns[line 16,
example 6], line 1, in module
browser.open('http://localhost/@@test-file-view.html')
  File 
/opt/eggs/zope.testbrowser-3.9.0-py2.7.egg/zope/testbrowser/browser.py,
line 237, in open
self.mech_browser.open(url, data)
  File /opt/eggs/mechanize-0.2.1-py2.7.egg/mechanize/_mechanize.py,
line 204, in open
return self._mech_open(url, data, timeout=timeout)
  File /opt/eggs/mechanize-0.2.1-py2.7.egg/mechanize/_mechanize.py,
line 231, in _mech_open
response = UserAgentBase.open(self, request, data)
  File /opt/eggs/mechanize-0.2.1-py2.7.egg/mechanize/_opener.py,
line 193, in open
response = urlopen(self, req, data)
  File /opt/eggs/mechanize-0.2.1-py2.7.egg/mechanize/_urllib2_fork.py,
line 344, in _open
'_open', req)
  File /opt/eggs/mechanize-0.2.1-py2.7.egg/mechanize/_urllib2_fork.py,
line 332, in _call_chain
result = func(*args)
  File 
/opt/eggs/wsgi_intercept-0.4-py2.7.egg/wsgi_intercept/urllib2_intercept/wsgi_urllib2.py,
line 34, in http_open
return self.do_open(WSGI_HTTPConnection, req)
  File /opt/python/parts/opt/lib/python2.7/urllib2.py, line
1142, in do_open

Re: [Zope-dev] Zope Tests: 26 OK, 10 Failed, 5 Unknown

2010-07-06 Thread Hanno Schlichting

On Tue, Jul 6, 2010 at 1:58 PM, Zope Tests Summarizer
zope-te...@epy.co.at wrote:
 Summary of messages to the zope-tests list.
 Period Mon Jul  5 12:00:00 2010 UTC to Tue Jul  6 12:00:00 2010 UTC.
 There were 41 messages: 6 from Zope Tests, 3 from buildbot at 
 enfoldsystems.com, 11 from buildbot at winbot.zope.org, 11 from ccomb at 
 free.fr, 1 from ct at gocept.com, 9 from jdriessen at thehealthagency.com.


 Test failures
 -

 Subject: FAILED : winbot / ztk_dev py_265_win64
 From: buildbot at winbot.zope.org
 Date: Mon Jul  5 22:46:05 EDT 2010
 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/016126.html

One of the test failures is this:

Running test-zopeapp-zope.app.applicationcontrol
test-zopeapp-zope.app.applicationcontrol failed with:
Running zope.app.applicationcontrol.testing.ApplicationControlLayer tests:
  Set up zope.app.applicationcontrol.testing.ApplicationControlLayer
in 1.843 seconds.
  Ran 4 tests with 0 failures and 0 errors in 0.516 seconds.
Running zope.testing.testrunner.layer.UnitTests tests:
  Tear down zope.app.applicationcontrol.testing.ApplicationControlLayer
in 0.000 seconds.
  Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds.
'svn' is not recognized as an internal or external command,
operable program or batch file.


Failure in test test_WrongLocale
(zope.app.applicationcontrol.tests.test_zopeversion.Test)
Traceback (most recent call last):
  File c:\Python26_32\lib\unittest.py, line 279, in run
testMethod()
  File 
c:\buildslave\ztk_dev_py_265_win32\build\src\zope.app.applicationcontrol\src\zope\app\applicationcontrol\tests\test_zopeversion.py,
line 136, in test_WrongLocale
self.assert_(zv.result.startswith('Development/Revision: '))
  File c:\Python26_32\lib\unittest.py, line 325, in failUnless
if not expr: raise self.failureException, msg
AssertionError


Note the 'svn' is not recognized as an internal or external command, in there.

Adam, does the build environment have Subversion installed and
accessible as svn on the path?

Hanno
___
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 )

[Zope-dev] Python 2.7 and the ZTK - three test failures

2010-07-05 Thread Hanno Schlichting

Hi there,

with Python 2.7 final being released, I ran the ZTK tests against it.

zope.exceptions, zope.formlib and zope.proxy all have one test output
related failure.

RestrictedPython will need a security review.

Any help with those appreciated,

Hanno


Full test output:

Running test-ztk-zope.formlib
test-ztk-zope.formlib failed with:
Running zope.testing.testrunner.layer.UnitTests tests:
  Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds.

Failure in test
/opt/eggs/zope.formlib-4.0.3-py2.7.egg/zope/formlib/tests/../form.txt
Traceback (most recent call last):
  File /opt/python/parts/opt/lib/python2.7/unittest/case.py, line 318, in run
testMethod()
  File /opt/python/parts/opt/lib/python2.7/doctest.py, line 2153, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for form.txt
  File /opt/eggs/zope.formlib-4.0.3-py2.7.egg/zope/formlib/tests/../form.txt,
line 0

--
File /opt/eggs/zope.formlib-4.0.3-py2.7.egg/zope/formlib/tests/../form.txt,
line 217, in form.txt
Failed example:
MyForm(None, request)() # doctest: +NORMALIZE_WHITESPACE +ELLIPSIS
Expected:
There were errors:
(u'Invalid floating point data',
 exceptions.ValueError instance at ...)
('max_size', u'Maximum size', RequiredMissing('max_size'))
input class=textType id=form.name name=form.name size=20
   type=text value=bob  /
input class=textType id=form.min_size name=form.min_size size=10
   type=text value=bob  /
span class=errorInvalid floating point data/span
input class=textType id=form.max_size name=form.max_size size=10
   type=text value=  /
span class=errorRequired input is missing./span
input class=textType id=form.color name=form.color size=20
   type=text value=  /
{'name': u'bob'}
Got:
There were errors:
(u'Invalid floating point data', ValueError('could not convert
string to float: bob',))
('max_size', u'Maximum size', RequiredMissing('max_size'))
input class=textType id=form.name name=form.name size=20
type=text value=bob  /
input class=textType id=form.min_size name=form.min_size
size=10 type=text value=bob  /
span class=errorInvalid floating point data/span
input class=textType id=form.max_size name=form.max_size
size=10 type=text value=  /
span class=errorRequired input is missing./span
input class=textType id=form.color name=form.color
size=20 type=text value=  /
{'name': u'bob'}


  Ran 398 tests with 1 failures and 0 errors in 2.037 seconds.
Tearing down left over layers:
  Tear down zope.testing.testrunner.layer.UnitTests in 0.000 seconds.


Running test-ztk-zope.proxy
test-ztk-zope.proxy failed with:
Running zope.testing.testrunner.layer.UnitTests tests:
  Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds.


Failure in test test_setProxiedObject (zope.proxy.tests.test_proxy)
Traceback (most recent call last):
  File /opt/python/parts/opt/lib/python2.7/unittest/case.py, line 318, in run
testMethod()
  File /opt/python/parts/opt/lib/python2.7/doctest.py, line 2153, in runTest
raise self.failureException(self.format_failure(new.getvalue()))
AssertionError: Failed doctest test for
zope.proxy.tests.test_proxy.test_setProxiedObject
  File 
/opt/eggs/zope.proxy-3.6.0-py2.7-macosx-10.6-x86_64.egg/zope/proxy/tests/test_proxy.py,
line 683, in test_setProxiedObject

--
File 
/opt/eggs/zope.proxy-3.6.0-py2.7-macosx-10.6-x86_64.egg/zope/proxy/tests/test_proxy.py,
line 709, in zope.proxy.tests.test_proxy.test_setProxiedObject
Failed example:
setProxiedObject(c1, None)
Expected:
Traceback (most recent call last):
TypeError: setProxiedObject() argument 1 must be zope.proxy.ProxyBase, not C
Got:
Traceback (most recent call last):
  File /opt/python/parts/opt/lib/python2.7/doctest.py, line 1248, in __run
compileflags, 1) in test.globs
  File doctest
zope.proxy.tests.test_proxy.test_setProxiedObject[9], line 1, in
module
setProxiedObject(c1, None)
TypeError: must be zope.proxy.ProxyBase, not C


  Ran 32 tests with 1 failures and 0 errors in 0.026 seconds.
Tearing down left over layers:
  Tear down zope.testing.testrunner.layer.UnitTests in 0.000 seconds.


Running test-ztk-zope.exceptions
test-ztk-zope.exceptions failed with:
Running zope.testing.testrunner.layer.UnitTests tests:
  Set up zope.testing.testrunner.layer.UnitTests in 0.000 seconds.


Failure in test testMultilineException
(zope.exceptions.tests.test_exceptionformatter.Test)
Traceback (most recent call last):
  File /opt/python/parts/opt/lib/python2.7/unittest/case.py, line 318, in run
testMethod()
  File 
/opt/eggs/zope.exceptions-3.6.0-py2.7.egg/zope/exceptions/tests/test_exceptionformatter.py,
line 160, in testMultilineException
'SyntaxError: unexpected EOF while

Re: [Zope-dev] Zope Tests: 21 OK, 8 Failed, 2 Unknown

2010-07-04 Thread Hanno Schlichting

On Sun, Jul 4, 2010 at 1:58 PM, Zope Tests Summarizer
zope-te...@epy.co.at wrote:
 Unknown
 ---

 Subject: UNKNOWN : Zope-trunk Python-2.6.5 : Linux
 From: Zope Tests
 Date: Sat Jul  3 21:30:30 EDT 2010
 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/016058.html

 Subject: UNKNOWN : Zope-trunk-alltests Python-2.6.5 : Linux
 From: Zope Tests
 Date: Sat Jul  3 21:32:30 EDT 2010
 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/016059.html

Looks like the testbox doesn't have Subversion 1.6 yet.

I asked Stefan to upgrade.

Hanno
___
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] Zope Tests: 26 OK, 2 Failed, 2 Unknown

2010-07-03 Thread Hanno Schlichting

On Sat, Jul 3, 2010 at 6:00 PM, Tres Seaver tsea...@palladion.com wrote:
 Subject: UNKNOWN : Zope-trunk-alltests Python-2.6.5 : Linux
 From: Zope Tests
 Date: Fri Jul  2 21:32:12 EDT 2010
 URL: http://mail.zope.org/pipermail/zope-tests/2010-July/016028.html

 These are due to an SSH issue:

 - - % 
 mr.developer: Queued 'DateTime' for checkout.
 mr.developer: Checked out 'DateTime' with subversion.
 mr.developer: Subversion checkout for 'DateTime' failed.
 mr.developer: Host key verification failed.
 mr.developer: svn: Connection closed unexpectedly
 mr.developer:
 mr.developer: There have been errors, see messages above.
 - - % 

 I haven't noticed any change to the SSH hostkey for svn.zope.org, so I'm
 puzzled.

I hope my commit from earlier today fixes this. DateTime is checked
out by mr.developer and that causes some slightly different SVN
interaction.

So hopefully this will work again tomorrow.

Hanno
___
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] Zope 2: move nt_svcutils to separate distribution

2010-07-02 Thread Hanno Schlichting

Hi.

I'm reviewing your branch now and will look at the nt_svcutils issue.

Hanno

On Fri, Jul 2, 2010 at 1:56 PM, Baiju M mba...@zeomega.com wrote:
 I was working on running ZEO as a windows service using 
 plone.recipe.zeoserver:
 http://svn.plone.org/svn/collective/buildout/plone.recipe.zeoserver/branches/baijum-windows-service/
 (This branch need some review)

 For this functionality (running ZEO as a windows service), that recipe need to
 depend on Zope2 distribution as it require nt_svcutils package.
 I propose to create a separate distribution which just contains
 nt_svcutils package.
___
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] Help!

2010-06-30 Thread Hanno Schlichting

On Wed, Jun 30, 2010 at 9:44 AM, Charlie Clark
charlie.cl...@clark-consulting.eu wrote:
 Well, that should be all I need to say - the help system is missing from
 Zope 2 trunk. I don't know exactly when it disappeared but I use it
 occasionally as a quick way to check on stuff and Hanno didn't mention it
 was due to be called in Zope 2.13

Ah, sorry. That's a side-effect of disabling the persistent product
installation by default. If you add enable-product-installation on
to your zope.conf, the help system should come back. I'll add that
information to the change log.

 Is it coming back?

I consider the help system definitely deprecated and it will go away
for good at some point. It's not been updated in ages. If there's any
useful information in there at all, we should move it to
http://docs.zope.org/zope2/.

Hanno
___
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 )

[Zope-dev] Zope Toolkit - 1.0a1 release

2010-06-30 Thread Hanno Schlichting

Hi.

On behalf of the Zope Toolkit release team and the Zope community, I'm
happy to announce the first 1.0 alpha release of the Zope Toolkit.

You can read more about the release at
http://docs.zope.org/zopetoolkit/releases/overview-1.0a1.html. The
first ZTK release supports all of Python 2.4, 2.5 and 2.6.

To use the ZTK release, you can use:

[buildout]
extends =
http://download.zope.org/zopetoolkit/index/1.0a1/ztk-versions.cfg
http://download.zope.org/zopetoolkit/index/1.0a1/zopeapp-versions.cfg

This first release focuses on getting something out and defining the
actual technical outcome of a release. Currently the release outcome
is tailored to the needs of the three frameworks.

Now would be a good time for any direct users of the ZTK to speak up
and note anything that would make a ZTK release more useful to them.
In a first dev release created earlier last week we tried to create an
easy_install friendly index for the release. But there have been
questions about the exact contents of the such an index. Furthermore
it isn't clear if such an index would be useful at all to any
potential ZTK consumer. Since the three frameworks only use buildout
and have no use for any other means, we decided to drop the index from
the release procedure until it's usefulness and exact definition have
become clear.

The release team is currently discussing the further roadmap to a 1.0
final release and has some open discussion points to what remains to
be done until we can call it a final release and the process for
further releases and version upgrades. We post our meeting notes at
http://docs.zope.org/zopetoolkit/releaseteam/index.html. Feel free to
start discussing with us on this mailing list.

All the best,
Hanno
___
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] Zope summit topics

2010-06-29 Thread Hanno Schlichting

On Mon, Jun 28, 2010 at 6:45 PM, Christian Theune c...@gocept.com wrote:
 So I'd like to open up the floor to everyone who ponders participating
 and express their wishes/hopes/expectations for the summit. Don't start
 your engines trying to solve any specific issue right now. Try to
 abstain from bikeshedding. Think of this as the preliminary
 brainstorming to figure out what we want to talk about at the summit.

Since nobody else wrote anything, I'll get started - feel free to skip
this, as it's gotten long :)

- Agree on a process for larger feature changes in Zope. Things like
zope.publisher vs. WSGI, changes to zope.interface semantics, security
without proxies, the NoZCML movement, ... - we need to have a way to
talk about these in a structured way, document things, create
opportunities for feedback from various stakeholders and get a
definitive answer on whether we allow it or not. There's different
options for how exactly such a process might look like, but I think we
definitely need one.

- Recognize the weekly Zope-dev IRC meetings as an official voice of
the Zope community and declare our support for the decisions we make
in these. I think effectively that is what we have today, but it is
currently not spoken out. We might want to make sure that certain
important decisions do get a mailing list discussion, so that people
who cannot attend the meeting have an opportunity to provide their
feedback. This needs to be balanced carefully, so we don't get
open-ended bikesheds on the mailing lists.

- Try to find a way how we can communicate cool new things we do in
the various projects. planet.zope.org is currently a bit empty and
didn't even mention things like Grok and BB releases. Following the
developer mailing lists of each project costs too much time, so it's
currently extremely hard to know what others are working on inside the
Zope community. I think we share too little knowledge and experience
with each other. This could lead to ideas for further improvements and
changes to Zope. What lessons have people learned in building RESTful
interfaces, Web 2.0 UI's, what strategies on decomposable UI like
zope.contentprovided / zope.viewlet have actually worked or whatever.
The Zope packages have little to offer when it comes to new Web
technologies but arguably that's one of the main things they are used
for.

I cannot think of anything else right now. There's always bikeshed
topics like Python 3, Subversion vs. DVCS but I don't think talking
about those at the current stage has much point.

Hanno
___
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 )

[Zope-dev] [zope2] Help needed with security checks and add views

2010-06-26 Thread Hanno Schlichting

Hi there,

recently MJ opened a security related bug and disclosed it to the
public at https://bugs.launchpad.net/zope2/+bug/578326.

In short Zope 2 never supported the permission attribute on ZCML
browser:view declarations. It seems some people might have specified
this attribute and assumed it would do something.

I have added a warning message to Zope 2 (trunk + 2.12 branch) which
warns about those cases. This is similar to how we handle other such
cases like the unsupported require set_schema=.. / and require
set_attributes=... / on class directives.

But it turns out that Zope 2 itself is using this in one place, that
looks like it ought to have a security declaration. The
Products.Five.adding.ContentAdding class registered as an add view
(+) has no working security declarations I can see, and only has
such a non-functioning permission=zope2.ViewManagementScreens set.
I'm not familiar enough with the add view concept to understand what
this is doing. It also looks like both CMF and Plone use similar
registrations for their add views.

Ideally I'd love to add support for the permission attribute, as
clearly people have been using it. But if there's nobody who can
figure out how to do that, I'd at least like to clarify the add view
case.

Any help appreciated,
Hanno
___
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 )

[Zope-dev] Zope 2.12.8 and 2.13.0a1 released

2010-06-25 Thread Hanno Schlichting

Hi there,

on behalf of the Zope community it is my pleasure to announce the
release of a new maintenance release of Zope 2.12.8 - most noteworthy
it should install on FreeBSD now.

I'm also happy to announce the first alpha release of the next major
version 2.13.0a1.

You can read all the news at
http://docs.zope.org/zope2/releases/2.13/WHATSNEW.html and in the
detailed change log.

We'll continue to work on more alpha releases during the summer and
wrap up a beta in September. I expect to see more work being done on
WSGI documentation and setup procedure and proper Zope Toolkit
integration amongst others.

While this release is marked as alpha, it should already be extremely
stable, so it is worth testing your applications and code against it.

Many thanks to everyone who contributed!

Hanno
___
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] check_python_version in Zope 2.12.7

2010-06-24 Thread Hanno Schlichting

Hi.

On Thu, Jun 24, 2010 at 3:43 PM, Sylvain Viollon sylv...@infrae.com wrote:
  There is a nice (and yet useless) python version check done in
  Zope2.Startup to verify that you have at least Python 2.3.4 when the
  daemon start.

  I guess it's a bit outdated in Zope2 2.12.7 (this version).

Right. I removed it from 2.12 / trunk.

Thanks for noticing it :)
Hanno
___
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] zope.sendmail and critical transaction errors.

2010-06-23 Thread Hanno Schlichting

Hi.

On Wed, Jun 23, 2010 at 1:59 PM, Laurence Rowe l...@lrowe.co.uk wrote:
 I think the Before Commit Hook option is probably best here.
 DirectMailDelivery should only be used for testing anyway, or at least
 only on very small sites in production - QueuedMailDelivery will scale
 better.

A before commit hook sounds like the right thing to do indeed.

 For Zope 2.12 / Plone 4.0 we have the additional problem that Zope
 2.12 is incompatible with zope.sendmail 3.7.x / trunk due to a
 zope.component 3.8 dependency. I think this issue is serious enough to
 warrant backporting this fix to the zope.sendmail 3.6.x branch.

Feel free to backport this to zope.sendmail 3.5.x (3.6.0 introduced
the backwards incompatible zope.component version).

I can cut a new release and include it in the next 2.12.x release.

Hanno
___
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] Problem with CMF trunk and Zope 2 trunk

2010-06-23 Thread Hanno Schlichting

Hi.

On Wed, Jun 23, 2010 at 8:52 PM, Charlie Clark
charlie.cl...@clark-consulting.eu wrote:
 I just wanted to test something with the CMF buildout and I'm getting the
 following error. As far as I can tell I have everything correctly up to
 date. What's going wrong?

You have likely some old SVN remains. If you do an svn st on the
Zope2 tree, you should see some orphaned directories - remove those.

Alternatively remove the Zope2 checkout and start fresh.

Hanno
___
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] connection commit ordering

2010-06-18 Thread Hanno Schlichting

On Fri, Jun 18, 2010 at 4:29 PM, Leonardo Rochael Almeida
leoroch...@gmail.com wrote:
 Thanks. Can I commit it to Zope 2.12 as well? It is backward
 compatible and helps us address a bug we see on production.

Go ahead. It really is trivial :)

Hanno
___
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] Zope Tests: 55 OK, 5 Failed, 4 Unknown

2010-06-17 Thread Hanno Schlichting

On Thu, Jun 17, 2010 at 2:32 PM, Christian Theune c...@gocept.com wrote:
 On 06/17/2010 01:58 PM, Zope Tests Summarizer wrote:
 Unknown
 ---

 Subject: FAILURE: Total languishing bugs: 1
 From: ct at gocept.com
 Date: Wed Jun 16 20:30:17 EDT 2010
 URL: http://mail.zope.org/pipermail/zope-tests/2010-June/015374.html

 Subject: FAILURE: Total languishing bugs: 101
 From: ct at gocept.com
 Date: Wed Jun 16 20:35:59 EDT 2010
 URL: http://mail.zope.org/pipermail/zope-tests/2010-June/015375.html

 Subject: FAILURE: Total languishing bugs: 178
 From: ct at gocept.com
 Date: Wed Jun 16 20:40:56 EDT 2010
 URL: http://mail.zope.org/pipermail/zope-tests/2010-June/015376.html

 Subject: FAILURE: Total languishing bugs: 75
 From: ct at gocept.com
 Date: Wed Jun 16 20:45:22 EDT 2010
 URL: http://mail.zope.org/pipermail/zope-tests/2010-June/015377.html

 Meh, those ended up having the wrong subject signature. I fixed them for
 tomorrow.

It's a little hard to see which projects these reports belong to. Is
this something you added to the subject?

Like FAILED: Total languishing bugs in Zope 2: number

Hanno
___
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] zope.wineggbuilder

2010-06-17 Thread Hanno Schlichting

Hi.

On Thu, Jun 17, 2010 at 2:59 PM, Adam GROSZER agros...@gmail.com wrote:
 The buildbot seems to work fine.
 I'll let it do the following packages tonight:

What exactly is do here?

It builds binary Windows eggs for those packages for various Python
versions I'd assume. What does it do with those eggs? Does it store
them at some publicly accessible URL? Or does it do some automatic
upload to PyPi?

Thanks!
Hanno
___
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] All sponsored MSDN licenses received?

2010-06-15 Thread Hanno Schlichting

On Tue, Jun 15, 2010 at 7:07 PM, Sidnei da Silva
sidnei.da.si...@canonical.com wrote:
 Has not arrived here. But then again Brazil is far away.

Not here either, Norway is far away as well, except from the north pole :)

Hanno
___
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] Zope 2.13 - next steps

2010-06-14 Thread Hanno Schlichting

Hi.

On Mon, Jun 14, 2010 at 4:16 PM, Jonas Meurer jo...@freesources.org wrote:
 first, thanks for clarifying. did i get you right, that for the future,
 monolithic source releases of zope2 are planned again once the dust has
 settled?

No. There is currently no monolithic released planned at all.

Only if someone does all the work of automating such a release, engage
with the community to discuss the approach and is willing to adjust to
community feedback, only then I as the release manager might make
those steps part of the release process. I'm not aware of anyone who
has shown even remote interest in this task.

 and second, does documentation exist which explains how to craft a
 monolithic tarball with zc.sourcerelease in order to build zope2.12
 without network access? i still didn't get the picture regarding
 buildout, and thus don't understand zc.sourcerelease either :-/

I'm not aware of any specific documentation. www.buildout.org and the
distutils-sig mailing list [1] would be the appropriate places to
look.

Hanno

[1] http://mail.python.org/mailman/listinfo/distutils-sig
___
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] Zope 2.13 - next steps

2010-06-14 Thread Hanno Schlichting

Hi there,

thanks to all of you for the feedback. Given the general agreement to
the plan, I'm going to release a first alpha on Friday June 25.

More alpha releases will follow depending on the changes that go into
the codebase. But I expect them on a roughly 3-4 weeks basis. If the
code stays as stable as it is and no new major features come in, I
expect to release a first beta in early September, in time for the
German Zope User Group conference.

The concrete plan up to the final will be decided once we get a beta
out of the door.

Thanks all,
Hanno

On Sat, Jun 12, 2010 at 8:58 PM, Hanno Schlichting ha...@hannosch.eu wrote:
 Aim for having a Zope 2.13 release in time for Plone 4.1, get a first
 alpha release out by the end of the month or early July. We can have
 more alpha releases during the summer, a beta probably around the
 zope-dev summit / German Zope User Group conference in early
 September.
___
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] Zope 2.13 - next steps

2010-06-13 Thread Hanno Schlichting

Hi Charlie,

On Sun, Jun 13, 2010 at 2:06 PM, Charlie Clark
charlie.cl...@clark-consulting.eu wrote:
 thanks for the information. I'm a little confused by the narrative - is
 Plone 4.0 being held back by a Zope 2 release?

No, Plone 4 is delayed for all the normal reasons of too many open
bugs caused by the massive amount of changes it has seen. But Plone 4
being delayed also delays the next major Plone (5) release.
Traditionally Plone has only upgraded to new major Zope versions in
its own major versions.

 As I don't use Plone I
 don't care about its release status and I don't think it should drive
 Zope's release status. Maybe that's what you were saying and I didn't
 understand it correctly.

The Zope 2 release schedule has for some time now effectively been
synced to match the Plone release schedule. We have seen what happens
with a Zope 2 release that isn't used in Plone with the Zope 2.11
release. It's not seen much of any maintenance and has only caused
extra effort, as we were forced to maintain multiple branches for a
longer time. As I said back in March, I want to avoid any Zope 2
release that isn't directly picked up by Plone. This is also the
reason why I briefly discussed the roadmap with some people in the
Plone community - to get buy-in on the idea and then made a proposal
to this list.

Hanno
___
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] Zope 2.13 - next steps

2010-06-13 Thread Hanno Schlichting

On Sat, Jun 12, 2010 at 9:29 PM, David Glick davidgl...@groundwire.org wrote:
 Has the process of reviewing RestrictedPython against a new Python
 release been documented anywhere?

Not that I know of. Stephan Richter and Sidnei da Silva were the last
to do these reviews, maybe they know.

Hanno
___
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] Zope 2.13 - next steps

2010-06-13 Thread Hanno Schlichting

On Sun, Jun 13, 2010 at 2:50 PM, Tres Seaver tsea...@palladion.com wrote:
 On the whole, I would actually favor getting a 2.13.0 out even sooner
 than Hanno suggests, to get it used (and therefore more polished)
 sooner.  With the post-eggification reduction in Zope2's scope, I think
 a six month cycle for major releases  would be a good target to aim at,
 rather than a year.

I agree that a shorter release cycle is going to be more suitable
again. I'm a bit conservative for 2.13 to make sure we really have a
ZTK release in place and Plone 4.1 is picking this up. If both of
these turn out to be true, than I can see another ZTK release used in
2.14 and Plone 4.2 picking this up again. I expect those kind of
releases to aim for six month and some of them languishing a bit to
end up with more like nine month. Still a lot shorter than the
effective one to two years we have now.

Hanno
___
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] zope.testrunner 4.0.0b2 problem

2010-06-10 Thread Hanno Schlichting

On Thu, Jun 10, 2010 at 4:39 PM, Stephan Richter
srich...@cosmos.phy.tufts.edu wrote:
 I assume the breakage occurs, since I released zc.recipe.testrunner last night
 that uses zope.testrunner instead of zope.testing.

Hhm, the new zc.recipe.testrunner introduces a non-backwards
compatible requirement on zope.testrunner 4.0.0b2.

Doing so a in minor release looks bad to me. The release should be a
clear 2.0 and since it depends on a non-final version itself, it
should probably be a beta release on its own.

I think rereleasing zc.recipe.testrunner without the zope.testrunner
dependency as a 1.3.1 would be in order. And then releasing the
current 1.3.0 code as a new 2.0b1.

Hanno
___
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] zope.testrunner 4.0.0b2 problem

2010-06-10 Thread Hanno Schlichting

On Thu, Jun 10, 2010 at 5:28 PM, Stephan Richter
srich...@cosmos.phy.tufts.edu wrote:
 We are not really changing the API in a BBB incompatible way. We simply 
 shuffled
 code around. We did that all the time and never increased the major version
 number.

The code is no longer compatible with older versions of zope.testing
and introduces a hard dependency on a new major release of another
package. That clearly constitues the need for a major version upgrade
in my book.

If the code would optionally use zope.testrunner and fall back on the
existing zope.testing it would be fine to do this change in a minor
release like 1.3. As you can tell from the reported breakage the new
release is not backwards compatible.

 I think rereleasing zc.recipe.testrunner without the zope.testrunner
 dependency as a 1.3.1 would be in order. And then releasing the
 current 1.3.0 code as a new 2.0b1.

 I think that would be a bit harsh and not fix the Zope 2 problem, if no
 versions are pinned, since even 2.0b1 will be picked up as latest.

Some people use the prefer-final option of buildout to guard against
unstable software. But more importantly humans checking for new
versions or the z3c.checkversions has a chance of identifying this new
release as yet unstable.

Hanno
___
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] SVN: Zope/branches/2.12/ Bunch of version updates and note incompatibilities in minor versions

2010-06-07 Thread Hanno Schlichting

On Mon, Jun 7, 2010 at 8:53 PM, Tres Seaver tsea...@palladion.com wrote:
 Hanno Schlichting wrote:

 If the comments are valid, these all smell like process fouls:  a new
 third-dot release should not introduce backward incompatibilities.

Sure. These are all from late 2009 cut in the middle of the main
refactoring wave. We didn't have much of any process at that time and
everyone just cut releases. Zope 2.12 uses this awkward snapshot out
of the middle of the refactoring - it's one of the reasons I would
like to make 2.12 a rather short lived release and wrap up 2.13 soon
(more on that in a separate mail). The particular version set used by
Zope 2.12 isn't very maintainable.

 I see the following issues in the zope.app packages:
 In the non-zope.app packages:

[...]

Good analysis, a lot comes down to a new zope.publisher version and
the zope.login addition. Unfortunately Zope 2.12 uses zope.publisher
3.8.0 and 3.9.0 has a major refactoring of zope.app.publisher and the
creation of zope.browserpage, zope.browsermenu and
zope.browserresource amongst others. This change required some
non-trivial changes to Zope2 (Five) code to work, so we cannot upgrade
anything here.

I knew about this situation all along, just made it more explicit now.
Mainly to make it easier to check the outcome of the checkversions
script and filter out the false positives. The list is so long, that
I didn't feel like retrospectively forcing sanity into all these
packages. Most of them have had many new feature releases in the
meantime, so it's hard to introduce policy compliant versions into
their version history.

 - - I cannot see that zope.traversing 3.7.2 introduced any incompatible
  changes.

It adjusts test output to zope.publisher 3.9 where we use 3.8. The
tests don't run with the older 3.8 release.

Hanno
___
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] Zope 2.12 and Broken classes

2010-06-04 Thread Hanno Schlichting

On Fri, Jun 4, 2010 at 5:33 PM, Sylvain Viollon sylv...@infrae.com wrote:
  After more testing, I have more information. This bug has been
  introduced by the release 2.13.0 of ExtensionClass and Persistance
  packages. Running 2.12.0  of packages make it disappear.

  I guess I should report this on launchpad ?

Please do. I'm not sure where the bug actually is, we probably need to
change the Broken implementation in OFS or unify it with the one from
ZODB to fix this. Not sure how ZODB deals with storing references to
persistent objects (the optimized kind storing the class name in it)
and how that relates to broken objects.

This isn't really a new problem, it probably happened to any normal
non-extension class already in the past. Those are just less frequent
in use.

Hanno
___
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] Zope Tests: 15 OK, 4 Failed

2010-05-24 Thread Hanno Schlichting

On Mon, May 24, 2010 at 4:52 PM, Tres Seaver tsea...@palladion.com wrote:
 zope.browserpage, which I am not privileged to release.  Can one of the
 owners (nadako, J1m, srichter, gary, tlotze, hannosch, faassen, baijum,
 agroszer) either add me ('tseaver') to the list, or else make a release?

You should have access now. I also gave you access to zope.browsermenu
and zope.browserresource - the close relatives of zope.browserpage.

Hanno
___
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 )

[Zope-dev] ZTK release team - kickoff meeting - delayed summary

2010-05-18 Thread Hanno Schlichting

Hi there,

I've been slacking and forgot to post the summary of the first ZTK
release team meeting.

Here it is. I'll put it into SVN into the ztk-docs area as well.

Cheers,
Hanno

ZTK meeting - 2010-05-06


Attendance
--

ccomb, j-w, hannosch

Agenda
--

- No fixed agenda, this is a kick-off meeting.

Discussion
--

Communication

- We'll use the zope-dev mailing list for our discussions and no separate list

Our role

- We see ourselves as representatives of communities that make use of the ZTK
- We should ensure stable releases of the ZTK, which are useful to our projects
  not more and not less

Release outcome

- Should produce a http://download.zope.org/ztk/release/1.1 with a ztk.cfg in
  it and a the zopeapp.cfg (for as long as it exists) in it.
- Nice to have: an index (for easy_install people)
- Should have some documentation site stating changes
  (http://docs.zope.org/zopetoolkit/releases/overview-trunk.html)

Release policies

- At first manual releases (x.y.Z), automate the process to generate the bugfix
  releases later. We need to make sure to release only versions sets for which
  all tests passed.

- ztk x.y.z. releases, stable package list per release

- a ztk minor release per month would be ok

- a ztk major release when one of the consumers projects needs it.

- backward compatibility breaking only happens in X.y.z that means, if we have
  a zope.component 4.0.0, it will be part of ZTK 2.0 or 3.0

- generally upstream releases happen in a 6-12 month interval, so the same
  timeline makes sense for ZTK releases

Tasks
-

- We want 64bit Linux and Windows tests for the ZTK. j-w is bugging janjaap to
  create those. Maybe contact ccomb for adding slaves to afpy [j-w]

- Make sure we have a buildbot testing the ZTK releases (and not SVN) [ccomb]

Open points
---

- Look at Tres's list of packages in all three frameworks, decide on a way to
  drop things from the initial ZTK set and on a process for the future.

- Look at and update http://docs.zope.org/zopetoolkit/about/coreextra.html for
  adding/removing policies, probably have a deprecated.cfg file

- Decide on process for new feature versions and the process for going from
  1.1.0 alpha to a final

Next meeting


2010-05-18, 14:00 to 15:00 UTC before the zope-dev meeting, in #zope
___
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] Zope 2.12.6 this Monday

2010-05-17 Thread Hanno Schlichting

On Fri, May 14, 2010 at 10:23 AM, Hanno Schlichting ha...@hannosch.eu wrote:
 I'm planning to make a new bugfix release of Zope2 on Monday
 (2010-05-17) in time for the next Plone 4.0 beta release.

The 2.12.6 release is made, Windows binary eggs will follow later today.

Hanno
___
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] Zope2 - Breaking out more packages

2010-05-17 Thread Hanno Schlichting

On Mon, May 17, 2010 at 9:20 PM, Tres Seaver tsea...@palladion.com wrote:
 Hanno Schlichting wrote:
 - Move Shared.TaintedString to an external distribution.

 +1 for putting it into AccessControl.

Yeah, makes most sense I guess. It's just one file after all.

 - Move the ZMI parts of AccessControl into the App package. App
 already holds a good deal of general ZMI pages, so this seems a good
 fit. It basically makes App the zope.app of Zope2.

 +1 for the generic security tab stuff.  I'm not so sure about anything
 related to the userfolder, though, unless moving it is a huge win.  Hmm,
 you must have wrestled with that already, no?

The ZMI functionality needs DTMLFile, App.MessageDialog and a couple
more of things from App. We could introduce another package that holds
the ZMI screens, but that feels like over-abstraction to me. It's not
like anyone really would want to use AccessControl's ZMI screens
without having App around. I admit App would get to be a bit of a
dumping ground :)

 Before trying the latter, we need to triple check that the zope.index
 stuff hasn't bitrotted, or lost / missed any features from the Z2 version.

Sure. Shane and Chris have done some of that work for the C code
already, that's why I'm considering it at all.

 BTW, making *all* the products seaparate eggs seems like a good plan to me.

Generally yes. But they need to be actually independent first. There's
a good deal of imports in all directions or usage of Testing and such.
We can clean them up one after another and break them out after they
are clean.

Thanks for the feedback,
Hanno
___
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 )

[Zope-dev] Zope2 - Breaking out more packages

2010-05-16 Thread Hanno Schlichting

Hi.

I've started working some more on my pet project of refactoring Zope2
- specifically to move all C code to external distributions. My
working branch is at
svn+ssh://svn.zope.org/repos/main/Zope/branches/hannosch-dtml-vs-accesscontrol
which also has a TODO.txt with some notes. On the branch
DocumenTemplate imports from AccessControl but not the other way
around.

So in general I think this can be made to work. My current plan involves:

- Move Shared.TaintedString to an external distribution. It's used
both by DocumentTemplate and ZPublisher. Moving it into
DocumentTemplate and have ZPublisher depend on it, sounds like a poor
choice to me - a publisher shouldn't depend on a markup language. We
could also move it into AccessControl as it's sort of a security
feature.

- Move zExceptions to an external distribution. It's used from all
over, but has no external dependencies on its own. Instead of just
moving it out, I'd look at merging some of it into zope.exceptions.
The two share a good deal of code like the exception formatter and
common exception classes.

- Move the ZMI parts of AccessControl into the App package. App
already holds a good deal of general ZMI pages, so this seems a good
fit. It basically makes App the zope.app of Zope2.

There's a bunch of more minor stuff to work out and lots of awful test
dependencies, but in general it looks good.

If you have any feedback on the above, please shout - otherwise I'll
continue as planned and time permits. Once this is finished and
merged, ZCTextIndex holds the last bits of C code inside the Zope2
distribution - there's multiple ways to deal with it: break it and
HelpSys out or reuse the C code from zope.index. We can look at that
later.

Hanno
___
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 )

[Zope-dev] Zope 2.12.6 this Monday

2010-05-14 Thread Hanno Schlichting

Hi.

I'm planning to make a new bugfix release of Zope2 on Monday
(2010-05-17) in time for the next Plone 4.0 beta release.

There's a ton of changes already. If you have more things to wrap up,
please do so :)

Hanno
___
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] SVN: zopetoolkit/trunk/ztk.cfg Update to ZODB3 = 3.9.5 and include a pin for the new package providing the mkzeoinst script

2010-05-06 Thread Hanno Schlichting

On Thu, May 6, 2010 at 2:37 PM, Martijn Faassen faas...@startifact.com wrote:
 Tres Seaver wrote:
 ZODB is only included in the ZTK as a dependency, because some packages
 import it:  nothing else in the ZTK configures server instances.

 Nothing in zopeapp uses it either?

Not that I know off.

 If nothing depends on it, it's less important to track it carefully. Of
 course if app servers start using it they should be tracking it, and if
 common infrastructure emerges that builds on it, it might make sense to
 push it into something more common.

I don't particular care if it is in there. Zope2 has a script which is
dependent on it and the buildout recipes for setting up ZEO servers
tend to depend on it. So I assumed this is a case of something many of
the ZTK consumers use.

Hanno
___
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] SVN: Zope/trunk/versions.cfg Group versions by the 'sets' to which they correspond.

2010-05-04 Thread Hanno Schlichting

On Tue, May 4, 2010 at 4:25 AM, Tres Seaver tsea...@palladion.com wrote:
 Should the triumvirs so decide, attached is the patch for zopetoolkit
 which adopts the versions from Zope2.  The normal buildout (using eggs
 rather than checkouts) passes all test-ztk and test-zopeapp tests with
 this patch applied.

As far as I understand the current process, you can just go ahead and
update the ztk.cfg file, as long as all tests pass.

Please do that.

I will change the Zope 2 versions file once we started clarifying a
few things on the release team.

Hanno
___
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] adding the weekly irc meetings record to the ZTK docs?

2010-05-04 Thread Hanno Schlichting

On Tue, May 4, 2010 at 10:54 PM, Charlie Clark
charlie.cl...@clark-consulting.eu wrote:
 I think some kind of paper trail is definitely a good idea. Not sure if
 docs is the right place but Christian is planning to put the reports into
 the svn repository. And both location and form are less important than
 having an archive*. We'll have something sorted by next week. Probably.

Cool. Feel free to put them into a new folder inside
svn+ssh://svn.zope.org/repos/main/zopetoolkit/doc/source if that is
easiest.

But do whatever works best for you and Christian.

Hanno
___
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] summary of suggestions

2010-05-03 Thread Hanno Schlichting

Hi Martijn,

On Mon, May 3, 2010 at 2:03 PM, Martijn Faassen faas...@startifact.com wrote:
 Because my suggestions (besides the fork issue) as a ZTK
 user/contributor were scattered through the thread, here's a handy summary:

Thank you very much for your suggestions. I'm sure the release team
will pick these up, once we get to start actual discussions.

We have only started talking to each other last week and are slowly
bootstrapping. Please don't expect us to solve everything in a matter
of days.

Hanno
___
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] Hanno, please update the ZTK

2010-05-03 Thread Hanno Schlichting

On Mon, May 3, 2010 at 9:56 PM, Martijn Faassen faas...@startifact.com wrote:
 Last december Hanno made progress on the ZTK's dependency structure,
 removing a lot of dependencies on packages. In his enthusiasm, he
 unilaterally just removed all those suddenly-unneeded (by him!) packages
 from the ZTK, without discussion.

My actions last December had an unfortunate effect. I assumed a common
understanding of what the ZTK should be and tried to work towards
that, but it turned out that understanding wasn't shared after all. I
should have known better and discussed things before taking any
actions. For not discussing things properly I apologize. In didn't see
any chance of making any progress during the heated debate following
those events, so I decided to let things cool off and let everyone
work on their own for a while.

 No, I cannot present it less acrimoniously. The lack of commitment and
 trust displayed back then still hurts me too much for that.

Martijn and me tried to discuss this off-list. I think at this stage
there's no way to solve our disagreement. I'd rather not continue any
of this in public, as I don't see how this would have any constructive
effect.

The Zope community asked Christophe, Jan-Wijbrand and me to act as a
release team for the ZTK and we started working on this task. I intend
to continue to work in this group. If the Zope community feels I'm not
qualified for the job or the other two team members don't want to work
with me, I'll happily step down.

Hanno
___
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] Zope Tests: 10 OK, 4 Failed, 2 Unknown

2010-05-03 Thread Hanno Schlichting

On Tue, May 4, 2010 at 12:41 AM, Christophe Combelles cc...@free.fr wrote:
 Hanno Schlichting a écrit :
 Hhm. I'm inclined to drop 2.4 support here. Using a zope.testing that
 tries to be compatible all the way from 2.4 to 3.1 is quite a bit of a
 stretch.

 Unless I missed something, the ZTK was globally compatible with Python2.4
 recently, wasn't it?  Do we want the latest changes and Lennart's work to be
 part of the ZTK 1.0?

 If not, the svn branches used for the ZTK 1.0dev should be updated to point 
 to a
 maintenance branch.
 (I suppose it's our job)

Dropping Python 2.4 supports makes most sense to me at this stage.
Zope2/Plone only support Python 2.6 for any modern version.

I don't know what BlueBream and Grok want to support, but would guess
they aim for Python 2.5 + 2.6 support. 2.4 is really old by now.

Hanno
___
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] Hanno, please update the ZTK

2010-05-02 Thread Hanno Schlichting

Good evening :)

If you have a specific issue with me, you might contact me in private.
But with your follow-ups this turned into a more general issue.

On Sun, May 2, 2010 at 10:59 PM, Martijn Faassen faas...@startifact.com wrote:
 Martijn Faassen wrote:
 Of course what applies to Hanno should apply to others making releases
 of packages maintained by the Zope Toolkit project as well. I think the
 ZTK leadership should figure out some kind of guidelines for this that
 people can follow. Maybe someone can write a tool too to check up how
 far a toolkit is out of sync with the latest releases. Just some ideas.

 Don't think you're off the hook with me though, Hanno. :)

 Hanno is special as he's maintaining a fork of the ZTK and was
 maintaining the ZTK already in the past before he forked it. If I were
 the ZTK leadership such a thing would probably frustrate me a lot, so
 it's a good thing I'm not. Instead I can just express my displeasure out
 loud.

The ZTK is on my list of things to look into and I'm committed to
the idea. Jan-Wijbrand, Christophe and me started an off-list
discussion on the specifics of the ZTK release team.

I expect us to define the process around package releases and updating
the ZTK. It's not entirely clear to me who should and who is allowed
to update the ZTK definition. We'll figure things out and once we have
I'll stick to the rules.

Hanno
___
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] Moving zpasswd from zope.app.server to zope.password?

2010-05-01 Thread Hanno Schlichting

On Sat, May 1, 2010 at 4:15 PM, Uli Fouquet u...@gnufix.de wrote:
 It would mean for zope.password to depend additionally on
 zope.configuration and zope.component.

 Are there any objections to this step?

No objection here. zope.password isn't used in Zope2 :)

Hanno
___
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] Version bump question? Bikeshed here.

2010-04-30 Thread Hanno Schlichting

On Fri, Apr 30, 2010 at 9:54 PM, Lennart Regebro rege...@gmail.com wrote:
 I updated zc.receipe.testrunner to use zope.testrunner instead of
 zope.testing.testrunner. Initial testing has shown that this should be
 compatible, and although the code changes are minor, it's potentially
 unexpected. So should we release it as 2.0.0 or 1.3.0?

If it is intended to be backwards compatible and seems to be so, I'd
say go with 1.3. It sounds like a new package dependency, like we have
had many others in minor releases.

Hanno
___
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] Version bump question? Bikeshed here.

2010-04-30 Thread Hanno Schlichting

On Fri, Apr 30, 2010 at 10:03 PM, Fred Drake fdr...@gmail.com wrote:
 On Fri, Apr 30, 2010 at 3:57 PM, Hanno Schlichting ha...@hannosch.eu wrote:
 If it is intended to be backwards compatible and seems to be so, I'd
 say go with 1.3. It sounds like a new package dependency, like we have
 had many others in minor releases.

 Since when were new dependencies not considered features?

They are of course. In my vocabulary a version consists of major.
minor . micro (or patchlevel). Going from 1.2 to 2.0 is a major new
feature release. Going from 1.2 to 1.3 is a minor new feature release.
Package dependencies are a new feature and need a new feature release.
They cannot be done in third-dot or bug fix releases. But Lennart
didn't ask for that.

Hanno
___
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] I would like to have some releases

2010-04-29 Thread Hanno Schlichting

On Thu, Apr 29, 2010 at 10:00 PM, Lennart Regebro rege...@gmail.com wrote:
 OK, I started carefully with zope.interface 3.6.0. :)

 Source only so far. I have a Windows machine, and I could make Windows
 releases as well, I guess. Is there any docs on what's needed for
 that? I haven't built python extensions on Windows since 2004. :)

I'll do the Python 2.6 (32-bit + 64-bit) releases tomorrow.

Hanno
___
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] ZTK community packages

2010-04-25 Thread Hanno Schlichting

Hi.

On Sun, Apr 25, 2010 at 11:14 AM, Christophe Combelles cc...@free.fr wrote:
 I believe packages such as z3c.form, z3c.macro, z3c.template, z3c.pagelet (and
 many others) are among the most important packages. I wonder why they are not
 included in the ZTK? I always end up using them, I believe they should even be
 part of the core ZTK.

We have written down some definition of what constitues a core library
at http://docs.zope.org/zopetoolkit/about/coreextra.html. That
document is outdated to some degree, and likely the steering group
should now be replaced by the release team.

Nevertheless the criteria given in that document are still sensible in
my opinion. z3c.form might at some point become part of the ZTK. But
right now none of the major projects includes it in its core. The
other z3c libraries you mention, I have never heard of or wouldn't
know what they did. They sound to me related to a specific way of
constructing user interface related code. I think there's many
different approaches to that and only very few can claim to be used by
multiple of the major projects.

 If they are not part of the core, I would like them to be part of a
 *community.cfg* list. There already is a community.cfg list in BlueBream, but 
 I
 don't like having many foobartoolkit in the wild, with many package lists to
 maintain. It's already difficult enough to maintain just 1 list for the
 zopetoolkit. Let's focus on it.

What you are describing is similar to the idea of the extra concept
we have defined for the ZTK. It has at this stage no manifestation in
any code, version list or process around it.

At this stage I would prefer to focus on the ZTK as a
least-common-denominator of the major projects. And only if we are
actually able to agree on such a set, should we try to extend it. This
is going to be hard enough and extending the set of packages won't
make it any easier.

That doesn't mean you shouldn't go forward with your idea. I just like
to have it separate from the ZTK.

Hanno
___
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] bug tracker gardening for bugday

2010-04-22 Thread Hanno Schlichting

On Thu, Apr 22, 2010 at 2:37 PM, Tres Seaver tsea...@palladion.com wrote:
 Incomplete is the auto-expiring state:  if nobody responds in 30 days,
 it automatically disappears.

 I agree that we should at least attempt to reproduce even really old
 bugs before assigning them 'wontfix' status (if we can't) or
 'incomplete' (if we need more information).

Speaking from my experience with cleaning up the Zope2 tracker: Zope
is remarkably stable and there's some really old but still completely
accurate tickets in the tracker. Just because anything is old, doesn't
mean it's not valid anymore. I found some really good patches from 8
years back ;)

I think you should use the incomplete status exactly when something
is that: there's not enough information in the ticket to reproduce it.

There's another category of tickets which describe problems with no
longer maintained or outdated versions. Something along the lines of
Zope X3.0b1 is missing a Windows binary installer. Those I'd close
with an immediate won't fix.

Hanno
___
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 )

[Zope-dev] Zope 2.12.5 - this weekend

2010-04-19 Thread Hanno Schlichting

Hi.

I'm planning to do a new Zope 2.12.5 release this weekend.

Yvo is going to try to look some more into the unauthorized /
exception view interaction and I hope to get a ZODB 3.9.5 release from
Jim.

If you have anything else you want to get in, commit away or let me know.

Cheers,
Hanno

P.S. I'm flexible on the weekend, I can postpone the release until Monday.
___
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] Repository for the zope mail summarizer

2010-04-16 Thread Hanno Schlichting

On Fri, Apr 16, 2010 at 9:55 PM, Patrick Gerken do3cc...@googlemail.com wrote:
 And who runs that script atm?

Talk to testmaster Stefan Holek irc: lurker, stefan (at) epy dot co dot at

He wrote the script and runs it.

Hanno
___
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 )

[Zope-dev] Comply with repository policy ?

2010-04-08 Thread Hanno Schlichting

Hi.

I've seen lots of checkins recently stating Comply with repository policy.

I haven't seen any announcement of a new official repository policy.
Have I missed it?

I'd be especially interested who exactly is responsible for changing
code so that it complies with the new policy. How much of the initial
work is automated and taken care of by some small group of people and
what is left to the individual package maintainers? How are packages
without maintainers handled? What about trunk vs. old branches?

Thanks,
Hanno
___
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] Wanted: representatives from Zope 2, grok, and BlueBream to engineer ZTK 1.0 release

2010-04-03 Thread Hanno Schlichting

Hi.

On Sat, Apr 3, 2010 at 8:44 PM, Christophe Combelles cc...@free.fr wrote:
 I will be the representative for BlueBream, since Baiju is already doing an
 enormous amount of work and he needs help.

Awesome news!

 Let's wait a little bit more for a caveman to stand up for Grok, and we can
 start discussing about the release of the ZTK 1.0.
 This should probably happen soon, because Grok 1.1 and BB 1.0 are currently
 using the same versions and are about to be released.

Jan-Wijbrand, do you feel like helping out or could you find someone
to do so for Grok?

I think the three of us might be able to actually get something done ;-)

Cheers,
Hanno
___
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 )

[Zope-dev] short svn.zope.org downtime

2010-04-03 Thread Hanno Schlichting

Hi,

looks like SVN and viewcvs weren't responding for a couple minutes. I
could log into the machine via SSH and Apache serving docs.zope.org
still worked.

I only noticed:

27059 simon 20   0 98664 6388 4360 R  100  0.2  43327:19 darcs

Why do we have darcs running on that machine and more importantly why
does it run with 100% cpu load for minutes (or hours?).

Hanno
___
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] Zope 2.13 roadmap

2010-04-01 Thread Hanno Schlichting

On Thu, Apr 1, 2010 at 11:52 AM, Marius Gedminas mar...@gedmin.as wrote:
 I don't think I'll be able to work on it, but I think it's worth
 consideration: Unicode issues with Zope 2.12.  I've seen these on at
 least three different Zope 2 sites built with a combination of TTW page
 templates, Python scripts and (sometimes) DTML documents: things like
 title attributes store their data as UTF-8 strings, while page templates
 insist on Unicode objects, resulting in errors all over the place.

 Those sites worked with Zope 2.9 and broke down after an upgrade to
 2.12.  That's a not very nice thing to do to your users...

They broke down after the move to Zope 2.10. We switched Zope 2 to
using the zope.tal / zope.tales packages in favor of Zope 2's own
implementation. As a result TAL uses Unicode internally ever since.
There's the whole unicoderesolver story, which allows you to implement
an application specific fallback story. We decided back then, that
dealing with this problem would be left to each application, as Zope 2
in general has too little knowledge about your data - and nobody
volunteered to do any work on it ;)

Plone has implemented a specific fallback story which automatically
converts all utf-8 encoded strings to Unicode. In the Plone 3.x series
it accepted all otherwise encoded strings and converted them via
unicode(text, 'utf-8', 'ignore'), logging such occurrences. In Plone 4
it throws an exception on any non-utf-8 non unicode data. In Plone 5
we'll probably log warnings for utf-8 encoded strings and push the
responsibility to convert to Unicode into the application code.

If you have a rather large application with third-party plugins and
have to deal with the encoded string to Unicode conversion, I think
such a long term upgrade story with policy changes happening around
major releases is the only way to go. If you have a pure-inhouse
application you can do a data and code conversion as single project
and get over with.

That being said, I'd like to see someone tackle the id / url
segments as Unicode problem. They are currently restricted to ASCII,
which means we don't have a problem with arbitrary encoded string
data. But there's probably enough places that rely on them being ASCII
in some way.

Hanno
___
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] Zope 2.13 roadmap

2010-04-01 Thread Hanno Schlichting

On Thu, Apr 1, 2010 at 9:33 AM, Martin Aspeli optilude+li...@gmail.com wrote:
 Hanno Schlichting wrote:
 - Five deprecation

 +1 - sounds hairy, though.

 Getting rid of the Zope 2 specific ViewPageTemplateFile and BrowserView
 (already done, I guess) would be a good starting point.

With Zope 2.12 BrowserView is basically done. You can now import the
BrowserView class from zope.publisher.browser instead of the one from
Five. But ZCML directives still use the Five class, to ensure code
using fancy Acquisition magic continues to work.

ViewPageTemplateFile is a very different beast. The page template
machinery of Zope2 and zope.tal are different enough, that there's no
easy upgrade path. The expression context (here, modules, ...),
path traversal, restricted templates, ... there's enough subtle
differences all over. I think it is more likely that applications like
Plone will switch to Chameleon and adjust import paths to a chameleon
specific package.

 - Make Zope 2 more modular

 I think it may help to make a list of the things we'd like to be able to
 get rid of, and then isolate those.

I'd kind of like to be able to explicitly decide what to get and make
this an opt-in. I could see someone using AccessControl, OFS, Zope2
(for the application bootstrapping) and ZPublisher without much of
anything else, except their dependencies like Acquisition or tiny
packages like Globals, Lifetime and Signals. Such a minimal set
wouldn't be called Zope 2 anymore, as Zope 2 is the application server
with all the TTW capabilities, Python scripts, ZRDB and friends. But
only actually looking at the code and refactoring it will tell to what
extend this is possible. My first step is to attack Five, as its been
pulled in by everyone and was dependent on everything in return. Once
we untied that knot, we can see what is going to be possible.

 One thing that would be interesting from a Plone perspective is whether
 people could optionally use Zope 2.13 with Plone 4.x. That may be quite
 attractive if Zope 2.13 has WSGI.

This is speculation at the moment. If WSGI ends up in 2.13 without a
backport to 2.12, we can look at it. One option is for someone to
backport the changes into a standalone package, like repoze.zope2 and
allow people to pull it in as an experimental backport. If only some
people will want to use it, this is a very viable option and much like
the status quo of repoze.zope2 today.

Hanno
___
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] Zope 2.13 roadmap

2010-04-01 Thread Hanno Schlichting

On Thu, Apr 1, 2010 at 3:50 PM, Charlie Clark
charlie.cl...@clark-consulting.eu wrote:
 Am 01.04.2010, 15:30 Uhr, schrieb Hanno Schlichting ha...@hannosch.eu:

 With Zope 2.12 BrowserView is basically done. You can now import the
 BrowserView class from zope.publisher.browser instead of the one from
 Five. But ZCML directives still use the Five class, to ensure code
 using fancy Acquisition magic continues to work.

 So, if I don't need any of the acquisition I just go with
 zope.publisher.browser? How about the configuration? Just use the adapter
 directive?

The class you get from any ZCML directive is going to be the one from
Five using the Five.bbb.AcquisitionBBB mix-in. It emulates enough of
Acquisition without actually using it. You cannot opt-out of that bit
of bbb support for the ZCML directives. At some stage it might make
sense to allow this. But I'd only consider this if you could opt-out
of all Five specific features for all browser directives at once. For
now the little bit of extra mix-in doesn't hurt much and you'll hardly
ever notice it. The change is described at
http://docs.zope.org/zope2/releases/2.12/WHATSNEW.html#acquisition-redux

 ViewPageTemplateFile is a very different beast. The page template
 machinery of Zope2 and zope.tal are different enough, that there's no
 easy upgrade path. The expression context (here, modules, ...),
 path traversal, restricted templates, ... there's enough subtle
 differences all over. I think it is more likely that applications like
 Plone will switch to Chameleon and adjust import paths to a chameleon
 specific package.

 I think this is you speaking with different hats on. My view on Zope2's
 roadmap would be to continue to move towards the zope.tales
 implementation, deprecating as necessary. I don't see any difference
 between Zope2 and Plone as to whether the actual implementation is
 zope.tales or Chameleon. Replacing here with context in templates is
 easy enough. That said, I did get pretty scared when I looked at the
 implementation!

here vs. context is the most trivial of the differences and one
could make that change. Since the two are simple aliases, it's easy
and only tedious to do the switch. On its own it doesn't have much
benefit though. But it's all the other things which are hard. For
example there's no restricted page template story outside Zope 2.
There's nothing to move to, except you decide to drop the support of
this particular feature. But that's not something that is sensible to
do for Zope 2. An application like Plone can make the decision to stop
supporting TTW development in the long run. For Zope 2 that doesn't
make any sense, as TTW development is what makes it Zope 2.

But my view on what makes sense for Zope 2 might always be biased as I noted :)

Hanno
___
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 )

[Zope-dev] Zope2 - Release Manager

Hi there,

I was in too much of a good mood while having some vacation. So I
thought I need more work to do :)

I'd like to step up as the release manager for Zope2 for the 2.12 and
2.13 (trunk) releases.

I've gotten an overwhelmingly positive response to this proposal from
the Zope Foundation board. The ZF board was discussing a general
release manager process. This discussion will become obsolete, should
nobody in the Zope2 developer community have significant objections
against my proposal. Unless there is a real need for it, the Zope
Foundation will continue to stay out of direct decisions on the
development process.

QA

Who am I?

I'm going to assume everyone on this list knows me by now. Should you
have any questions, please feel free to ask.


You know this is Zope2 and not Plone?

Indeed. I hope I have shown in the past, that I'm able to distinguish
between the two. And what is appropriate and sensible for Zope2 with
its many different consumers. Plone might be a major consumer of
Zope2, but it's not the only one. Since I only use Zope2 as a base for
Plone, I do have a certain bias.


Wait, you say 2.12 and 2.13, what about 2.11 and before?

Sorry, I have to pick my playground. The non-eggified Zope2 releases
are very different in their release procedures. I find that process to
be tedious and no fun at all, so I'm not going to spent my free time
on it. Should nobody else step up to act as a release manager for
those releases, they will be unsupported.


Are you a new Andreas?

Nobody can replace Andreas and the tremendous amount of time and
dedication he has shown. Personally I do not care about evangelizing
Zope2 or helping out end-users on mailing lists amongst others. So no,
I'm not going to do all the work Andreas did. I'm only here to help
out as a release manager, whose job it is to get stable releases out.
I do read the developers mailing lists and watch the bug trackers, I
don't read any users mailing list or see it as my job to fix or
respond to every bug anyone reports.


What about that Plone release manager position?

I am currently the release manager for Plone 5. We have clarified the
overall roadmap for Plone 5, and we aren't going to work on any of the
formal release parts for the next 12 months or longer. The current
focus is on the Plone 4.x release series, where Eric Steele serves as
the release manager. So while I'm going to keep my post as a Plone
release manager, it currently doesn't involve any time commitments.


What about Zope 2.14 or beyond?

Nobody knows yet. We will see once we get there. My formal commitment
is for 2.12 and 2.13.


Are you insane?

Maybe a little bit. But seriously if anyone knows anyone else who
would be interested in this job, speak up. I haven't seen anyone else
since Andreas stepped down. And I happen to work for a company which
is 100% dependent on Zope / Plone for their income stream. While I'm
doing this in my spare time, I do have a very real need for Zope2
releases.


I'm planning to make a 2.12.4 release on Easter Monday (April 5). You
have until then to ask questions and complain :)

Hanno
___
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] Wanted: representatives from Zope 2, grok, and BlueBream to engineer ZTK 1.0 release

On Mon, Mar 29, 2010 at 4:08 PM, Christian Theune c...@gocept.com wrote:
 * Zope 2: In theory I'd suggest the Zope 2 release manager. In practice
   I'd like to nominate Hanno because he's been very active with Zope 2
   recently and already has done work on the ZTK before. (Hanno: sorry.
   *duck*)

Since I just stepped up as the Zope2 release manager, I'd be happy to
be involved and help out with this. Pending any objections against me
as a release manager that is :)

I'm probably not going to be able to drive the ZTK process. I think
the first release should be driven by the needs of BlueBream and Grok.
I'll be happy to voice my opinion and my concerns from a Zope2
(Plone?) standpoint. And make sure that the overall release process of
the ZTK ensures the same sort of stability and release timespans, that
will allow Zope2 to use it.

Hanno
___
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] Zope2 - Release Manager

On Wed, Mar 31, 2010 at 2:48 PM, Charlie Clark
charlie.cl...@clark-consulting.eu wrote:
 great that you'll be Release Manager. I only have questions on the
 forthcoming release - a summary of the proposed changes / bugfixes for us
 to moan about! ;-)

We release whatever is on the stable branch, as seen at
http://svn.zope.org/Zope/branches/2.12/doc/CHANGES.rst?view=markup

You moan about things when they get checked in. Otherwise silence is
consent. Unless I'll use my dictator power for a release of course ;-)

Hanno
___
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] Zope 2.13 roadmap

On Thu, Apr 1, 2010 at 3:49 AM, Martin Aspeli optilude+li...@gmail.com wrote:
 What's the next step? I'd love to see some roadmapping ala that you did
 for Plone 5, in particular to discuss our WSGI story (which I'm
 interested in helping out with if others can help too).

There's no big roadmap yet, but I have some ideas :)

In general I'd like to avoid a major Zope release, that isn't used by
an official Plone release. Zope 2.11 hasn't seen much attention and we
had to maintain 2.10 anyways. But if there's a decent and stable
feature set that other consumers like to get there hands on, we can
get them a release. I just won't be pushing into that direction.

Here's what I can see today:

There's a bunch of stuff already done as noted in
http://svn.zope.org/Zope/trunk/doc/CHANGES.rst?view=markup.

- zope.app removal

This project is all finished. Zope2 doesn't contain any trace of
zope.app or the name Zope 3 in itself nor its dependencies anymore.

- Moving formlib out of the core

Triggered by the above and finished as well. Zope trunk doesn't
contain any trace of formlib anymore. The relevant code is now in the
five.formlib package. This package is also included in Zope 2.12, so
you can start using the functionality and be compatible with both Zope
versions. CMF does this already.

- WSGI

I cannot tell at the moment. It's going to depend on the actual
changes required to get this to work. Since there is some broken WSGI
support inside the 2.12 codebase, we can claim a certain deal of
changes as bugfixes. But there's limits to what we can warrant as a
bugfix. If the code changes are self-contained and only touch the
broken WSGI modules, we are good. If we require changes all over the
board for whatever reasons, this will have to be a new feature and go
into Zope 2.13. Only a branch with actual code will tell :)

- ZTK

As long as there's no formal release of the ZTK or a defined and
stable process around it, Zope 2 defines its own KGS. It so happens to
use exactly the same versions as the current ZTK trunk. Once we are
making progress on the ZTK release, we'll see how Zope 2 can use such
a release. My current guess is that Zope 2.13 will use some ZTK 1.1
release.

- Five deprecation

I did a whole bunch of work on this already and keep working on it.
The end goal is to be able to deprecate the entire Products.Five and
phase it out of the core. Actually useful functionality in it, is
integrated into the proper places inside the Zope2 core packages
instead. Like security stuff in AccessControl, container events in
OFS, reading site.zcml and setting up the CA in Zope2/App and so
forth. There's a number of hard cases, where there's some semantic
differences between zope.* packages and their Five equivalent,
especially in the browser realm. This project might not be
completely finished for 2.13. And yes, there's some difficult
questions with non-obvious answers around this. We'll deal with them
once we get there. I'm focussing on the obvious parts first.

- Reduce C code in Zope 2

My first part of this was discussed and implemented. The remaining C
code inside the Zope 2 distribution is in AccessControl,
DocumentTemplate and ZCTextIndex. We'll see what to do about them,
once their packages are actually self-contained.

- Make Zope 2 more modular

This is related to the above two points. I'm not quite sure about the
details of the implementation yet. But in general it would be nice, if
a consumer of Zope 2 could use it's core, without getting a whole
bunch of stuff it doesn't want. The obvious example here is Plone,
which continues to use less and less code from Zope 2, but has no
chance of making a radical cut and loose it all. There's interesting
problems, like being able to use Zope 2 without the ZMI. In some sense
this is similar to using the ZTK instead of zope.app. The only thing I
know for sure, is that I'd like to first make the packages inside Zope
2 standalone and reusable and only once they are, break them into more
distributions. We've gone the other way around with Zope 3 and it has
cost a whole lot of pain.

- ZODB 3.10

Jim promised a second alpha release to be out shortly. Should be low
risk to upgrade to it. The multi-threaded ZEO server promises some
good improvements.

- Python 2.7

This would be 2.7 support in addition to the existing 2.6. Last time I
checked all Zope 2 tests passed. But there where some hairy looking
test failures in zope.proxy and some more in RestrictedPython.
RestrictedPython will also need a new security review to make sure it
continues to work with 2.7.

- Python 3.x

Not on the agenda. We'll need to tackle this on the ZTK level first.


For an actual timeline, it seems autumn this year is the earliest any
2.13 could come out, so it properly supports Python 2.7 and we have
something definitive on the ZTK matter. But I'm not going to rush this
and it's somewhat more likely we'll end up with an ever later release
and match the Plone 5 release schedule.

All that said,

[Zope-dev] Zope2: Reducing C dependencies

Hi.

For Zope 2.13 (trunk) I'd like to try to reduce the C dependencies of
the Zope2 distribution itself. Ideally it would not have any C
dependencies in its own distribution, but that's a bit too much for
now.

As a next step I'd like to split out the initgroups, Missing,
MultiMapping, Record and ThreadLock packages into their own
distributions. The code in these hasn't changed in years and I don't
see this changing anytime soon.

If this is done the remaining C libraries are in AccessControl,
DocumentTemplate and ZCTextIndex. AccessControl has a reference
implementation in Python and could the C library could be made an
optional optimization. The ZCTextIndex okascore.c and stopper.c should
also be relatively easy to do as Python implementations.

DocumentTemplate has a pDocumentTemplate.py module as a reference
implementation, which clearly states that it is outdated. This would
need to be updated to match the C implementation.

Hanno
___
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] Zope2: Reducing C dependencies

On Tue, Mar 30, 2010 at 5:26 PM, Martin Aspeli optilude+li...@gmail.com wrote:
 Hanno Schlichting wrote:
 For Zope 2.13 (trunk) I'd like to try to reduce the C dependencies of
 the Zope2 distribution itself. Ideally it would not have any C
 dependencies in its own distribution

 Why?

It simplifies the release process for Zope2. In most cases upgrading
to a new version of Zope2 won't involve any changes to C code. If the
C code is split out, we won't have to release any new Windows binary
eggs of any kind. Upgrades on systems without a compiler are also
going to be easier.

Hanno
___
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] Zope2: Reducing C dependencies

On Tue, Mar 30, 2010 at 5:44 PM, Martin Aspeli optilude+li...@gmail.com wrote:
 Hanno Schlichting wrote:
 It simplifies the release process for Zope2. In most cases upgrading
 to a new version of Zope2 won't involve any changes to C code. If the
 C code is split out, we won't have to release any new Windows binary
 eggs of any kind. Upgrades on systems without a compiler are also
 going to be easier.

 +1

 I'm generally for it, we just need to (a) make sure we're not going to
 negatively impact performance if we can help it and (b) explain our
 rationale.

This is all going to be transparent to everyone. We've already split
out Acquisition, ExtensionClass (ComputedAttribute, MethodObject) in
the same way.

Note that the packages I'm proposing to split out have no Python fallback.

The C code which we might want to turn into optional optimizations at
a later point, would follow the same standard we already use in the
Zope Toolkit. So there won't be any new kind of risk. For example
zope.i18nmessageid and zope.interface use this approach.

Hanno
___
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] Zope2: Reducing C dependencies

On Tue, Mar 30, 2010 at 5:49 PM, Wichert Akkerman wich...@wiggy.net wrote:
 On 3/30/10 16:56 , Hanno Schlichting wrote:
 If this is done the remaining C libraries are in AccessControl,
 DocumentTemplate and ZCTextIndex. AccessControl has a reference
 implementation in Python and could the C library could be made an
 optional optimization. The ZCTextIndex okascore.c and stopper.c should
 also be relatively easy to do as Python implementations.

 All of those are quite stable as well, aren't they? What is the
 rationale for not splitting those out?

These packages have hairy interdependencies on lots of other things.
Like code in AccessControl modifies code inside DocumentTemplate,
DocumentTemplate imports from AccessControl at the same time. Or
Zope2.App needs HelpSys which in turn relies on ZCTextIndex. There's
many more of these examples.

Before we could think about splitting out any of these, we'd need to
clean up those dependencies. At least AccessControl has seen a lot of
changes in current Zope trunk compared to 2.12.x, so I'd be hesitant
to split it out right now.

Hanno
___
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] Zope2: Reducing C dependencies