... [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. _______________________________________________ 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 )
