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
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
> 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
> 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
> 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
> 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"
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.
Simplistix - Content Management, Zope & Python Consulting
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -