[Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
tseaver at palladion.com
Tue May 12 10:34:29 EDT 2009
-----BEGIN PGP SIGNED MESSAGE-----
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.
> 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 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
>> 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
>> 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
>> 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"
> 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
- - 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 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
-----END PGP SIGNATURE-----
More information about the Zope-Dev