Re: [Zope-dev] "ZTK" futures: one big package?

[Chris McDonough]

I realize now that I've neglected to give sufficient reasoning for why less 
granular packaging would be a good thing.

I've noticed that there's a common theme in Zope development, software, and 
packages that I can only describe as "power law development" or "turtles all 
the 
way down".  It's a bit of an antipattern, unfortunately.

I'll provide an example by way of Zope-3-the-appserver.  In an application that 
uses Zope-3-the-appserver, many individual subframeworks will be used.  For 
example, there is a traversal subframework, a security subframework, a 
cataloging subframework, and so on.

Each of these subframeworks acts as a logical unit, and through the magic of 
the 
component architecture, each can be replaced wholesale by registering some 
adapter.  However, each of these subframeworks tend to also have settings that 
can be configured.  For example, individual traversal steps for certain types 
of 
objects can be overridden by registering an adapter that *configures* the 
subframework.  In the case of Zope 3, we have a traversal situation where the 
larger traversal subframework can either be replaced wholesale via an adapter 
registration or extended piecemeal via other adapter registrations.

The problem is that the mechanism to *replace* the subframework is the same as 
the mechanism to *configure* it (both are done via adapter registration, 
sometimes even in the same file).  This is theoretically fine.  But in reality, 
it's tremendously hard for someone just walking up to a complex system like 
Zope 
3 to discern adapter registrations that replace subsystems from those which 
merely configure subsystems.  An inability to discern the difference leads to 
situations where people just "don't get the joke" and try to wiggle wires to 
configure-to-death a existing subsystem that's clearly suboptimal for their use 
case instead of just replacing it wholesale with a much simpler custom policy. 
They just don't know it was engineered to be replaced.  So they keep adding 
more 
configuration code to the existing subframework to handle various 1% edge 
cases. 
  Often this code makes the subframework tremendously complex, and the 
subframework grows inappropriate dependencies along the way.  *Sometimes* the 
situation gets so confusing for a new user, they just quit and go use something 
else.

This is a pattern that happens over and over again in Zope development.  In my 
personal opinion, the original error was trying to make the subframework 
configurable at all.  Instead, the subframework should be replaceable easily, 
but it should itself be relatively rigid.  At very least, for subframeworks 
that 
really do require extra configuration (should be very few), this configuration 
should be done via highly specialized ZCML directives (or grokkers), as opposed 
to some very general adapter registration that can't be easily discerned from 
other adapter registrations by a newbie.

If the subframeworks were more rigid (but replaceable), the *intent* of the 
subframework author could be more easily discerned, and fewer people would fall 
into the trap of adding more configuration code to a subframework instead of 
just replacing it entirely.  And fewer people would just walk away in 
frustration.

What does this have to do with packaging?  Well, currently, there's a dizzying 
number of packages that make up "the ZTK" (nee "Zope 3").  Each of these 
packages is a pure peer of all others in a PyPI listing with no real way to get 
a sense of their relative importance other than performing a linear audit.  
Even 
if a user *does* do a linear search of all of them, it's still awful hard to 
discern for some new user which ones are "important", and which ones just 
happen 
to exist by some inequity of history without trying to install it.  The user 
needs to gain some holistic knowledge of the system in order to discern the 
important bits from these historical inequities.

Most new users understandably just walk away from *all* Zope packages before 
they gain this knowledge; it's just too hard for them to tell the difference 
between the truly important and reusable bits and the stuff that just happens 
to 
be packaged up and released but which is useless outside of some highly 
specific 
context.  In effect, we just don't communicate *intent* very effectively in our 
current packaging structure.

In my opinion, this is why a lot of Python developers who are otherwise very 
smart have given up on trying to use Zope packages.  The time required to 
figure 
out which ones are useful and which ones aren't is just too high.  It's way 
"easier" for them to write them all off wholesale and just write what they need 
from scratch or use somebody else's software.  Good developers tend to like 
small, useful libraries and frameworks.

We can ameliorate the situation in a few ways:

- We can reduce the number of distributions.

- We can make each current Zope package distribution independently useful.

My sugges

Re: [Zope-dev] [buildbot] zc.buildout (small) failures

[Michael Howitz]

Am 12.05.2009 um 03:21 schrieb Sebastien Douche:
> http://misc.buildbot.securactive.org/builders/zc.buildout-py2.4-32bit-linux/builds/1/steps/test/logs/stdio
> http://misc.buildbot.securactive.org/builders/zc.buildout-py2.4-64bit-linux/builds/7/steps/test/logs/stdio
> http://misc.buildbot.securactive.org/builders/zc.buildout-py2.6-32bit-linux/builds/0/steps/test/logs/stdio
> http://misc.buildbot.securactive.org/builders/zc.buildout-py2.6-64bit-linux/builds/4/steps/test/logs/stdio
>
> Failed example:
>print 'X'; print system(
>zc.buildout.easy_install._safe_arg(sys.executable)+' '+
>'bootstrap.py --version 1.1.1'); print 'X'
> Expected:
>X
>Generated script '/sample/bin/buildout'.
>
>X
> Got:
>X
>Generated script '/sample/bin/buildout'.
>/tmp/tmp64BRh4/zc.buildout-1.1.1-py2.6.egg/zc/buildout/ 
> buildout.py:21:
> DeprecationWarning: the md5 module is deprecated; use hashlib instead
>  import md5
>
>X

This one I fixed in r99860.

> -
> Expected:
>X
>No local packages or download links found for zc.buildout==UNKNOWN
>error: Could not find suitable distribution for
> Requirement.parse('zc.buildout==UNKNOWN')
>Traceback (most recent call last):
>  File "bootstrap.py", line 78, in 
>) == 0
>AssertionError
>
>X
> Got:
>X
>No local packages or download links found for zc.buildout==UNKNOWN
>error: Could not find suitable distribution for
> Requirement.parse('zc.buildout==UNKNOWN')
>Traceback (most recent call last):
>  File "bootstrap.py", line 75, in ?
>PYTHONPATH=
>AssertionError
>
>X


Not sure what to do here.

Yours sincerely,
-- 
Michael Howitz · m...@gocept.com · software developer
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 8 · fax +49 345 1229889 1
Zope and Plone consulting and development

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] "ZTK" futures: one big package?

[robert rottermann]

chris
you have *exactly* mirrored my feelings as a longtime zope2 user/application
developer getting in touch with plone3/five.
now after a year digging in it I still am not free of it

thanks a lot
robert

Chris McDonough schrieb:
> I realize now that I've neglected to give sufficient reasoning for why less 
> granular packaging would be a good thing.
> 
> I've noticed that there's a common theme in Zope development, software, and 
> packages that I can only describe as "power law development" or "turtles all 
> the 
> way down".  It's a bit of an antipattern, unfortunately.
> 
> I'll provide an example by way of Zope-3-the-appserver.  In an application 
> that 
> uses Zope-3-the-appserver, many individual subframeworks will be used.  For 
> example, there is a traversal subframework, a security subframework, a 
> cataloging subframework, and so on.
> 
> Each of these subframeworks acts as a logical unit, and through the magic of 
> the 
> component architecture, each can be replaced wholesale by registering some 
> adapter.  However, each of these subframeworks tend to also have settings 
> that 
> can be configured.  For example, individual traversal steps for certain types 
> of 
> objects can be overridden by registering an adapter that *configures* the 
> subframework.  In the case of Zope 3, we have a traversal situation where the 
> larger traversal subframework can either be replaced wholesale via an adapter 
> registration or extended piecemeal via other adapter registrations.
> 
> The problem is that the mechanism to *replace* the subframework is the same 
> as 
> the mechanism to *configure* it (both are done via adapter registration, 
> sometimes even in the same file).  This is theoretically fine.  But in 
> reality, 
> it's tremendously hard for someone just walking up to a complex system like 
> Zope 
> 3 to discern adapter registrations that replace subsystems from those which 
> merely configure subsystems.  An inability to discern the difference leads to 
> situations where people just "don't get the joke" and try to wiggle wires to 
> configure-to-death a existing subsystem that's clearly suboptimal for their 
> use 
> case instead of just replacing it wholesale with a much simpler custom 
> policy. 
> They just don't know it was engineered to be replaced.  So they keep adding 
> more 
> configuration code to the existing subframework to handle various 1% edge 
> cases. 
>   Often this code makes the subframework tremendously complex, and the 
> subframework grows inappropriate dependencies along the way.  *Sometimes* the 
> situation gets so confusing for a new user, they just quit and go use 
> something 
> else.
> 
> This is a pattern that happens over and over again in Zope development.  In 
> my 
> personal opinion, the original error was trying to make the subframework 
> configurable at all.  Instead, the subframework should be replaceable easily, 
> but it should itself be relatively rigid.  At very least, for subframeworks 
> that 
> really do require extra configuration (should be very few), this 
> configuration 
> should be done via highly specialized ZCML directives (or grokkers), as 
> opposed 
> to some very general adapter registration that can't be easily discerned from 
> other adapter registrations by a newbie.
> 
> If the subframeworks were more rigid (but replaceable), the *intent* of the 
> subframework author could be more easily discerned, and fewer people would 
> fall 
> into the trap of adding more configuration code to a subframework instead of 
> just replacing it entirely.  And fewer people would just walk away in 
> frustration.
> 
> What does this have to do with packaging?  Well, currently, there's a 
> dizzying 
> number of packages that make up "the ZTK" (nee "Zope 3").  Each of these 
> packages is a pure peer of all others in a PyPI listing with no real way to 
> get 
> a sense of their relative importance other than performing a linear audit.  
> Even 
> if a user *does* do a linear search of all of them, it's still awful hard to 
> discern for some new user which ones are "important", and which ones just 
> happen 
> to exist by some inequity of history without trying to install it.  The user 
> needs to gain some holistic knowledge of the system in order to discern the 
> important bits from these historical inequities.
> 
> Most new users understandably just walk away from *all* Zope packages before 
> they gain this knowledge; it's just too hard for them to tell the difference 
> between the truly important and reusable bits and the stuff that just happens 
> to 
> be packaged up and released but which is useless outside of some highly 
> specific 
> context.  In effect, we just don't communicate *intent* very effectively in 
> our 
> current packaging structure.
> 
> In my opinion, this is why a lot of Python developers who are otherwise very 
> smart have given up on trying to use Zope packages.  The time required to 
> figure 
> out which one

Re: [Zope-dev] "ZTK" futures: one big package?

[Patrick Gerken]

Hi,

I agree with the package inflation. It makes people nervous of the
complexity.
But putting everything back into a pile of mud sounds like going back from
where we came, and I this situation makes people even more nervous when they
want to look into zope.
As far as I know, the big dependency clean up is not finished yet, no? Maybe
it might be better to do that first. With a clean dependency graph, its
easier to see, which set of packages could be merged into one package.
About the configurability of all the subpackages, I remember a proposal long
time ago to reduce the number of zcml directives. This time I am in favor of
inventing some zcml directives with some care. But before doing that, it
might be better to write two or free easy tutorials about how to write
custom zcml directives and grokkers. That would result in people writing
more custom zcml directives and grokkers and get the hang of it. With the a
much bigger userbase of writers of custom zcml directives and grokkers, the
community as a whole will get a much better idea of how to use zcml, and I
think gaining that community sense first will result in some high quality
new general usable zcml directives. At the moment, and with my limited view,
it looks like most zope ppl really don't know how to write custom zcml
directives.

Just my 0.02€

Best regards,

   Patrick



On Tue, May 12, 2009 at 09:08, Chris McDonough  wrote:

> I realize now that I've neglected to give sufficient reasoning for why less
> granular packaging would be a good thing.
>
> I've noticed that there's a common theme in Zope development, software, and
> packages that I can only describe as "power law development" or "turtles
> all the
> way down".  It's a bit of an antipattern, unfortunately.
>
> I'll provide an example by way of Zope-3-the-appserver.  In an application
> that
> uses Zope-3-the-appserver, many individual subframeworks will be used.  For
> example, there is a traversal subframework, a security subframework, a
> cataloging subframework, and so on.
>
> Each of these subframeworks acts as a logical unit, and through the magic
> of the
> component architecture, each can be replaced wholesale by registering some
> adapter.  However, each of these subframeworks tend to also have settings
> that
> can be configured.  For example, individual traversal steps for certain
> types of
> objects can be overridden by registering an adapter that *configures* the
> subframework.  In the case of Zope 3, we have a traversal situation where
> the
> larger traversal subframework can either be replaced wholesale via an
> adapter
> registration or extended piecemeal via other adapter registrations.
>
> The problem is that the mechanism to *replace* the subframework is the same
> as
> the mechanism to *configure* it (both are done via adapter registration,
> sometimes even in the same file).  This is theoretically fine.  But in
> reality,
> it's tremendously hard for someone just walking up to a complex system like
> Zope
> 3 to discern adapter registrations that replace subsystems from those which
> merely configure subsystems.  An inability to discern the difference leads
> to
> situations where people just "don't get the joke" and try to wiggle wires
> to
> configure-to-death a existing subsystem that's clearly suboptimal for their
> use
> case instead of just replacing it wholesale with a much simpler custom
> policy.
> They just don't know it was engineered to be replaced.  So they keep adding
> more
> configuration code to the existing subframework to handle various 1% edge
> cases.
>  Often this code makes the subframework tremendously complex, and the
> subframework grows inappropriate dependencies along the way.  *Sometimes*
> the
> situation gets so confusing for a new user, they just quit and go use
> something
> else.
>
> This is a pattern that happens over and over again in Zope development.  In
> my
> personal opinion, the original error was trying to make the subframework
> configurable at all.  Instead, the subframework should be replaceable
> easily,
> but it should itself be relatively rigid.  At very least, for subframeworks
> that
> really do require extra configuration (should be very few), this
> configuration
> should be done via highly specialized ZCML directives (or grokkers), as
> opposed
> to some very general adapter registration that can't be easily discerned
> from
> other adapter registrations by a newbie.
>
> If the subframeworks were more rigid (but replaceable), the *intent* of the
> subframework author could be more easily discerned, and fewer people would
> fall
> into the trap of adding more configuration code to a subframework instead
> of
> just replacing it entirely.  And fewer people would just walk away in
> frustration.
>
> What does this have to do with packaging?  Well, currently, there's a
> dizzying
> number of packages that make up "the ZTK" (nee "Zope 3").  Each of these
> packages is a pure peer of all others in a PyPI listi

Re: [Zope-dev] (no subject)

[Malthe Borch]

Chris McDonough  plope.com> writes:
> This is a pattern that happens over and over again in Zope
> development.  In my personal opinion, the original error was trying
> to make the subframework configurable at all.  Instead, the
> subframework should be replaceable easily, but it should itself be
> relatively rigid.  At very least, for subframeworks that really do
> require extra configuration (should be very few), this configuration
> should be done via highly specialized ZCML directives (or grokkers),
> as opposed to some very general adapter registration that can't be
> easily discerned from other adapter registrations by a newbie.

I agree very much that the various default Zope components could be
much more rigid; this would make it easier to understand the
application flow and better realize when to subclass or replace.

If rigid means less configurable, then perhaps components could be
made flexible by better adapting to the objects given to them,
e.g. use the interfaces system to tell what kind of functionality
objects inhibit and provide flexibility through this route.

As such, instead of attempting to look up a custom traverser for an
object, ask the object "do you provide your own traversal
logic?". Instead of components being primarily pluggable, they could
be adaptive.

\malthe

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Publishing our company internal Zope extensions and fixes

[Andreas Jung]

A subset of our changes landed on the current 2.12 trunk:

http://svn.zope.org/Zope/trunk/doc/CHANGES.rst?rev=99866&r1=99853&r2=99866

Most of the stuff are bugfixes and minor improvements. The only major
new feature is the introduction of publication events.

All other patches submitted to Launchpad are not subject for inclusion
for the Zope 2.12 release.

All patches are based on work by Dieter Maurer and released with
kind permission of Haufe Mediengruppe, Freiburg. Thanks!

Andreas

On 08.05.09 11:39, Andreas Jung wrote:
> Hi there,
>
> we are currently combing through our company internal Zope (2.11) version
> and trying to identify the stuff that is of interest for the public and the
> Zope 2 core (including some ZODB extensions/changes). I will create a ticket
> on Launchpad (containing a detailed description + patch)
> for the interesting items (we have roughly 50 of them) over the next
> days. All items are prefixed with "[DM]".
> Everyone is invited to look at the stuff and
> comment on it. I also reserve the right merging some of the changes into
> the current
> trunk until the next Zope 2.12 beta2 release (intentionally breaking the
> rule
> that no new features should be added within the beta phase).
>
> Andreas
>   
> 
>
> ___
> Zope-Dev maillist  -  Zope-Dev@zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists - 
>  http://mail.zope.org/mailman/listinfo/zope-announce
>  http://mail.zope.org/mailman/listinfo/zope )
>   


-- 
ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany
Web: www.zopyx.com - Email: i...@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


begin:vcard
fn:Andreas Jung
n:Jung;Andreas
org:ZOPYX Ltd. & Co. KG
adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany
email;internet:i...@zopyx.com
title:CEO
tel;work:+49-7071-793376
tel;fax:+49-7071-7936840
tel;home:+49-7071-793257
x-mozilla-html:FALSE
url:www.zopyx.com
version:2.1
end:vcard

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

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

[Chris Withers]

Hi All,

I have some real issues with this work being done in the fashion it has:

- It's being done into the beta phase of Zope 2.12

- There's been zero discussion with the community before this was done.

Have I missed something here?

In particular:
> Modified: Zope/trunk/src/ZPublisher/Publish.py
> +from zope.event import notify
>  
> +from pubevents import PubStart, PubSuccess, PubFailure, \
> + PubBeforeCommit, PubAfterTraversal
> +

Has anyone looked at the performance implications of all these events 
(which most of us will never use) being fired off?

>  except:
> +# save in order to give 'PubFailure' the original exception info
> +exc_info = sys.exc_info()

As this is never deleted, does it not leak stack frames?

> Modified: Zope/trunk/src/Zope2/Startup/handlers.py
> ===
> --- Zope/trunk/src/Zope2/Startup/handlers.py  2009-05-12 08:32:23 UTC (rev 
> 99865)
> +++ Zope/trunk/src/Zope2/Startup/handlers.py  2009-05-12 08:49:29 UTC (rev 
> 99866)
> @@ -184,8 +184,10 @@
>  """
>  
>  # Set environment variables
> -for k,v in config.environment.items():
> -os.environ[k] = v
> +d = {}
> +for s in config.environment: 
> +d.update(s)
> +os.environ.update(d)

The change in the config that makes this necessary is pretty 
unacceptable. I have lots of code that looks in config.environment, now 
I have to find all that code and change it in a similar fashion. WTF?

> -  
> +  
>  
>   A section which allows a user to define arbitrary key-value pairs for
>   use as environment variables during Zope's run cycle.  It
>   is not recommended to set system-related environment variables such as
>   PYTHONPATH within this section.
>  
> -  
> +  

...this is the offending change.

Andreas, please revert this change until people have had a chance to 
look at it properly.

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Publishing our company internal Zope extensions and fixes

[Wichert Akkerman]

Previously Andreas Jung wrote:
> A subset of our changes landed on the current 2.12 trunk:
> 
> http://svn.zope.org/Zope/trunk/doc/CHANGES.rst?rev=99866&r1=99853&r2=99866
> 
> Most of the stuff are bugfixes and minor improvements. The only major
> new feature is the introduction of publication events.

Can you document for the post-traversal-pre-publication event if that
happens before or after validation?

Wichert.

-- 
Wichert Akkerman It is simple to make things.
http://www.wiggy.net/   It is hard to make things simple.
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

[Zope-dev] Zope Tests: 8 OK

[Zope Tests Summarizer]

Summary of messages to the zope-tests list.
Period Mon May 11 12:00:00 2009 UTC to Tue May 12 12:00:00 2009 UTC.
There were 8 messages: 8 from Zope Tests.


Tests passed OK
---

Subject: OK : Zope-2.10 Python-2.4.6 : Linux
From: Zope Tests
Date: Mon May 11 20:52:28 EDT 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011683.html

Subject: OK : Zope-2.11 Python-2.4.6 : Linux
From: Zope Tests
Date: Mon May 11 20:54:31 EDT 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011684.html

Subject: OK : Zope-trunk Python-2.4.6 : Linux
From: Zope Tests
Date: Mon May 11 20:56:34 EDT 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011685.html

Subject: OK : Zope-trunk Python-2.5.4 : Linux
From: Zope Tests
Date: Mon May 11 20:58:35 EDT 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011686.html

Subject: OK : Zope-trunk Python-2.6.1 : Linux
From: Zope Tests
Date: Mon May 11 21:00:41 EDT 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011687.html

Subject: OK : Zope-trunk-alltests Python-2.4.6 : Linux
From: Zope Tests
Date: Mon May 11 21:02:57 EDT 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011688.html

Subject: OK : Zope-trunk-alltests Python-2.5.4 : Linux
From: Zope Tests
Date: Mon May 11 21:04:59 EDT 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011689.html

Subject: OK : Zope-trunk-alltests Python-2.6.1 : Linux
From: Zope Tests
Date: Mon May 11 21:07:03 EDT 2009
URL: http://mail.zope.org/pipermail/zope-tests/2009-May/011690.html

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] Publishing our company internal Zope extensions and fixes

[Andreas Jung]

On 12.05.09 13:25, Wichert Akkerman wrote:
> Previously Andreas Jung wrote:
>   
>> A subset of our changes landed on the current 2.12 trunk:
>>
>> http://svn.zope.org/Zope/trunk/doc/CHANGES.rst?rev=99866&r1=99853&r2=99866
>>
>> Most of the stuff are bugfixes and minor improvements. The only major
>> new feature is the introduction of publication events.
>> 
> Can you document for the post-traversal-pre-publication event if that
> happens before or after validation?
>   

You refer to IPubAfterTraversal? Have you checked ZPublisher/interfaces.py?

Andreas

-- 
ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany
Web: www.zopyx.com - Email: i...@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


begin:vcard
fn:Andreas Jung
n:Jung;Andreas
org:ZOPYX Ltd. & Co. KG
adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany
email;internet:i...@zopyx.com
title:CEO
tel;work:+49-7071-793376
tel;fax:+49-7071-7936840
tel;home:+49-7071-793257
x-mozilla-html:FALSE
url:www.zopyx.com
version:2.1
end:vcard

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] [buildbot] zc.buildout (small) failures

[Jim Fulton]

Please don't spam zope-dev with these. Please just send them to me  
instead.

Jim

On May 11, 2009, at 9:21 PM, Sebastien Douche wrote:

> http://misc.buildbot.securactive.org/builders/zc.buildout-py2.4-32bit-linux/builds/1/steps/test/logs/stdio
> http://misc.buildbot.securactive.org/builders/zc.buildout-py2.4-64bit-linux/builds/7/steps/test/logs/stdio
> http://misc.buildbot.securactive.org/builders/zc.buildout-py2.6-32bit-linux/builds/0/steps/test/logs/stdio
> http://misc.buildbot.securactive.org/builders/zc.buildout-py2.6-64bit-linux/builds/4/steps/test/logs/stdio
>
> Failed example:
>print 'X'; print system(
>zc.buildout.easy_install._safe_arg(sys.executable)+' '+
>'bootstrap.py --version 1.1.1'); print 'X'
> Expected:
>X
>Generated script '/sample/bin/buildout'.
>
>X
> Got:
>X
>Generated script '/sample/bin/buildout'.
>/tmp/tmp64BRh4/zc.buildout-1.1.1-py2.6.egg/zc/buildout/ 
> buildout.py:21:
> DeprecationWarning: the md5 module is deprecated; use hashlib instead
>  import md5
>
>X
>
> -
> Expected:
>X
>No local packages or download links found for zc.buildout==UNKNOWN
>error: Could not find suitable distribution for
> Requirement.parse('zc.buildout==UNKNOWN')
>Traceback (most recent call last):
>  File "bootstrap.py", line 78, in 
>) == 0
>AssertionError
>
>X
> Got:
>X
>No local packages or download links found for zc.buildout==UNKNOWN
>error: Could not find suitable distribution for
> Requirement.parse('zc.buildout==UNKNOWN')
>Traceback (most recent call last):
>  File "bootstrap.py", line 75, in ?
>PYTHONPATH=
>AssertionError
>
>X
>
>
>
> Cheers
>
> -- 
> Sebastien Douche 
> ___
> Zope-Dev maillist  -  Zope-Dev@zope.org
> http://mail.zope.org/mailman/listinfo/zope-dev
> **  No cross posts or HTML encoding!  **
> (Related lists -
> http://mail.zope.org/mailman/listinfo/zope-announce
> http://mail.zope.org/mailman/listinfo/zope )

--
Jim Fulton
Zope Corporation


___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

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

[Chris Withers]

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  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  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
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

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

[Sidnei da Silva]

On Tue, May 12, 2009 at 10:25 AM, 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. 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
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

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

[Chris Withers]

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
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

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

[Tres Seaver]

-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  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  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  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  tsea...@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-

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

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

[Chris Withers]

Andreas Jung wrote:
> but I see no option for using such a list for tracker notifications.
> 
> I suggest to add a pseudo member to the Zope 2 dev team and configure its
> mail address to some new mailman list on lists.zope.org where ppl
> can subscribe/unsubscribe at their own joy and pleasure.
> 
> If there are no other options, please vote on my proposal.

+10 for getting the mail just to come to zope-dev, where more people 
will see it.

+1 for kicking the old zope-collector list back into action.

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

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

[Hanno Schlichting]

Chris Withers wrote:
> Andreas Jung wrote:
>> but I see no option for using such a list for tracker notifications.
>>
>> I suggest to add a pseudo member to the Zope 2 dev team and configure its
>> mail address to some new mailman list on lists.zope.org where ppl
>> can subscribe/unsubscribe at their own joy and pleasure.
>>
>> If there are no other options, please vote on my proposal.
> 
> +10 for getting the mail just to come to zope-dev, where more people 
> will see it.

-10 ;) The number of collector entries is quite high and especially the
random bursts of cleanups that happen from time to time can generate
lots of mails which are of little interest to most people.

I don't want to get every bug tracker change note on this list. A
separate list for the interested is fine.

Hanno

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

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

[Sidnei da Silva]

On Tue, May 12, 2009 at 11:37 AM, Andreas Jung  wrote:
> I *think* there was such a list. LP provides mailinglist support for
> for each group
>
> https://launchpad.net/~zope2-dev

That's an option, creating a mailing list for the team. However it's
not required. See below.

> but I see no option for using such a list for tracker notifications.
>
> I suggest to add a pseudo member to the Zope 2 dev team and configure its
> mail address to some new mailman list on lists.zope.org

That's not needed. Since the zope2-dev team is automatically
subscribed to issues, we only need to set it's contact address. If we
set that address to zope-...@lists.zope.org, then issues will
automatically be delivered to it.

-- 
Sidnei da Silva
Canonical Ltd.
 Landscape · Changing the way you manage your systems
http://landscape.canonical.com
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

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

[Andreas Jung]

On 12.05.09 16:37, Andreas Jung wrote:
> On 12.05.09 15:29, Sidnei da Silva wrote:
>   
>> On Tue, May 12, 2009 at 10:25 AM, 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. 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?)
>>   
>> 
> I *think* there was such a list. LP provides mailinglist support for
> for each group
>
> https://launchpad.net/~zope2-dev
>
> but I see no option for using such a list for tracker notifications.
>
> I suggest to add a pseudo member to the Zope 2 dev team and configure its
> mail address to some new mailman list on lists.zope.org where ppl
> can subscribe/unsubscribe at their own joy and pleasure.
>
> If there are no other options, please vote on my proposal.
>
> Andreas
>
>
>
>   


-- 
ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany
Web: www.zopyx.com - Email: i...@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


begin:vcard
fn:Andreas Jung
n:Jung;Andreas
org:ZOPYX Ltd. & Co. KG
adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany
email;internet:i...@zopyx.com
title:CEO
tel;work:+49-7071-793376
tel;fax:+49-7071-7936840
tel;home:+49-7071-793257
x-mozilla-html:FALSE
url:www.zopyx.com
version:2.1
end:vcard

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

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

[Andreas Jung]

On 12.05.09 16:53, Andreas Jung wrote:
>   
>> 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.
>> 
> Two is not a big pile. We had changes other than bugfixes after beta at
> least in Zope 2.9, 2.10 and you added yourself a feature after 2.12.0b1.
> So let's be pragmatic, not dogmatic.
>   
>> - 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.
>> 
> Every active core developer should be member of Zope 2 dev team:
>
> https://launchpad.net/~zope2-dev
>
> It is up to each developer to join the team - this is not much different
> from
> a mailinglist membership.
>
> Andreas
>
>   


-- 
ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany
Web: www.zopyx.com - Email: i...@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


begin:vcard
fn:Andreas Jung
n:Jung;Andreas
org:ZOPYX Ltd. & Co. KG
adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany
email;internet:i...@zopyx.com
title:CEO
tel;work:+49-7071-793376
tel;fax:+49-7071-7936840
tel;home:+49-7071-793257
x-mozilla-html:FALSE
url:www.zopyx.com
version:2.1
end:vcard

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [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  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  section is for making
>>> additional environment
>>> variables available with Zope. I consider being an "internal"
>>> functionality.
>>>   
>> Well, I consider it less than internal ;-)
>> 
> That 's
>  a
>  matter
>  of
>  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: i...@zopyx.com - Phone +49 - 7071 - 793376
Registergericht

Re: [Zope-dev] [buildbot] zc.buildout (small) failures

[Sebastien Douche]

On Tue, May 12, 2009 at 15:14, Jim Fulton  wrote:
> Please don't spam zope-dev with these. Please just send them to me instead.

Ok, sorry for the spam.


-- 
Sebastien Douche 
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

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

[Chris Withers]

Andreas Jung wrote:
> Every active core developer should be member of Zope 2 dev team:
> 
> https://launchpad.net/~zope2-dev
> 
> It is up to each developer to join the team

It took me ages to figure out how to do this, and I still couldn't tell 
you how to do it now. Launchpad has an *extremely* poor UI here, what 
would be so hard about having a "request to join this team" link 
somewhere prominently on the team page?

It might be good to put an explanation of how to do this on:
http://docs.zope.org/developer/
...once you figure it out.

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

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

[Andreas Jung]

On 12.05.09 16:58, Chris Withers wrote:
> Andreas Jung wrote:
>> Every active core developer should be member of Zope 2 dev team:
>>
>> https://launchpad.net/~zope2-dev
>>
>> It is up to each developer to join the team
>
> It took me ages to figure out how to do this, and I still couldn't
> tell you how to do it now. Launchpad has an *extremely* poor UI here,
> what would be so hard about having a "request to join this team" link
> somewhere prominently on the team page?

Where the hell is the "join" link - I can't find it.
>
> It might be good to put an explanation of how to do this on:
> http://docs.zope.org/developer/
> ...once you figure it out.

Will do - after having the URL for the "Join" link.

Andreas
begin:vcard
fn:Andreas Jung
n:Jung;Andreas
org:ZOPYX Ltd. & Co. KG
adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany
email;internet:i...@zopyx.com
title:CEO
tel;work:+49-7071-793376
tel;fax:+49-7071-7936840
tel;home:+49-7071-793257
x-mozilla-html:FALSE
url:www.zopyx.com
version:2.1
end:vcard

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

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

[Sidnei da Silva]

On Tue, May 12, 2009 at 12:06 PM, Andreas Jung  wrote:
> Will do - after having the URL for the "Join" link.

https://launchpad.net/~zope2-dev/+join

-- 
Sidnei da Silva
Canonical Ltd.
 Landscape · Changing the way you manage your systems
http://landscape.canonical.com
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

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

[Sidnei da Silva]

On Tue, May 12, 2009 at 11:58 AM, Chris Withers  wrote:
> It took me ages to figure out how to do this, and I still couldn't tell
> you how to do it now. Launchpad has an *extremely* poor UI here, what
> would be so hard about having a "request to join this team" link
> somewhere prominently on the team page?

It's visible enough to me right there were it is?

I can understand your complaint though. That page was changed recently
to show more information. You can see from the screenshot on this page
that there used to be a Big Green Button in the page for joining the
team:

https://help.launchpad.net/Teams/Joining

-- 
Sidnei da Silva
Canonical Ltd.
 Landscape · Changing the way you manage your systems
http://landscape.canonical.com
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

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

[Sidnei da Silva]

On Tue, May 12, 2009 at 12:08 PM, Chris Withers  wrote:
> Sidnei da Silva wrote:
>>
>> On Tue, May 12, 2009 at 12:06 PM, Andreas Jung  wrote:
>>>
>>> Will do - after having the URL for the "Join" link.
>>
>> https://launchpad.net/~zope2-dev/+join
>
> And where, exactly, are you supposed to find that?!

Obviously it's not visible anymore once you *are* a member of a team.
For an example of what it looks like when you're not a member of a
team, see this screenshot:

  http://www.ubuntu-pics.de/bild/14102/screenshot_027_8l3CD1.png

To me the link is perfectly clear there, with a green '+' icon and all.

-- 
Sidnei da Silva
Canonical Ltd.
 Landscape · Changing the way you manage your systems
http://landscape.canonical.com
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

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

[Chris Withers]

Sidnei da Silva wrote:
> On Tue, May 12, 2009 at 11:58 AM, Chris Withers  
> wrote:
>> It took me ages to figure out how to do this, and I still couldn't tell
>> you how to do it now. Launchpad has an *extremely* poor UI here, what
>> would be so hard about having a "request to join this team" link
>> somewhere prominently on the team page?
> 
> It's visible enough to me right there were it is?

Huh? I can't tell for zope2-dev as I'm a member, but I see no "big green 
button" here:

https://edge.launchpad.net/~launchpad-dev

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

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

[Sidnei da Silva]

On Tue, May 12, 2009 at 12:12 PM, Chris Withers  wrote:
> Huh? I can't tell for zope2-dev as I'm a member, but I see no "big green
> button" here:
>
> https://edge.launchpad.net/~launchpad-dev

Chris, please slow down and read the *whole* message and also my other
replies. I can't keep up with your speed, and you you're just causing
a lot of extra communication overhead by not reading what I'm writing
and quickly replying with short messages. This is not IRC/IM.

Thanks!

-- 
Sidnei da Silva
Canonical Ltd.
 Landscape · Changing the way you manage your systems
http://landscape.canonical.com
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

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

[Andreas Jung]

On 12.05.09 17:07, Sidnei da Silva wrote:
> On Tue, May 12, 2009 at 12:06 PM, Andreas Jung  wrote:
>   
>> Will do - after having the URL for the "Join" link.
>> 
> https://launchpad.net/~zope2-dev/+join

I added a note to the developers docs (should be online with the
next automatic update of docs.zope.org).

Andreas
begin:vcard
fn:Andreas Jung
n:Jung;Andreas
org:ZOPYX Ltd. & Co. KG
adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany
email;internet:i...@zopyx.com
title:CEO
tel;work:+49-7071-793376
tel;fax:+49-7071-7936840
tel;home:+49-7071-793257
x-mozilla-html:FALSE
url:www.zopyx.com
version:2.1
end:vcard

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] "ZTK" futures: one big package?

[Chris McDonough]

On 5/12/09 4:44 AM, Patrick Gerken wrote:
> Hi,
>
> I agree with the package inflation. It makes people nervous of the
> complexity.
> But putting everything back into a pile of mud sounds like going back
> from where we came, and I this situation makes people even more nervous
> when they want to look into zope.
> As far as I know, the big dependency clean up is not finished yet, no?
> Maybe it might be better to do that first. With a clean dependency
> graph, its easier to see, which set of packages could be merged into one
> package.

I don't think there will ever be a point where it's "finished"; at least not in 
any time frame in which Zope is still relevant at the end.  Sure, we can keep 
the current setuptools distributions and keep pulling apart their respective 
dependencies forever, but by the time it's all over, it just won't matter 
anyway; folks will be happily using "Django 3000" or "Pylons 4", which will 
have 
recreated all the features we teased out.

- C


> About the configurability of all the subpackages, I remember a proposal
> long time ago to reduce the number of zcml directives. This time I am in
> favor of inventing some zcml directives with some care. But before doing
> that, it might be better to write two or free easy tutorials about how
> to write custom zcml directives and grokkers. That would result in
> people writing more custom zcml directives and grokkers and get the hang
> of it. With the a much bigger userbase of writers of custom zcml
> directives and grokkers, the community as a whole will get a much better
> idea of how to use zcml, and I think gaining that community sense first
> will result in some high quality new general usable zcml directives. At
> the moment, and with my limited view, it looks like most zope ppl really
> don't know how to write custom zcml directives.
>
> Just my 0.02€
>
> Best regards,
>
> Patrick
>
>
>
> On Tue, May 12, 2009 at 09:08, Chris McDonough  > wrote:
>
> I realize now that I've neglected to give sufficient reasoning for
> why less
> granular packaging would be a good thing.
>
> I've noticed that there's a common theme in Zope development,
> software, and
> packages that I can only describe as "power law development" or
> "turtles all the
> way down".  It's a bit of an antipattern, unfortunately.
>
> I'll provide an example by way of Zope-3-the-appserver.  In an
> application that
> uses Zope-3-the-appserver, many individual subframeworks will be
> used.  For
> example, there is a traversal subframework, a security subframework, a
> cataloging subframework, and so on.
>
> Each of these subframeworks acts as a logical unit, and through the
> magic of the
> component architecture, each can be replaced wholesale by
> registering some
> adapter.  However, each of these subframeworks tend to also have
> settings that
> can be configured.  For example, individual traversal steps for
> certain types of
> objects can be overridden by registering an adapter that
> *configures* the
> subframework.  In the case of Zope 3, we have a traversal situation
> where the
> larger traversal subframework can either be replaced wholesale via
> an adapter
> registration or extended piecemeal via other adapter registrations.
>
> The problem is that the mechanism to *replace* the subframework is
> the same as
> the mechanism to *configure* it (both are done via adapter registration,
> sometimes even in the same file).  This is theoretically fine.  But
> in reality,
> it's tremendously hard for someone just walking up to a complex
> system like Zope
> 3 to discern adapter registrations that replace subsystems from
> those which
> merely configure subsystems.  An inability to discern the difference
> leads to
> situations where people just "don't get the joke" and try to wiggle
> wires to
> configure-to-death a existing subsystem that's clearly suboptimal
> for their use
> case instead of just replacing it wholesale with a much simpler
> custom policy.
> They just don't know it was engineered to be replaced.  So they keep
> adding more
> configuration code to the existing subframework to handle various 1%
> edge cases.
>   Often this code makes the subframework tremendously complex, and the
> subframework grows inappropriate dependencies along the way.
>   *Sometimes* the
> situation gets so confusing for a new user, they just quit and go
> use something
> else.
>
> This is a pattern that happens over and over again in Zope
> development.  In my
> personal opinion, the original error was trying to make the subframework
> configurable at all.  Instead, the subframework should be
> replaceable easily,
> but it should itself be relatively rigid.  At very least, for
> subframeworks th

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

[Chris Withers]

Sidnei da Silva wrote:
> On Tue, May 12, 2009 at 12:12 PM, Chris Withers  
> wrote:
>> Huh? I can't tell for zope2-dev as I'm a member, but I see no "big green
>> button" here:
>>
>> https://edge.launchpad.net/~launchpad-dev
> 
> Chris, please slow down and read the *whole* message and also my other
> replies. 

I did read the *whole* message...

>I can't keep up with your speed, and you you're just causing
> a lot of extra communication overhead by not reading what I'm writing
> and quickly replying with short messages. 

I'm reading everything you're writing. What do you think I missed?

What you should have said was that there's no join button on 
launchpad-dev because it's a "restricted team", whatever that means.

Are zope2-dev or zope3-dev similarly restricted teams?
If so, how do people find out how to join a restricted team?

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

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

[Sidnei da Silva]

On Tue, May 12, 2009 at 12:25 PM, Chris Withers  wrote:
> I'm reading everything you're writing. What do you think I missed?

You said:

>>> Huh? I can't tell for zope2-dev as I'm a member, but I see no "big green
>>> button" here:

And the original message said:

"""
That page was changed recently
to show more information. You can see from the screenshot on this page
that there used to be a Big Green Button in the page for joining the
team:

https://help.launchpad.net/Teams/Joining
"""

That means you didn't read the whole message, and no matter how much
effort I spend in explaining this to you, if you don't read the whole
message then it's worthless.

> Are zope2-dev or zope3-dev similarly restricted teams?
> If so, how do people find out how to join a restricted team?

See Andreas' reply.

-- 
Sidnei da Silva
Canonical Ltd.
 Landscape · Changing the way you manage your systems
http://landscape.canonical.com
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

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

[Chris Withers]

Sidnei da Silva wrote:
> On Tue, May 12, 2009 at 12:06 PM, Andreas Jung  wrote:
>> Will do - after having the URL for the "Join" link.
> 
> https://launchpad.net/~zope2-dev/+join

And where, exactly, are you supposed to find that?!

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

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

[Andreas Jung]

On 12.05.09 17:25, Chris Withers wrote:

> > Sidnei da Silva wrote:
>   
>> >> On Tue, May 12, 2009 at 12:12 PM, Chris Withers
>> >>  wrote:
>> 
>>> >>> Huh? I can't tell for zope2-dev as I'm a member, but I see no "big
>>> >>> green
>>> >>> button" here:
>>> >>>
>>> >>> https://edge.launchpad.net/~launchpad-dev
>>>   
>> >>
>> >> Chris, please slow down and read the *whole* message and also my other
>> >> replies. 
>> 
> >
> > I did read the *whole* message...
> >
>   
>> >> I can't keep up with your speed, and you you're just causing
>> >> a lot of extra communication overhead by not reading what I'm writing
>> >> and quickly replying with short messages. 
>> 
> >
> > I'm reading everything you're writing. What do you think I missed?
> >
> > What you should have said was that there's no join button on
> > launchpad-dev because it's a "restricted team", whatever that means.
> >
> > Are zope2-dev or zope3-dev similarly restricted teams?
> > If so, how do people find out how to join a restricted team?
> >
>   
LP distinguishes between open, moderated and restricted teams. zope2-dev
is a moderated team.

Andreas



-- 
ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany
Web: www.zopyx.com - Email: i...@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


begin:vcard
fn:Andreas Jung
n:Jung;Andreas
org:ZOPYX Ltd. & Co. KG
adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany
email;internet:i...@zopyx.com
title:CEO
tel;work:+49-7071-793376
tel;fax:+49-7071-7936840
tel;home:+49-7071-793257
x-mozilla-html:FALSE
url:www.zopyx.com
version:2.1
end:vcard

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

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

[Tres Seaver]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andreas Jung wrote:
> 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  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  section is for making
 additional environment
 variables available with Zope. I consider being an "internal"
 functionality.
   
>>> Well, I consider it less than internal ;-)
>>> 
>> That 's
>>  a
>>  matter
>>  of
>>  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 

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

[Chris Withers]

Sidnei da Silva wrote:
> And the original message said:
> 
> """
> That page was changed recently
> to show more information. You can see from the screenshot on this page
> that there used to be a Big Green Button in the page for joining the
> team:
> 
> https://help.launchpad.net/Teams/Joining
> """

Yes, I read this, but since, as you say, launchpad has changed, this 
information is no longer relevant so I didn't reply to it.

>> Are zope2-dev or zope3-dev similarly restricted teams?
>> If so, how do people find out how to join a restricted team?
> 
> See Andreas' reply.

I have and was waiting for you to reply, I was hoping you could explain 
where you'd find a join link for a moderated team...

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

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

[Sidnei da Silva]

On Tue, May 12, 2009 at 12:38 PM, Chris Withers  wrote:
> Sidnei da Silva wrote:
>>
>> And the original message said:
>>
>> """
>> That page was changed recently
>> to show more information. You can see from the screenshot on this page
>> that there used to be a Big Green Button in the page for joining the
>> team:
>>
>> https://help.launchpad.net/Teams/Joining
>> """
>
> Yes, I read this, but since, as you say, launchpad has changed, this
> information is no longer relevant so I didn't reply to it.

/me shrugs.

I was pointing out that there *used* to be a Big Green Button, and it
doesn't exist anymore. You said "I don't see a Big Green Button". Of
course the information is relevant. I was telling you *NOT* to look
for a Big Green Button because it doesn't exist anymore, and, still,
you looked for one.

>>> Are zope2-dev or zope3-dev similarly restricted teams?
>>> If so, how do people find out how to join a restricted team?
>>
>> See Andreas' reply.
>
> I have and was waiting for you to reply, I was hoping you could explain
> where you'd find a join link for a moderated team...

The screenshot I've sent is for a moderated team, gnome-terminator.
The link is visible there and would be in the same location for
someone joining zope-dev.

-- 
Sidnei da Silva
Canonical Ltd.
 Landscape · Changing the way you manage your systems
http://landscape.canonical.com
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

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

[Chris Withers]

Sidnei da Silva wrote:
> Obviously it's not visible anymore once you *are* a member of a team.
> For an example of what it looks like when you're not a member of a
> team, see this screenshot:
> 
>   http://www.ubuntu-pics.de/bild/14102/screenshot_027_8l3CD1.png
> 
> To me the link is perfectly clear there, with a green '+' icon and all.

Hmm, may just have been me then. My membership somehow became 
'deactivated' before and I didn't get the add link but I wasn't getting 
the tracker emails either.

I've left the "Launchpad Beta" group,  so I shouldn't have edge. 
interfering with things anymore...

Chris

-- 
Simplistix - Content Management, Zope & Python Consulting
- http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] "ZTK" futures: one big package?

[Paul Winkler]

On Tue, May 12, 2009 at 03:08:05AM -0400, Chris McDonough wrote:
> Once we deflate our current set of packages down to a reasonable
> number, the packages listed in PyPI will immediately start to
> reflect "the state of reality right now".  As a result, we'll
> hopefully be able to get some new blood in the form of new
> developers that use the smaller bits outside Zope to help us tease
> the truly independent pieces out of the larger pile.  If we do this,
> at no time after the deflation will PyPI listings ever as badly
> advertise "the state of reality" as it is advertised right now, and
> the community will hopefully again start to grow.

I agree with a lot of what you wrote, but I don't understand this last
bit.  All the currently released packages will continue to live on
pypi more or less forever, no?  To paraphrase a wise man, "Releasing a
package means always having to say you're sorry" ;-)


-- 

Paul Winkler
http://www.slinkp.com
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] "ZTK" futures: one big package?

[Chris McDonough]

On 5/12/09 12:27 PM, Paul Winkler wrote:
> On Tue, May 12, 2009 at 03:08:05AM -0400, Chris McDonough wrote:
>> Once we deflate our current set of packages down to a reasonable
>> number, the packages listed in PyPI will immediately start to
>> reflect "the state of reality right now".  As a result, we'll
>> hopefully be able to get some new blood in the form of new
>> developers that use the smaller bits outside Zope to help us tease
>> the truly independent pieces out of the larger pile.  If we do this,
>> at no time after the deflation will PyPI listings ever as badly
>> advertise "the state of reality" as it is advertised right now, and
>> the community will hopefully again start to grow.
>
> I agree with a lot of what you wrote, but I don't understand this last
> bit.  All the currently released packages will continue to live on
> pypi more or less forever, no?  To paraphrase a wise man, "Releasing a
> package means always having to say you're sorry" ;-)

I don't think so.  People would need to change their code to depend on the big 
package, and the smaller packages would cease to have a life of their own. 
Having both the smaller packages and some bigger package that also contains it 
and needing to maintain both truly would be the worst of all possible worlds.

- C
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] "ZTK" futures: one big package?

[Paul Winkler]

On Tue, May 12, 2009 at 12:36:06PM -0400, Chris McDonough wrote:
> On 5/12/09 12:27 PM, Paul Winkler wrote:
>> I agree with a lot of what you wrote, but I don't understand this last
>> bit.  All the currently released packages will continue to live on
>> pypi more or less forever, no?  To paraphrase a wise man, "Releasing a
>> package means always having to say you're sorry" ;-)
>
> I don't think so.  People would need to change their code to depend on 
> the big package, and the smaller packages would cease to have a life of 
> their own. Having both the smaller packages and some bigger package that 
> also contains it and needing to maintain both truly would be the worst of 
> all possible worlds.

I must be dense today because I still don't understand what "cease to
have a life" means. Remove them from pypi?  How would you avoid
breaking all the current software in the world that currently depends
on all those distributions?

-- 

Paul Winkler
http://www.slinkp.com
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )

Re: [Zope-dev] "ZTK" futures: one big package?

[Chris McDonough]

On 5/12/09 12:46 PM, Paul Winkler wrote:
> On Tue, May 12, 2009 at 12:36:06PM -0400, Chris McDonough wrote:
>> On 5/12/09 12:27 PM, Paul Winkler wrote:
>>> I agree with a lot of what you wrote, but I don't understand this last
>>> bit.  All the currently released packages will continue to live on
>>> pypi more or less forever, no?  To paraphrase a wise man, "Releasing a
>>> package means always having to say you're sorry" ;-)
>> I don't think so.  People would need to change their code to depend on
>> the big package, and the smaller packages would cease to have a life of
>> their own. Having both the smaller packages and some bigger package that
>> also contains it and needing to maintain both truly would be the worst of
>> all possible worlds.
>
> I must be dense today because I still don't understand what "cease to
> have a life" means. Remove them from pypi?  How would you avoid
> breaking all the current software in the world that currently depends
> on all those distributions?
>

If your package depends on zope.app.publisher, you get *78* eggs.  Change that 
install_requires line in your package to "ZTK" and you get the same software. 
OTOH, packages that rely on things that are *truly reusable* like 
zope.interface, and so on will need to do nothing; those packages will continue 
to have a life of their own.

- C

___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )