[Zope-dev] Re: [Zope3-dev] December release post-mortem

[Tim Peters]

...

[Stephan Ricther]
>> I have seen you take a similar approach to zope.testing and I found that
>> painful just by watching the checkins.

[Jim Fulton]
> I don't understand what you mean.  Having a separate zope.testing project has
> been extremely useful.  For example, in our comercial apps,
> we often used newer versions than existed in Zope 3.  We often needed
> enhacements to zope.testing at times that Zope 3 was feature frozen.
> We could have made a Zope 3 branch just to modify zope.testing, but that
> would have been a hassle for us and for Zope 3 developers.  Note that
> the new test runner (from zope.testing) was used in ZODB long before it
> was used in Zope 3.

I want to note that this was good for Zope3, too:  as a willing "early
adopter" of zope.testing, ZODB hit bugs and platform-dependent
glitches first, and got them fixed before the larger Zope3 development
community could be bit by them.

Also want to note that ZRS needed to add "new features" to
zope.testing, and ZRS doesn't include _any_ Zope code (ZRS builds on
ZEO, not Zope).  Having zope.testing be its own project without all
the adminstrative overheads of having its own "official releases" made
it very easy to add new code for ZRS's benefit without disturbing any
of zope.testing's other users.

In all, zope.testing is a poster child for the value of package
development outside of a Zope tree.  It's true that, to make changes
in zope.testing, I needed to have a distinct checkout of zope.testing.
 I didn't feel that to be a burden, though.