May 2009 - Zope-Dev - Zope lists

reusability markers in our documentation
by Martijn Faassen 13 May '09

13 May '09

Hi there, In the "ZTK futures" thread Chris McDonough pointed out that right now we don't signal which packages are easily reusable outside of the Zope Toolkit and which packages aren't, and need a great knowledge of the way the Zope Toolkit works and a large amount of installed packages. In order to increase our focus on reusable packages that stand on their own, and to reduce confusion by the outside world, we should signal clearly which packages should be considered by the broader community, and more importantly, which packages they can safely ignore. I've therefore created the following guideline in the Zope Toolkit decisions document: Some Zope Toolkit packages are quite reusable without having to buy into the rest of the Zope Toolkit. Others aren't reusable at all without pulling in a huge chunk of the Zope Toolkit; they depend on many assumptions. We should communicate this clearly to potential users. As a first step, we will make sure these notifications are available on the PyPI pages. We will do this by adding a message about reusability to the long_description (which gets displayed on PyPI). Typically this is done by modifying the package's README.txt or ``src/zope/../README.txt`` doctest. The following text should be used for reusable packages:: *This package is intended to be independently reusable in any Python project. It is maintained by the* `Zope Toolkit project <http://docs.zope.org/zopetoolkit/>`_. The following text should be used for packages that are *not* easily reusable:: *This package is at present not reusable without depending on a large chunk of the Zope Toolkit and its assumptions. It is maintained by the* `Zope Toolkit project <http://docs.zope.org/zopetoolkit/>`_. At the time of writing, most of our packages will be marked as *not* reusable. Only packages at the roots of our dependency tree that have a clear purpose and some documentation (such as ``zope.interface`` and ``zope.component``) should be marked as reusable. We will slowly start to build up from there. Help is needed to mark these packages. As a safe assumption, all zope.app.* packages should be marked as not reusable. It's a simple matter of going to the setup.py, seeing what file ends up being the start of long_description (typically README.txt or something like that) and modifying it with the marker text. I've marked zope.component, zope.interface and zope.schema as "reusable". That doesn't mean their documentation shouldn't be improved to support this; it should. But nevertheless it's pretty doable to reuse them today. We have more such packages; in case of any doubt about the status, please bring it up in discussions here. I've marked zope.app.publication as not reusable already. Volunteers to help mark the other packages? Regards, Martijn

1 0

Re: [Zope-dev] Mailinglist for Zope 2 bug!?
by Sidnei da Silva 13 May '09

13 May '09

On Wed, May 13, 2009 at 11:46 AM, Andreas Jung <andreas(a)andreas-jung.com> wrote: > So anyone can subscribe to Zope 2 ticket changes without having > to be a member of the Zope 2 team. Works for me. -- Sidnei da Silva Canonical Ltd. Landscape · Changing the way you manage your systems http://landscape.canonical.com

1 0

Zope Tests: 8 OK
by Zope Tests Summarizer 13 May '09

13 May '09

Summary of messages to the zope-tests list. Period Tue May 12 12:00:00 2009 UTC to Wed May 13 12:00:00 2009 UTC. There were 8 messages: 8 from Zope Tests. Tests passed OK --------------- Subject: OK : Zope-2.10 Python-2.4.6 : Linux From: Zope Tests Date: Tue May 12 20:52:26 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011691.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Tue May 12 20:54:28 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011692.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Tue May 12 20:56:29 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011693.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Tue May 12 20:58:29 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011694.html Subject: OK : Zope-trunk Python-2.6.1 : Linux From: Zope Tests Date: Tue May 12 21:00:30 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011695.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Tue May 12 21:02:30 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011696.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Tue May 12 21:04:30 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011697.html Subject: OK : Zope-trunk-alltests Python-2.6.1 : Linux From: Zope Tests Date: Tue May 12 21:06:30 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011698.html

1 0

Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
by Chris Withers 13 May '09

13 May '09

Andreas Jung wrote: >> - It's being done into the beta phase of Zope 2.12 > changes in this *early* beta phase, no changes after beta 2 are > acceptable). This feels like an abuse of your position as release manager. Can you honestly tell me that if it was anyone other than you, you'd let them merge these changes after you'd already cut beta 1? > Feature 2 (the one you are complaining about): Making <environment> a > multisection. > > The rational behind this change is clear: making the Zope configuration > more modular for bigger setups. In complex setups there is a need for > having this > extension if you don't want and can't to build a monolithic configuration. There are plenty of options other than this, the one that jumps to mind would be a buildout recipe similar to collective.recipe.template that staples together your various config file snippets into one zope.conf. > "The community" working on Zope 2.12 was basically Hanno doing most of > the work, > Tres and me. That's not quite true, other people have been contributing fixes and I know I spent a lot of time getting Zope 2.12 to work in a buildout without the need for rewriting the zope2instance recipe. But, that aside, people working on Zope 2.12 does not make up the whole community, there's the whole userbase, or even potential userbase to consider. > So the actual development is driven by the people doing the > work and by > their needs. I agree with this. > Not every new feature must be discussed in depth on the list. I don't agree with this. New features should always be discussed. Had you posted the messages you posted to the bug tracker to this list instead, and then waited a week or so for people to comment, that would have been fine. The problem is that the visibility of issues in Launchpad is very poor. You can't even get notifications of bugs unless you're part of the development team. Using it for features means that no-one in the wider community is likely to even know what's going on. That's bad as it means that no-one gets the opportunity to make suggestions or comments. This could be improved by getting issue emails sent to this list too, is that possible? > Consider this being a defect of your release process and planning. *My* release process and planning? > We are running this stuff in production at Haufe on *very*very*very* > large sites. > All those changes are the result of using Zope in enterprise-level > installations. > I don't know many other Zope installation that beat our internal and > external setups > in size and complexity. Glad to hear it, I was also glad to hear about the tools that make use of these events being released. I look forward to it :-) > The primary purpose of the <environment> section is for making > additional environment > variables available with Zope. I consider being an "internal" > functionality. Well, I consider it less than internal ;-) >> Andreas, please revert this change until people have had a chance to >> look at it properly. > Reverting the change without a discussion was offending (see above). And > I want to emphasize > once more: none of the people doing the development work need to ask for > every single > change made to the Zope 2 core for public feedback. I actually agree with this, but I don't agree in the case of new features or in the case of backwards compatibility breakages. Nevertheless, if you're intent on bulldozing this change through, please consider using and writing a test for the one additional like I gave you that should result in getConfiguration().environment being the single dict it always has been and should logically be. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

5 9

Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
by Chris Withers 12 May '09

12 May '09

Andreas Jung wrote: > Every active core developer should be member of Zope 2 dev team: > > https://launchpad.net/~zope2-dev > > It is up to each developer to join the team It took me ages to figure out how to do this, and I still couldn't tell you how to do it now. Launchpad has an *extremely* poor UI here, what would be so hard about having a "request to join this team" link somewhere prominently on the team page? It might be good to put an explanation of how to do this on: http://docs.zope.org/developer/ ...once you figure it out. Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

3 14

Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
by Andreas Jung 12 May '09

12 May '09

On 12.05.09 16:02, Andreas Jung wrote: > On 12.05.09 15:25, Chris Withers wrote: > >> Andreas Jung wrote: >> >>>> - It's being done into the beta phase of Zope 2.12 >>>> >>> changes in this *early* beta phase, no changes after beta 2 are >>> acceptable). >>> >> This feels like an abuse of your position as release manager. >> > I call it adjusting the policies as needed for getting things done and > for getting important things and I emphasize once again: it happend > during beta 1 - we proceeded always this way to some degree. I am not > the slave to the policy. > > >> Can you honestly tell me that if it was anyone other than you, you'd >> let them merge these changes after you'd already cut beta 1? >> >> >>> Feature 2 (the one you are complaining about): Making <environment> a >>> multisection. >>> >>> The rational behind this change is clear: making the Zope configuration >>> more modular for bigger setups. In complex setups there is a need for >>> having this >>> extension if you don't want and can't to build a monolithic >>> configuration. >>> >> There are plenty of options other than this, the one that jumps to >> mind would be a buildout recipe similar to collective.recipe.template >> that staples together your various config file snippets into one >> zope.conf. >> > Possibly. As said, I am not married with this particular feature. > >> >>> "The community" working on Zope 2.12 was basically Hanno doing most of >>> the work, >>> Tres and me. >>> >> That's not quite true, other people have been contributing fixes and I >> know I spent a lot of time getting Zope 2.12 to work in a buildout >> without the need for rewriting the zope2instance recipe. >> >> But, that aside, people working on Zope 2.12 does not make up the >> whole community, there's the whole userbase, or even potential >> userbase to consider. >> > We try our best for not breaking things - this happens from time to time > - usually > unintended. It's perfectly fine when an incompatiblity pops up during > the beta phase. > No need for crying out lould. > > >>> So the actual development is driven by the people doing the >>> work and by >>> their needs. >>> >> I agree with this. >> >> >>> Not every new feature must be discussed in depth on the list. >>> >> I don't agree with this. New features should always be discussed. Had >> you posted the messages you posted to the bug tracker to this list >> instead, and then waited a week or so for people to comment, that >> would have been fine. >> > A mis-configuration/mis-feature of Launchpad. There should be a list for > all LP > related traffic. Right now you have to be member of the Zope 2 group on LP. > Something we can easily fix. > > >> >>> Consider this being a defect of your release process and planning. >>> >> *My* release process and planning? >> > Sorry, basically not my problem - if you depend on bleeding-edge > releases, you > have to be aware of the consequences. And since we have no schedule for > the release, your planning is pretty much obsolete. > > >> >> >>> The primary purpose of the <environment> section is for making >>> additional environment >>> variables available with Zope. I consider being an "internal" >>> functionality. >>> >> Well, I consider it less than internal ;-) >> > That <http://dict.leo.org/ende?lp=ende&p=thMx..&search=That>'s > <http://dict.leo.org/ende?lp=ende&p=thMx..&search=s> a > <http://dict.leo.org/ende?lp=ende&p=thMx..&search=a> matter > <http://dict.leo.org/ende?lp=ende&p=thMx..&search=matter> of > <http://dict.leo.org/ende?lp=ende&p=thMx..&search=of> opinion > <http://dict.leo.org/ende?lp=ende&p=thMx..&search=opinion>. > >> >>>> Andreas, please revert this change until people have had a chance to >>>> look at it properly. >>>> >>> Reverting the change without a discussion was offending (see above). And >>> I want to emphasize >>> once more: none of the people doing the development work need to ask for >>> every single >>> change made to the Zope 2 core for public feedback. >>> >> I actually agree with this, but I don't agree in the case of new >> features or in the case of backwards compatibility breakages. >> > See above. I could not commit the fixes and new features earlier because > of constraints that don't belong into public. > >> Nevertheless, if you're intent on bulldozing this change through, >> please consider using and writing a test for the one additional like I >> gave you that should result in getConfiguration().environment being >> the single dict it always has been and should logically be. >> > Where is the test telling us that getConfiguration().environment has to > be a dict (as it is used > only internally)? > > Andreas > > -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info(a)zopyx.com - Phone +49 - 7071 - 793376 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535 Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK ------------------------------------------------------------------------ E-Publishing, Python, Zope & Plone development, Consulting

2 1

[buildbot] zc.buildout (small) failures
by Sebastien Douche 12 May '09

12 May '09

http://misc.buildbot.securactive.org/builders/zc.buildout-py2.4-32bit-linux… http://misc.buildbot.securactive.org/builders/zc.buildout-py2.4-64bit-linux… http://misc.buildbot.securactive.org/builders/zc.buildout-py2.6-32bit-linux… http://misc.buildbot.securactive.org/builders/zc.buildout-py2.6-64bit-linux… Failed example: print 'X'; print system( zc.buildout.easy_install._safe_arg(sys.executable)+' '+ 'bootstrap.py --version 1.1.1'); print 'X' Expected: X Generated script '/sample/bin/buildout'. <BLANKLINE> X Got: X Generated script '/sample/bin/buildout'. /tmp/tmp64BRh4/zc.buildout-1.1.1-py2.6.egg/zc/buildout/buildout.py:21: DeprecationWarning: the md5 module is deprecated; use hashlib instead import md5 <BLANKLINE> X --------------------------------------------------------------------------------------------- Expected: X No local packages or download links found for zc.buildout==UNKNOWN error: Could not find suitable distribution for Requirement.parse('zc.buildout==UNKNOWN') Traceback (most recent call last): File "bootstrap.py", line 78, in <module> ) == 0 AssertionError <BLANKLINE> X Got: X No local packages or download links found for zc.buildout==UNKNOWN error: Could not find suitable distribution for Requirement.parse('zc.buildout==UNKNOWN') Traceback (most recent call last): File "bootstrap.py", line 75, in ? PYTHONPATH= AssertionError <BLANKLINE> X Cheers -- Sebastien Douche <sdouche(a)gmail.com>

3 3

Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
by Andreas Jung 12 May '09

12 May '09

On 12.05.09 16:53, Andreas Jung wrote: > >> That said, I think the process issues are more important than sepcific >> changes here: >> >> - We are too late in the cycle to be jamming in huge piles of features. >> > Two is not a big pile. We had changes other than bugfixes after beta at > least in Zope 2.9, 2.10 and you added yourself a feature after 2.12.0b1. > So let's be pragmatic, not dogmatic. > >> - ChrisW is correct that adding issues to Launchpad does *not* >> constitute sufficient notice of such features. Probably less than >> ten percent of the "core" developers actually get Launchpad e-mails. >> > Every active core developer should be member of Zope 2 dev team: > > https://launchpad.net/~zope2-dev > > It is up to each developer to join the team - this is not much different > from > a mailinglist membership. > > Andreas > > -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info(a)zopyx.com - Phone +49 - 7071 - 793376 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535 Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK ------------------------------------------------------------------------ E-Publishing, Python, Zope & Plone development, Consulting

1 0

Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
by Andreas Jung 12 May '09

12 May '09

On 12.05.09 16:37, Andreas Jung wrote: > On 12.05.09 15:29, Sidnei da Silva wrote: > >> On Tue, May 12, 2009 at 10:25 AM, Chris Withers <chris(a)simplistix.co.uk> wrote: >> >> >>> The problem is that the visibility of issues in Launchpad is very poor. >>> You can't even get notifications of bugs unless you're part of the >>> development team. Using it for features means that no-one in the wider >>> community is likely to even know what's going on. That's bad as it means >>> that no-one gets the opportunity to make suggestions or comments. This >>> could be improved by getting issue emails sent to this list too, is that >>> possible? >>> >>> >> Yes, that is possible. But I fear this list might not be the most >> appropriate place. Maybe we should revive the 'zope-collector' mailing >> list (or am I dreaming that such a list ever existed?) >> >> > I *think* there was such a list. LP provides mailinglist support for > for each group > > https://launchpad.net/~zope2-dev > > but I see no option for using such a list for tracker notifications. > > I suggest to add a pseudo member to the Zope 2 dev team and configure its > mail address to some new mailman list on lists.zope.org where ppl > can subscribe/unsubscribe at their own joy and pleasure. > > If there are no other options, please vote on my proposal. > > Andreas > > > > -- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info(a)zopyx.com - Phone +49 - 7071 - 793376 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535 Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK ------------------------------------------------------------------------ E-Publishing, Python, Zope & Plone development, Consulting

1 0

Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
by Sidnei da Silva 12 May '09

12 May '09

On Tue, May 12, 2009 at 11:37 AM, Andreas Jung <andreas(a)andreas-jung.com> wrote: > I *think* there was such a list. LP provides mailinglist support for > for each group > > https://launchpad.net/~zope2-dev That's an option, creating a mailing list for the team. However it's not required. See below. > but I see no option for using such a list for tracker notifications. > > I suggest to add a pseudo member to the Zope 2 dev team and configure its > mail address to some new mailman list on lists.zope.org That's not needed. Since the zope2-dev team is automatically subscribed to issues, we only need to set it's contact address. If we set that address to zope-dev(a)lists.zope.org, then issues will automatically be delivered to it. -- Sidnei da Silva Canonical Ltd. Landscape · Changing the way you manage your systems http://landscape.canonical.com

1 0