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 > -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
