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 )