[Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch

[Chris Withers]

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