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
> cycle. 

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
> point. 

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  -

Reply via email to