[Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
lists at zopyx.com
Tue May 12 10:55:28 EDT 2009
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
>> 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
>>> 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
>> 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
> 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"
>> 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
>>>> 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)?
ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany
Web: www.zopyx.com - Email: info at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 316 bytes
Desc: not available
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20090512/89731687/attachment-0001.vcf
More information about the Zope-Dev