On 06/20/2010 05:42 AM, Robin 'cheese' Lee wrote: > 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 suspect BlueBream solves our namespace issue; namely, the zope namespace will be zope2 only. Nathaniel -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
