Hi there, Tres Seaver wrote: [snip] > It is a nightmare, but not one which a KGS can really fix: sometimes > your project needs its *own* KGS.
Sure, that's fine. Grok has its own KGS. And we want reuse. Grok reuses Zope 3's KGS as it doesn't want to do all the research itself and only diverges minimally from the Zope 3 KGS. Grok would prefer to be able to reuse a Zope Framework KGS though as that wouldn't include the ZMI. > Honestly, the only safe thing for > anybody trying to support a large application in production is to run > their own index, and do the gatekeeping of packages into it themselves. There are other distribution methods for application than maintaining indexes; you could do a source release for instance. Software developers have slightly different use cases than a released application does, after all. That said, of course the Zope Framework could provide tools and guidelines that help with such matters. > For instance: [examples the document mostly covers] > Given the likelihood that a monolithic Zope 3.5 release is not > interesting to lots of the folks who both develop and consume its > packages, how much coordination is going to be possible (or even useful) > around the idea of another release? We need a Zope Framework 3.5 release more than a Zope 3.5 release. The Zope Framework doesn't contain the ZMI. It'd be nice if we could discuss ideas that aren't already covered in the document I wrote :) Regards, Martijn _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )