To construct a Zope skyscraper on Fedora

Robin 'cheese' Lee cheeseli at
Mon Jun 21 07:47:35 UTC 2010

Write access to the yum[1] and git[2] repos has been granted to Zope SIG 

     ( )
[2] git://
     ( I have cloned out this new git and removed unrelated packages. )

On 06/20/2010 12:22 PM, Jonathan Steffan wrote:
> On Fri, 2010-06-18 at 21:08 +0800, Robin 'cheese' Lee wrote:
>> The 'zope' package itself is most kept under the same conventions of the
>> legacy 2.10.x 'zope' package.
> We have a unique opportunity to address many of the failings of the
> current zope namespace. We should get anyone interested (and willing to
> do the work) into a meeting soon. Every time I go back to building up
> zope again I run out of steam and end up just being frustrated. I
> foresee issues with splitting out every module in this stack but it just
> needs to be discussed. The current package layout is far from optimal
> and it's not the best idea to ship a default standalone instance with
> the package. Shipping standalone/zeo instance configs/etc. in
> subpackages is a far better idea. I've never been able to address this
> as there is just about no upgrade path (that I've been able to design)
> that would allow for a safe re-layout of the current package.
> We should consider the current "zope" namespace dead and start from
> scratch. It's far too complex of an application to be able to have
> everything in one namespace (speaking to zope2 vs zope3.) I've only
> briefly looked into all of the specs you've worked on and already can
> see we are going to run into issues with cross-product dependencies. I
> could be convinced that the "zope" namespace should be the latest 2.x
> and then address the need for zope 3 in the zope3 namespace. However,
> how do we distinguish a module built for zope 2 vs zope 3? This, again,
> could be solved but will need discussion.
> With zope 2.12 supporting py2.6, I think we might actually have a shot
> at making this work. However, immediately off the bat if we stick 2.12.x
> into "zope" what happens to grok? What packages are going to break? Too
> many things need zope 2.x so updating the "zope" namespace to zope 3
> would break a lot of good software. What happens to plone? Do we just
> ditch Plone 3 and only support Plone 4?[2]
> We could also modularize everything and have things like "zope",
> "plone", "grok" and "zenoss" have dependencies based on their release
> recipes. There are a lot of common modules in these projects, but they
> all have their own specific version requirements. This would be a lot of
> work and could potentially cause us to package ourselves into a corner
> where we are having to do absolute requires or just end up with broken
> software when absolute requirements are not properly documented.
> I really look forward to others being involved with this. Count me in
> for the SIG.[2]
> - Jonathan Steffan
> [1]
> [2]

More information about the devel mailing list