[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