On 2/26/13 7:26 PM, Hanno Schlichting wrote:
> Our rule for inclusion in the ZTK is: Whatever library is used by at
> least two out of the three frameworks (BlueBream, Grok, Zope).
> Given that BlueBream hasn't seen any release beyond a 1.0 about two
> years back, I'm not sure it's active or relevant anymore. Grok isn't
> seeing frequent releases, but there was a 1.5.5 mid last year.
> If you compare the version list from the last ZTK 1.1.5
> and Grok 1.5.5 (http://grok.zope.org/releaseinfo/1.5.5/versions.cfg),
> you'll notice that Grok already overwrites the version requirement for
> half of the non-deprecated packages with its own versions. And as I
> said, Zope isn't using any of them anymore for a long time.
> So I don't see any value in testing and promising stability for those
> zope.app packages, when there aren't any shared consumers for the
> specific versions.
> And the actually used versions by Grok are:
> zope.app.applicationcontrol, zope.app.appsetup, zope.app.debug -
> renaming those to a non zope.app prefix doesn't make a lot of sense
> for me either - as they are all about a specific app server
> configuration and not generally reusable libraries.
Agreed, from a Grok perspective: if there is no shared interested
anymore in the zope.app.* packages, Grok will need to take up
maintainership for those itself. In a way we already did by upping the
versions of several of those package already.
The zope.app.* packages that really are in use for a vanilla Grok-based
application are zope.app.applicationcontrol, zope.app.appsetup and
zope.app.debug and zope.app.wsgi.
If there would be a strong drive from the Grok community to have Python
3 compatibility, they (and that includes me :) ) should port those
zope.app.* packages or build the equivalents.
I'll make note of this on the Grok dev list as well.
Zope-Dev maillist - Zope-Dev@zope.org
** No cross posts or HTML encoding! **
(Related lists -