Re: [Zope-dev] [buildbot] zc.buildout (small) failures
Am 12.05.2009 um 03:21 schrieb Sebastien Douche:
http://misc.buildbot.securactive.org/builders/zc.buildout-py2.4-32bit-linux/builds/1/steps/test/logs/stdio
http://misc.buildbot.securactive.org/builders/zc.buildout-py2.4-64bit-linux/builds/7/steps/test/logs/stdio
http://misc.buildbot.securactive.org/builders/zc.buildout-py2.6-32bit-linux/builds/0/steps/test/logs/stdio
http://misc.buildbot.securactive.org/builders/zc.buildout-py2.6-64bit-linux/builds/4/steps/test/logs/stdio
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
This one I fixed in r99860.
-
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
Not sure what to do here.
Yours sincerely,
--
Michael Howitz · m...@gocept.com · software developer
gocept gmbh co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1
Zope and Plone consulting and development
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZTK futures: one big package?
chris you have *exactly* mirrored my feelings as a longtime zope2 user/application developer getting in touch with plone3/five. now after a year digging in it I still am not free of it thanks a lot robert Chris McDonough schrieb: I realize now that I've neglected to give sufficient reasoning for why less granular packaging would be a good thing. I've noticed that there's a common theme in Zope development, software, and packages that I can only describe as power law development or turtles all the way down. It's a bit of an antipattern, unfortunately. I'll provide an example by way of Zope-3-the-appserver. In an application that uses Zope-3-the-appserver, many individual subframeworks will be used. For example, there is a traversal subframework, a security subframework, a cataloging subframework, and so on. Each of these subframeworks acts as a logical unit, and through the magic of the component architecture, each can be replaced wholesale by registering some adapter. However, each of these subframeworks tend to also have settings that can be configured. For example, individual traversal steps for certain types of objects can be overridden by registering an adapter that *configures* the subframework. In the case of Zope 3, we have a traversal situation where the larger traversal subframework can either be replaced wholesale via an adapter registration or extended piecemeal via other adapter registrations. The problem is that the mechanism to *replace* the subframework is the same as the mechanism to *configure* it (both are done via adapter registration, sometimes even in the same file). This is theoretically fine. But in reality, it's tremendously hard for someone just walking up to a complex system like Zope 3 to discern adapter registrations that replace subsystems from those which merely configure subsystems. An inability to discern the difference leads to situations where people just don't get the joke and try to wiggle wires to configure-to-death a existing subsystem that's clearly suboptimal for their use case instead of just replacing it wholesale with a much simpler custom policy. They just don't know it was engineered to be replaced. So they keep adding more configuration code to the existing subframework to handle various 1% edge cases. Often this code makes the subframework tremendously complex, and the subframework grows inappropriate dependencies along the way. *Sometimes* the situation gets so confusing for a new user, they just quit and go use something else. This is a pattern that happens over and over again in Zope development. In my personal opinion, the original error was trying to make the subframework configurable at all. Instead, the subframework should be replaceable easily, but it should itself be relatively rigid. At very least, for subframeworks that really do require extra configuration (should be very few), this configuration should be done via highly specialized ZCML directives (or grokkers), as opposed to some very general adapter registration that can't be easily discerned from other adapter registrations by a newbie. If the subframeworks were more rigid (but replaceable), the *intent* of the subframework author could be more easily discerned, and fewer people would fall into the trap of adding more configuration code to a subframework instead of just replacing it entirely. And fewer people would just walk away in frustration. What does this have to do with packaging? Well, currently, there's a dizzying number of packages that make up the ZTK (nee Zope 3). Each of these packages is a pure peer of all others in a PyPI listing with no real way to get a sense of their relative importance other than performing a linear audit. Even if a user *does* do a linear search of all of them, it's still awful hard to discern for some new user which ones are important, and which ones just happen to exist by some inequity of history without trying to install it. The user needs to gain some holistic knowledge of the system in order to discern the important bits from these historical inequities. Most new users understandably just walk away from *all* Zope packages before they gain this knowledge; it's just too hard for them to tell the difference between the truly important and reusable bits and the stuff that just happens to be packaged up and released but which is useless outside of some highly specific context. In effect, we just don't communicate *intent* very effectively in our current packaging structure. In my opinion, this is why a lot of Python developers who are otherwise very smart have given up on trying to use Zope packages. The time required to figure out which ones are useful and which ones aren't is just too high. It's way easier for them to write them all off
Re: [Zope-dev] ZTK futures: one big package?
Hi, I agree with the package inflation. It makes people nervous of the complexity. But putting everything back into a pile of mud sounds like going back from where we came, and I this situation makes people even more nervous when they want to look into zope. As far as I know, the big dependency clean up is not finished yet, no? Maybe it might be better to do that first. With a clean dependency graph, its easier to see, which set of packages could be merged into one package. About the configurability of all the subpackages, I remember a proposal long time ago to reduce the number of zcml directives. This time I am in favor of inventing some zcml directives with some care. But before doing that, it might be better to write two or free easy tutorials about how to write custom zcml directives and grokkers. That would result in people writing more custom zcml directives and grokkers and get the hang of it. With the a much bigger userbase of writers of custom zcml directives and grokkers, the community as a whole will get a much better idea of how to use zcml, and I think gaining that community sense first will result in some high quality new general usable zcml directives. At the moment, and with my limited view, it looks like most zope ppl really don't know how to write custom zcml directives. Just my 0.02€ Best regards, Patrick On Tue, May 12, 2009 at 09:08, Chris McDonough chr...@plope.com wrote: I realize now that I've neglected to give sufficient reasoning for why less granular packaging would be a good thing. I've noticed that there's a common theme in Zope development, software, and packages that I can only describe as power law development or turtles all the way down. It's a bit of an antipattern, unfortunately. I'll provide an example by way of Zope-3-the-appserver. In an application that uses Zope-3-the-appserver, many individual subframeworks will be used. For example, there is a traversal subframework, a security subframework, a cataloging subframework, and so on. Each of these subframeworks acts as a logical unit, and through the magic of the component architecture, each can be replaced wholesale by registering some adapter. However, each of these subframeworks tend to also have settings that can be configured. For example, individual traversal steps for certain types of objects can be overridden by registering an adapter that *configures* the subframework. In the case of Zope 3, we have a traversal situation where the larger traversal subframework can either be replaced wholesale via an adapter registration or extended piecemeal via other adapter registrations. The problem is that the mechanism to *replace* the subframework is the same as the mechanism to *configure* it (both are done via adapter registration, sometimes even in the same file). This is theoretically fine. But in reality, it's tremendously hard for someone just walking up to a complex system like Zope 3 to discern adapter registrations that replace subsystems from those which merely configure subsystems. An inability to discern the difference leads to situations where people just don't get the joke and try to wiggle wires to configure-to-death a existing subsystem that's clearly suboptimal for their use case instead of just replacing it wholesale with a much simpler custom policy. They just don't know it was engineered to be replaced. So they keep adding more configuration code to the existing subframework to handle various 1% edge cases. Often this code makes the subframework tremendously complex, and the subframework grows inappropriate dependencies along the way. *Sometimes* the situation gets so confusing for a new user, they just quit and go use something else. This is a pattern that happens over and over again in Zope development. In my personal opinion, the original error was trying to make the subframework configurable at all. Instead, the subframework should be replaceable easily, but it should itself be relatively rigid. At very least, for subframeworks that really do require extra configuration (should be very few), this configuration should be done via highly specialized ZCML directives (or grokkers), as opposed to some very general adapter registration that can't be easily discerned from other adapter registrations by a newbie. If the subframeworks were more rigid (but replaceable), the *intent* of the subframework author could be more easily discerned, and fewer people would fall into the trap of adding more configuration code to a subframework instead of just replacing it entirely. And fewer people would just walk away in frustration. What does this have to do with packaging? Well, currently, there's a dizzying number of packages that make up the ZTK (nee Zope 3). Each of these packages is a pure peer of all others in a PyPI listing with no real way to get a sense of their relative importance other
Re: [Zope-dev] (no subject)
Chris McDonough chrism at plope.com writes: This is a pattern that happens over and over again in Zope development. In my personal opinion, the original error was trying to make the subframework configurable at all. Instead, the subframework should be replaceable easily, but it should itself be relatively rigid. At very least, for subframeworks that really do require extra configuration (should be very few), this configuration should be done via highly specialized ZCML directives (or grokkers), as opposed to some very general adapter registration that can't be easily discerned from other adapter registrations by a newbie. I agree very much that the various default Zope components could be much more rigid; this would make it easier to understand the application flow and better realize when to subclass or replace. If rigid means less configurable, then perhaps components could be made flexible by better adapting to the objects given to them, e.g. use the interfaces system to tell what kind of functionality objects inhibit and provide flexibility through this route. As such, instead of attempting to look up a custom traverser for an object, ask the object do you provide your own traversal logic?. Instead of components being primarily pluggable, they could be adaptive. \malthe ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Publishing our company internal Zope extensions and fixes
A subset of our changes landed on the current 2.12 trunk: http://svn.zope.org/Zope/trunk/doc/CHANGES.rst?rev=99866r1=99853r2=99866 Most of the stuff are bugfixes and minor improvements. The only major new feature is the introduction of publication events. All other patches submitted to Launchpad are not subject for inclusion for the Zope 2.12 release. All patches are based on work by Dieter Maurer and released with kind permission of Haufe Mediengruppe, Freiburg. Thanks! Andreas On 08.05.09 11:39, Andreas Jung wrote: Hi there, we are currently combing through our company internal Zope (2.11) version and trying to identify the stuff that is of interest for the public and the Zope 2 core (including some ZODB extensions/changes). I will create a ticket on Launchpad (containing a detailed description + patch) for the interesting items (we have roughly 50 of them) over the next days. All items are prefixed with [DM]. Everyone is invited to look at the stuff and comment on it. I also reserve the right merging some of the changes into the current trunk until the next Zope 2.12 beta2 release (intentionally breaking the rule that no new features should be added within the beta phase). Andreas ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope ) -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: i...@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 begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
Hi All,
I have some real issues with this work being done in the fashion it has:
- It's being done into the beta phase of Zope 2.12
- There's been zero discussion with the community before this was done.
Have I missed something here?
In particular:
Modified: Zope/trunk/src/ZPublisher/Publish.py
+from zope.event import notify
+from pubevents import PubStart, PubSuccess, PubFailure, \
+ PubBeforeCommit, PubAfterTraversal
+
Has anyone looked at the performance implications of all these events
(which most of us will never use) being fired off?
except:
+# save in order to give 'PubFailure' the original exception info
+exc_info = sys.exc_info()
As this is never deleted, does it not leak stack frames?
Modified: Zope/trunk/src/Zope2/Startup/handlers.py
===
--- Zope/trunk/src/Zope2/Startup/handlers.py 2009-05-12 08:32:23 UTC (rev
99865)
+++ Zope/trunk/src/Zope2/Startup/handlers.py 2009-05-12 08:49:29 UTC (rev
99866)
@@ -184,8 +184,10 @@
# Set environment variables
-for k,v in config.environment.items():
-os.environ[k] = v
+d = {}
+for s in config.environment:
+d.update(s)
+os.environ.update(d)
The change in the config that makes this necessary is pretty
unacceptable. I have lots of code that looks in config.environment, now
I have to find all that code and change it in a similar fashion. WTF?
- section type=environment attribute=environment name=*
+ multisection type=environment attribute=environment name=*
description
A section which allows a user to define arbitrary key-value pairs for
use as environment variables during Zope's run cycle. It
is not recommended to set system-related environment variables such as
PYTHONPATH within this section.
/description
- /section
+ /multisection
...this is the offending change.
Andreas, please revert this change until people have had a chance to
look at it properly.
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Publishing our company internal Zope extensions and fixes
Previously Andreas Jung wrote: A subset of our changes landed on the current 2.12 trunk: http://svn.zope.org/Zope/trunk/doc/CHANGES.rst?rev=99866r1=99853r2=99866 Most of the stuff are bugfixes and minor improvements. The only major new feature is the introduction of publication events. Can you document for the post-traversal-pre-publication event if that happens before or after validation? Wichert. -- Wichert Akkerman wich...@wiggy.netIt is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Zope Tests: 8 OK
Summary of messages to the zope-tests list. Period Mon May 11 12:00:00 2009 UTC to Tue May 12 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: Mon May 11 20:52:28 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011683.html Subject: OK : Zope-2.11 Python-2.4.6 : Linux From: Zope Tests Date: Mon May 11 20:54:31 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011684.html Subject: OK : Zope-trunk Python-2.4.6 : Linux From: Zope Tests Date: Mon May 11 20:56:34 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011685.html Subject: OK : Zope-trunk Python-2.5.4 : Linux From: Zope Tests Date: Mon May 11 20:58:35 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011686.html Subject: OK : Zope-trunk Python-2.6.1 : Linux From: Zope Tests Date: Mon May 11 21:00:41 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011687.html Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux From: Zope Tests Date: Mon May 11 21:02:57 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011688.html Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux From: Zope Tests Date: Mon May 11 21:04:59 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011689.html Subject: OK : Zope-trunk-alltests Python-2.6.1 : Linux From: Zope Tests Date: Mon May 11 21:07:03 EDT 2009 URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011690.html ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Publishing our company internal Zope extensions and fixes
On 12.05.09 13:25, Wichert Akkerman wrote: Previously Andreas Jung wrote: A subset of our changes landed on the current 2.12 trunk: http://svn.zope.org/Zope/trunk/doc/CHANGES.rst?rev=99866r1=99853r2=99866 Most of the stuff are bugfixes and minor improvements. The only major new feature is the introduction of publication events. Can you document for the post-traversal-pre-publication event if that happens before or after validation? You refer to IPubAfterTraversal? Have you checked ZPublisher/interfaces.py? Andreas -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: i...@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 begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [buildbot] zc.buildout (small) failures
Please don't spam zope-dev with these. Please just send them to me
instead.
Jim
On May 11, 2009, at 9:21 PM, Sebastien Douche wrote:
http://misc.buildbot.securactive.org/builders/zc.buildout-py2.4-32bit-linux/builds/1/steps/test/logs/stdio
http://misc.buildbot.securactive.org/builders/zc.buildout-py2.4-64bit-linux/builds/7/steps/test/logs/stdio
http://misc.buildbot.securactive.org/builders/zc.buildout-py2.6-32bit-linux/builds/0/steps/test/logs/stdio
http://misc.buildbot.securactive.org/builders/zc.buildout-py2.6-64bit-linux/builds/4/steps/test/logs/stdio
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 sdou...@gmail.com
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
--
Jim Fulton
Zope Corporation
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
On Tue, May 12, 2009 at 10:25 AM, Chris Withers ch...@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?) -- Sidnei da Silva Canonical Ltd. Landscape · Changing the way you manage your systems http://landscape.canonical.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
Sidnei da Silva wrote: Yes, that is possible. But I fear this list might not be the most appropriate place. Why not? I think having all developers being away of activity going on with issues related to the software would be a good thing... Maybe we should revive the 'zope-collector' mailing list (or am I dreaming that such a list ever existed?) I'd prefer this than nothing. At least then it's easy to join that list without having to go through Launchpad's arcane group-joining process... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 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. 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 ;-) I don't even understand the usecase: the product sections were intended to support the whole extensible configuration notion, and any code written for Zope 2.9+ has had access to that feature. 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. - - 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. I get those mails, but stopped looking at them closely when you replied to an earlier concern of ChrisW's that the changes were only going in on a private branch. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKCYj0+gerLs4ltQ4RAnZFAJ9hLSdFz4aBNRCkP4TgNUAZ+DVa9wCbB5iR dsaWdswkHKTJi2uMdg5tJiA= =v4KC -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
Andreas Jung wrote: 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. +10 for getting the mail just to come to zope-dev, where more people will see it. +1 for kicking the old zope-collector list back into action. Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
Chris Withers wrote: Andreas Jung wrote: 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. +10 for getting the mail just to come to zope-dev, where more people will see it. -10 ;) The number of collector entries is quite high and especially the random bursts of cleanups that happen from time to time can generate lots of mails which are of little interest to most people. I don't want to get every bug tracker change note on this list. A separate list for the interested is fine. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
On Tue, May 12, 2009 at 11:37 AM, Andreas Jung andr...@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-...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
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 ch...@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: i...@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 begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
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: i...@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 begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
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=endep=thMx..search=That's http://dict.leo.org/ende?lp=endep=thMx..search=s a http://dict.leo.org/ende?lp=endep=thMx..search=a matter http://dict.leo.org/ende?lp=endep=thMx..search=matter of http://dict.leo.org/ende?lp=endep=thMx..search=of opinion http://dict.leo.org/ende?lp=endep=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: i...@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 begin:vcard fn:Andreas
Re: [Zope-dev] [buildbot] zc.buildout (small) failures
On Tue, May 12, 2009 at 15:14, Jim Fulton j...@zope.com wrote: Please don't spam zope-dev with these. Please just send them to me instead. Ok, sorry for the spam. -- Sebastien Douche sdou...@gmail.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
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 ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
On 12.05.09 16:58, Chris Withers wrote: 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? Where the hell is the join link - I can't find it. It might be good to put an explanation of how to do this on: http://docs.zope.org/developer/ ...once you figure it out. Will do - after having the URL for the Join link. Andreas begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
On Tue, May 12, 2009 at 12:06 PM, Andreas Jung li...@zopyx.com wrote: Will do - after having the URL for the Join link. https://launchpad.net/~zope2-dev/+join -- Sidnei da Silva Canonical Ltd. Landscape · Changing the way you manage your systems http://landscape.canonical.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
On Tue, May 12, 2009 at 11:58 AM, Chris Withers ch...@simplistix.co.uk wrote: 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's visible enough to me right there were it is? I can understand your complaint though. That page was changed recently to show more information. You can see from the screenshot on this page that there used to be a Big Green Button in the page for joining the team: https://help.launchpad.net/Teams/Joining -- Sidnei da Silva Canonical Ltd. Landscape · Changing the way you manage your systems http://landscape.canonical.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
On Tue, May 12, 2009 at 12:08 PM, Chris Withers ch...@simplistix.co.uk wrote: Sidnei da Silva wrote: On Tue, May 12, 2009 at 12:06 PM, Andreas Jung li...@zopyx.com wrote: Will do - after having the URL for the Join link. https://launchpad.net/~zope2-dev/+join And where, exactly, are you supposed to find that?! Obviously it's not visible anymore once you *are* a member of a team. For an example of what it looks like when you're not a member of a team, see this screenshot: http://www.ubuntu-pics.de/bild/14102/screenshot_027_8l3CD1.png To me the link is perfectly clear there, with a green '+' icon and all. -- Sidnei da Silva Canonical Ltd. Landscape · Changing the way you manage your systems http://landscape.canonical.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
Sidnei da Silva wrote: On Tue, May 12, 2009 at 11:58 AM, Chris Withers ch...@simplistix.co.uk wrote: 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's visible enough to me right there were it is? Huh? I can't tell for zope2-dev as I'm a member, but I see no big green button here: https://edge.launchpad.net/~launchpad-dev Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
On Tue, May 12, 2009 at 12:12 PM, Chris Withers ch...@simplistix.co.uk wrote: Huh? I can't tell for zope2-dev as I'm a member, but I see no big green button here: https://edge.launchpad.net/~launchpad-dev Chris, please slow down and read the *whole* message and also my other replies. I can't keep up with your speed, and you you're just causing a lot of extra communication overhead by not reading what I'm writing and quickly replying with short messages. This is not IRC/IM. Thanks! -- Sidnei da Silva Canonical Ltd. Landscape · Changing the way you manage your systems http://landscape.canonical.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
On 12.05.09 17:07, Sidnei da Silva wrote: On Tue, May 12, 2009 at 12:06 PM, Andreas Jung li...@zopyx.com wrote: Will do - after having the URL for the Join link. https://launchpad.net/~zope2-dev/+join I added a note to the developers docs (should be online with the next automatic update of docs.zope.org). Andreas begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZTK futures: one big package?
On 5/12/09 4:44 AM, Patrick Gerken wrote: Hi, I agree with the package inflation. It makes people nervous of the complexity. But putting everything back into a pile of mud sounds like going back from where we came, and I this situation makes people even more nervous when they want to look into zope. As far as I know, the big dependency clean up is not finished yet, no? Maybe it might be better to do that first. With a clean dependency graph, its easier to see, which set of packages could be merged into one package. I don't think there will ever be a point where it's finished; at least not in any time frame in which Zope is still relevant at the end. Sure, we can keep the current setuptools distributions and keep pulling apart their respective dependencies forever, but by the time it's all over, it just won't matter anyway; folks will be happily using Django 3000 or Pylons 4, which will have recreated all the features we teased out. - C About the configurability of all the subpackages, I remember a proposal long time ago to reduce the number of zcml directives. This time I am in favor of inventing some zcml directives with some care. But before doing that, it might be better to write two or free easy tutorials about how to write custom zcml directives and grokkers. That would result in people writing more custom zcml directives and grokkers and get the hang of it. With the a much bigger userbase of writers of custom zcml directives and grokkers, the community as a whole will get a much better idea of how to use zcml, and I think gaining that community sense first will result in some high quality new general usable zcml directives. At the moment, and with my limited view, it looks like most zope ppl really don't know how to write custom zcml directives. Just my 0.02€ Best regards, Patrick On Tue, May 12, 2009 at 09:08, Chris McDonough chr...@plope.com mailto:chr...@plope.com wrote: I realize now that I've neglected to give sufficient reasoning for why less granular packaging would be a good thing. I've noticed that there's a common theme in Zope development, software, and packages that I can only describe as power law development or turtles all the way down. It's a bit of an antipattern, unfortunately. I'll provide an example by way of Zope-3-the-appserver. In an application that uses Zope-3-the-appserver, many individual subframeworks will be used. For example, there is a traversal subframework, a security subframework, a cataloging subframework, and so on. Each of these subframeworks acts as a logical unit, and through the magic of the component architecture, each can be replaced wholesale by registering some adapter. However, each of these subframeworks tend to also have settings that can be configured. For example, individual traversal steps for certain types of objects can be overridden by registering an adapter that *configures* the subframework. In the case of Zope 3, we have a traversal situation where the larger traversal subframework can either be replaced wholesale via an adapter registration or extended piecemeal via other adapter registrations. The problem is that the mechanism to *replace* the subframework is the same as the mechanism to *configure* it (both are done via adapter registration, sometimes even in the same file). This is theoretically fine. But in reality, it's tremendously hard for someone just walking up to a complex system like Zope 3 to discern adapter registrations that replace subsystems from those which merely configure subsystems. An inability to discern the difference leads to situations where people just don't get the joke and try to wiggle wires to configure-to-death a existing subsystem that's clearly suboptimal for their use case instead of just replacing it wholesale with a much simpler custom policy. They just don't know it was engineered to be replaced. So they keep adding more configuration code to the existing subframework to handle various 1% edge cases. Often this code makes the subframework tremendously complex, and the subframework grows inappropriate dependencies along the way. *Sometimes* the situation gets so confusing for a new user, they just quit and go use something else. This is a pattern that happens over and over again in Zope development. In my personal opinion, the original error was trying to make the subframework configurable at all. Instead, the subframework should be replaceable easily, but it should itself be relatively rigid. At very least, for subframeworks that really do require extra configuration (should be very few), this configuration
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
Sidnei da Silva wrote: On Tue, May 12, 2009 at 12:12 PM, Chris Withers ch...@simplistix.co.uk wrote: Huh? I can't tell for zope2-dev as I'm a member, but I see no big green button here: https://edge.launchpad.net/~launchpad-dev Chris, please slow down and read the *whole* message and also my other replies. I did read the *whole* message... I can't keep up with your speed, and you you're just causing a lot of extra communication overhead by not reading what I'm writing and quickly replying with short messages. I'm reading everything you're writing. What do you think I missed? What you should have said was that there's no join button on launchpad-dev because it's a restricted team, whatever that means. Are zope2-dev or zope3-dev similarly restricted teams? If so, how do people find out how to join a restricted team? Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
On Tue, May 12, 2009 at 12:25 PM, Chris Withers ch...@simplistix.co.uk wrote: I'm reading everything you're writing. What do you think I missed? You said: Huh? I can't tell for zope2-dev as I'm a member, but I see no big green button here: And the original message said: That page was changed recently to show more information. You can see from the screenshot on this page that there used to be a Big Green Button in the page for joining the team: https://help.launchpad.net/Teams/Joining That means you didn't read the whole message, and no matter how much effort I spend in explaining this to you, if you don't read the whole message then it's worthless. Are zope2-dev or zope3-dev similarly restricted teams? If so, how do people find out how to join a restricted team? See Andreas' reply. -- Sidnei da Silva Canonical Ltd. Landscape · Changing the way you manage your systems http://landscape.canonical.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
Sidnei da Silva wrote: On Tue, May 12, 2009 at 12:06 PM, Andreas Jung li...@zopyx.com wrote: Will do - after having the URL for the Join link. https://launchpad.net/~zope2-dev/+join And where, exactly, are you supposed to find that?! Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
On 12.05.09 17:25, Chris Withers wrote: Sidnei da Silva wrote: On Tue, May 12, 2009 at 12:12 PM, Chris Withers ch...@simplistix.co.uk wrote: Huh? I can't tell for zope2-dev as I'm a member, but I see no big green button here: https://edge.launchpad.net/~launchpad-dev Chris, please slow down and read the *whole* message and also my other replies. I did read the *whole* message... I can't keep up with your speed, and you you're just causing a lot of extra communication overhead by not reading what I'm writing and quickly replying with short messages. I'm reading everything you're writing. What do you think I missed? What you should have said was that there's no join button on launchpad-dev because it's a restricted team, whatever that means. Are zope2-dev or zope3-dev similarly restricted teams? If so, how do people find out how to join a restricted team? LP distinguishes between open, moderated and restricted teams. zope2-dev is a moderated team. Andreas -- ZOPYX Ltd. Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: i...@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 begin:vcard fn:Andreas Jung n:Jung;Andreas org:ZOPYX Ltd. Co. KG adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany email;internet:i...@zopyx.com title:CEO tel;work:+49-7071-793376 tel;fax:+49-7071-7936840 tel;home:+49-7071-793257 x-mozilla-html:FALSE url:www.zopyx.com version:2.1 end:vcard ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andreas Jung wrote: 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=endep=thMx..search=That's http://dict.leo.org/ende?lp=endep=thMx..search=s a http://dict.leo.org/ende?lp=endep=thMx..search=a matter http://dict.leo.org/ende?lp=endep=thMx..search=matter of http://dict.leo.org/ende?lp=endep=thMx..search=of opinion http://dict.leo.org/ende?lp=endep=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)? I would consider the section type in 'zopeschema.xml' to be part of a public-facing API: the attrribute name 'environ' is part of the documented schema. Assuming that jamming things into os.environ from add-ons is a hard requiremnt (I can't imagine that, myself: a lot of the point of ZConfig was to move *away* from dependencies on os.environ), it would be trivial to add
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
Sidnei da Silva wrote: And the original message said: That page was changed recently to show more information. You can see from the screenshot on this page that there used to be a Big Green Button in the page for joining the team: https://help.launchpad.net/Teams/Joining Yes, I read this, but since, as you say, launchpad has changed, this information is no longer relevant so I didn't reply to it. Are zope2-dev or zope3-dev similarly restricted teams? If so, how do people find out how to join a restricted team? See Andreas' reply. I have and was waiting for you to reply, I was hoping you could explain where you'd find a join link for a moderated team... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
On Tue, May 12, 2009 at 12:38 PM, Chris Withers ch...@simplistix.co.uk wrote: Sidnei da Silva wrote: And the original message said: That page was changed recently to show more information. You can see from the screenshot on this page that there used to be a Big Green Button in the page for joining the team: https://help.launchpad.net/Teams/Joining Yes, I read this, but since, as you say, launchpad has changed, this information is no longer relevant so I didn't reply to it. /me shrugs. I was pointing out that there *used* to be a Big Green Button, and it doesn't exist anymore. You said I don't see a Big Green Button. Of course the information is relevant. I was telling you *NOT* to look for a Big Green Button because it doesn't exist anymore, and, still, you looked for one. Are zope2-dev or zope3-dev similarly restricted teams? If so, how do people find out how to join a restricted team? See Andreas' reply. I have and was waiting for you to reply, I was hoping you could explain where you'd find a join link for a moderated team... The screenshot I've sent is for a moderated team, gnome-terminator. The link is visible there and would be in the same location for someone joining zope-dev. -- Sidnei da Silva Canonical Ltd. Landscape · Changing the way you manage your systems http://landscape.canonical.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
Sidnei da Silva wrote: Obviously it's not visible anymore once you *are* a member of a team. For an example of what it looks like when you're not a member of a team, see this screenshot: http://www.ubuntu-pics.de/bild/14102/screenshot_027_8l3CD1.png To me the link is perfectly clear there, with a green '+' icon and all. Hmm, may just have been me then. My membership somehow became 'deactivated' before and I didn't get the add link but I wasn't getting the tracker emails either. I've left the Launchpad Beta group, so I shouldn't have edge. interfering with things anymore... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZTK futures: one big package?
On Tue, May 12, 2009 at 03:08:05AM -0400, Chris McDonough wrote: Once we deflate our current set of packages down to a reasonable number, the packages listed in PyPI will immediately start to reflect the state of reality right now. As a result, we'll hopefully be able to get some new blood in the form of new developers that use the smaller bits outside Zope to help us tease the truly independent pieces out of the larger pile. If we do this, at no time after the deflation will PyPI listings ever as badly advertise the state of reality as it is advertised right now, and the community will hopefully again start to grow. I agree with a lot of what you wrote, but I don't understand this last bit. All the currently released packages will continue to live on pypi more or less forever, no? To paraphrase a wise man, Releasing a package means always having to say you're sorry ;-) -- Paul Winkler http://www.slinkp.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZTK futures: one big package?
On 5/12/09 12:27 PM, Paul Winkler wrote: On Tue, May 12, 2009 at 03:08:05AM -0400, Chris McDonough wrote: Once we deflate our current set of packages down to a reasonable number, the packages listed in PyPI will immediately start to reflect the state of reality right now. As a result, we'll hopefully be able to get some new blood in the form of new developers that use the smaller bits outside Zope to help us tease the truly independent pieces out of the larger pile. If we do this, at no time after the deflation will PyPI listings ever as badly advertise the state of reality as it is advertised right now, and the community will hopefully again start to grow. I agree with a lot of what you wrote, but I don't understand this last bit. All the currently released packages will continue to live on pypi more or less forever, no? To paraphrase a wise man, Releasing a package means always having to say you're sorry ;-) I don't think so. People would need to change their code to depend on the big package, and the smaller packages would cease to have a life of their own. Having both the smaller packages and some bigger package that also contains it and needing to maintain both truly would be the worst of all possible worlds. - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZTK futures: one big package?
On Tue, May 12, 2009 at 12:36:06PM -0400, Chris McDonough wrote: On 5/12/09 12:27 PM, Paul Winkler wrote: I agree with a lot of what you wrote, but I don't understand this last bit. All the currently released packages will continue to live on pypi more or less forever, no? To paraphrase a wise man, Releasing a package means always having to say you're sorry ;-) I don't think so. People would need to change their code to depend on the big package, and the smaller packages would cease to have a life of their own. Having both the smaller packages and some bigger package that also contains it and needing to maintain both truly would be the worst of all possible worlds. I must be dense today because I still don't understand what cease to have a life means. Remove them from pypi? How would you avoid breaking all the current software in the world that currently depends on all those distributions? -- Paul Winkler http://www.slinkp.com ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] ZTK futures: one big package?
On 5/12/09 12:46 PM, Paul Winkler wrote: On Tue, May 12, 2009 at 12:36:06PM -0400, Chris McDonough wrote: On 5/12/09 12:27 PM, Paul Winkler wrote: I agree with a lot of what you wrote, but I don't understand this last bit. All the currently released packages will continue to live on pypi more or less forever, no? To paraphrase a wise man, Releasing a package means always having to say you're sorry ;-) I don't think so. People would need to change their code to depend on the big package, and the smaller packages would cease to have a life of their own. Having both the smaller packages and some bigger package that also contains it and needing to maintain both truly would be the worst of all possible worlds. I must be dense today because I still don't understand what cease to have a life means. Remove them from pypi? How would you avoid breaking all the current software in the world that currently depends on all those distributions? If your package depends on zope.app.publisher, you get *78* eggs. Change that install_requires line in your package to ZTK and you get the same software. OTOH, packages that rely on things that are *truly reusable* like zope.interface, and so on will need to do nothing; those packages will continue to have a life of their own. - C ___ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
