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

[Andreas Jung]

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: 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...
Name: lists.vcf
Type: text/x-vcard
Size: 316 bytes
Desc: not available
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20090512/89731687/attachment-0001.vcf