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: [email protected] - 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:[email protected] 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 - [email protected] 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 )
