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=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@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 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=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)?
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 another importable component.xml which could be used to extend the environment from an add-on products, rather than changing the type of the <environment> section in a BBB-incompatible way. E.g. in zopeschema.xml: <schema> ... <sectiontype name="extended-evironment" datatype=".cgi_evironment" keytype="identifier"> <description>...</description> <key name="+" attribute="environ"> <description>...</description> </key> </sectiontype> <multisection type="extended-environment" name="*" attribute="extended_environment"/> </schema> and then tweak the startup code to iterate over those sections in addition to the original one when populating os.environ:: #Zope2/Startup/handlers.py def root_handler(config): #existing <environment> code for k, v in config.environment.items(): os.environ[k] = v #extensions to os.environ from add-on products for extension in config.extended_environment: for k, v in extension.items(): os.environ[k] = v Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFKCZbS+gerLs4ltQ4RAotQAJ9lqf/mvEB+k+TVmFp1TIOLmTVaGQCgh+IU 5Bvwp0Ry+0YKisLDZu8s7bk= =NK6E -----END PGP SIGNATURE-----
participants (2)
-
Andreas Jung -
Tres Seaver