Jeff Shell wrote:
> For what it's worth, I've dealt with broken / unloved /
> mildly-out-of-date ZODB scripts by making a new package that my
> little company uses internally.
I don't agree with this because it's fragmenting a tiny development
group even further, no to mention creating private forks of tools that
mean everyone loses in terms of eyeballing...
> It allowed me to get some useful
> tools available again,
Such as? And what stopped you working on them back in the ZODB source tree?
> and was independent from any ZODB release
I have no problems with the ZODB release cycle...
> You could always explore this option, and even do it better than me
> by sharing with the community.
This just feels wrong to me. If I *was* changing a script's behaviour
such that it needed new tests, I'd make sure those were automatically
run. The changes to repozo didn't require any new tests, the bug was
provoked just by running the existing tests with python 2.6.
> So if 'repozo' needs love, even if it's simple love, I would
> recommend that someone make a 'z3c.zodbtools' or 'z3c.repozo' or
> 'z3c.fsbackup' project.
I couldn't agree less. This kind of fragmentation helps no-one. It's
something I'd only consider as a last resort, and then the most likely
action is just to roll my own sdist with a funky version number and
stick it on the customer's index server.
> Hell, I'll look at the package I've made and
> see if I can do something along those lines as a starting/example
I'd much prefer to see your fixes worked back into the 3.9 branch and
trunk of ZODB...
Simplistix - Content Management, Batch Processing & Python Consulting
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org