Hi there,

Tres Seaver wrote:
> 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 :)



Zope-Dev maillist  -  Zope-Dev@zope.org
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope )

Reply via email to