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

Tres Seaver tseaver at palladion.com
Tue May 12 10:34:29 EDT 2009


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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.
> 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 ;-)

I don't even understand the usecase:  the <product> sections were
intended to support the whole "extensible" configuration notion, and any
code written for Zope 2.9+ has had access to that feature.

That said, I think the process issues are more important than sepcific
changes here:

- - We are too late in the cycle to be jamming in huge piles of features.

- - ChrisW is correct that adding issues to Launchpad does *not*
  constitute sufficient notice of such features.  Probably less than
  ten percent of the "core" developers actually get Launchpad e-mails.

I get those mails, but stopped looking at them closely when you replied
to an earlier concern of ChrisW's that the changes were only going in on
a private branch.


Tres.
- --
===================================================================
Tres Seaver          +1 540-429-0999          tseaver at palladion.com
Palladion Software   "Excellence by Design"    http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFKCYj0+gerLs4ltQ4RAnZFAJ9hLSdFz4aBNRCkP4TgNUAZ+DVa9wCbB5iR
dsaWdswkHKTJi2uMdg5tJiA=
=v4KC
-----END PGP SIGNATURE-----



More information about the Zope-Dev mailing list