To construct a Zope skyscraper on Fedora

[Robin 'cheese' Lee]

On 06/20/2010 12:45 PM, Nathaniel McCallum wrote:
> On 06/20/2010 12:22 AM, 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] http://plone.org/documentation/faq/plone-versions
>> [2] http://fedoraproject.org/wiki/SIGs/Zope
>>      
> I agree, we've got lots to talk about.  The most important things are:
> 1. Packaging guidelines
> 2. Component upgrade guidelines
> 3. Namespace issues (addressed above)
> 4. Zope 2 vs Zope 3 (again, addressed above)
>    
Zope 3 seems no more going, and a new project named BlueBream[1][2] 
replacing it is being developed.

There are also other blueprint-like and amazing projects[3][4] being 
worked on in the Zope world.

But after all, the most productive and widely used is still Zope 2 which 
should gets higher priority.

[1] http://en.wikipedia.org/wiki/BlueBream
[2] https://launchpad.net/bluebream
[2] http://codespeak.net/z3/five/
[3] http://repoze.org/

> I think we should talk sooner rather than later.  Anyone want to setup a
> meeting time?
>
> Just an FYI, it is my current plan (probably because I am completely
> ignorant as to how much pain this will cause) is to simply package the
> latest version of all Zenoss dependencies and then work through whatever
> bugs I find.  I'm in a somewhat unique situation though in that I have
> the ability to commit to upstream.  This may be a less than ideal plan
> for other applications.
>
> As I mentioned to Jonathan on IRC, I think the best plan is to try to
> get something working'ish as soon as possible and then try to shakedown
> the details from there.  If we bog ourselves down in policy (an easy
> quagmire to get stuck in when in zopeland) we may get too discouraged to
> continue.  Not to dismiss what will be the very needed policy, I just
> want to make sure no-one gets burned out.
>    
I agree with this. And so I packaged a working Zope2 before speaking 
anything publicly.
> One thing we may want to consider is a "tenant" policy.  That is, the
> zope stack as a whole has "tenants" (Zenoss, Plone, etc).  The tenants
> would be formally defined and any upgrade to any component in the
> platform would require signoff from all the tenants who depend on that
> component (or some derivation thereof).  I suspect that the short-term
> trade-off of buildouts/bundling is not as valuable as the long-term
> value of testing a software product across multiple versions of its
> dependencies.
>
> Nathaniel
>