Hi there,

Paul Everitt wrote:
> Hopefully the Zope Framework proposal helps untangle this, and gets to a 
> point where you don't have to keep the Uberthing in your head when doing 
> something small.

It's not small, as it has an impact on a lot of things that build on 
zope.component. Changing things low in something that lots of people 
have built stacks on is almost never a small change.

Just look at Python 3, which makes a bunch of actually rather small but 
still incompatible changes to the language. While small from the 
perspective of the language, they're *huge* from the perspective of the 

So you need ways to coordinate such changes.

I hope that having someone actually taking responsibility for 
zope.component's evolution can get the zope.security dependency out of 
it, and then improvements of repoze.zcml into it, or alternatively move 
the ZCML implementations *entirely* out of zope.component. I hope Chris 
will coordinate with us where necessary.

I don't want security bits to sit around in zope.component either. 
grokcore.component doesn't need that code, just like repoze.zcml doesn't 
need that code. It's still there, even if you use repoze.zcml, just 
inactive. I tried to propose various ways forward. I got nowhere as I 
got 10 people giving 10 answers. Original problem unresolved.

I'd like there to be someone who can make this decision and I'd like 
this someone to usually make *positive* decisions that work towards 
resolving the underlying issue, while coordinating with everybody that 
is impacted by this decision.

The zope.component ZCML case was very much in my head as I wrote this 



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

Reply via email to