Re: [Zope-dev] [Zope-Checkins] SVN: Zope/trunk/ merged haufe-legacy-integration branch
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 ;-)
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. 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. cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Tue, May 12, 2009 at 10:25 AM, Chris Withers <chris@simplistix.co.uk> wrote:
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?
Yes, that is possible. But I fear this list might not be the most appropriate place. Maybe we should revive the 'zope-collector' mailing list (or am I dreaming that such a list ever existed?) -- Sidnei da Silva Canonical Ltd. Landscape · Changing the way you manage your systems http://landscape.canonical.com
Sidnei da Silva wrote:
Yes, that is possible. But I fear this list might not be the most appropriate place.
Why not? I think having all developers being away of activity going on with issues related to the software would be a good thing...
Maybe we should revive the 'zope-collector' mailing list (or am I dreaming that such a list ever existed?)
I'd prefer this than nothing. At least then it's easy to join that list without having to go through Launchpad's arcane group-joining process... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
-----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@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-----
On Tue, May 12, 2009 at 02:25:38PM +0100, Chris Withers wrote:
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.
You don't have to be part of the development team. You can go to https://launchpad.net/zope/ and click on "Subscribe to bug mail" to get notification of bug changes. -- Björn Tillenius | https://launchpad.net/~bjornt
Bjorn Tillenius wrote:
On Tue, May 12, 2009 at 02:25:38PM +0100, Chris Withers wrote:
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.
You don't have to be part of the development team. You can go to https://launchpad.net/zope/ and click on "Subscribe to bug mail" to get notification of bug changes.
I see no such option on: https://launchpad.net/zope2 Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Wed, May 13, 2009 at 2:01 PM, Chris Withers <chris@simplistix.co.uk> wrote:
I see no such option on:
This page has the option: https://bugs.launchpad.net/zope2 "Bugs" tab on this link takes one to the above URL. https://launchpad.net/zope2 Chetan
On Wed, May 13, 2009 at 09:31:42AM +0100, Chris Withers wrote:
Bjorn Tillenius wrote:
On Tue, May 12, 2009 at 02:25:38PM +0100, Chris Withers wrote:
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.
You don't have to be part of the development team. You can go to https://launchpad.net/zope/ and click on "Subscribe to bug mail" to get notification of bug changes.
I see no such option on:
Oh, that's unfortunate. There you have to go to the Bugs tab, and then you should see a "Subscribe to bug mail" link in the middle of the page. -- Björn Tillenius | https://launchpad.net/~bjornt
Bjorn Tillenius wrote:
Oh, that's unfortunate. There you have to go to the Bugs tab, and then you should see a "Subscribe to bug mail" link in the middle of the page.
...and even there it's pretty well hidden. Why isn't it a "big button" like "Report a bug" and "Ask a question"? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Wed, May 13, 2009 at 09:51:42AM +0100, Chris Withers wrote:
Bjorn Tillenius wrote:
Oh, that's unfortunate. There you have to go to the Bugs tab, and then you should see a "Subscribe to bug mail" link in the middle of the page.
...and even there it's pretty well hidden.
Why isn't it a "big button" like "Report a bug" and "Ask a question"?
Because we can't have everything being big buttons ;) The more big buttons you have, the more hidden each button get. I do agree that it is kind of hidden where it is now. I'll talk to our UI designer and see if we can improve its discoverability somehow. -- Björn Tillenius | https://launchpad.net/~bjornt
participants (5)
-
Bjorn Tillenius -
Chetan Kumar -
Chris Withers -
Sidnei da Silva -
Tres Seaver