>> I need to review the changes before the release. I'll probably reject the
>> repozo change without an automated test.
> Are you serious? You'd rather have a broken tool than one that isn't
> broken on the basis that the existing tests aren't part of the test
> suite that gets run by default?!
That's what he said -- and you made him repeat it several times by now.
>> In the future, please don't check changes directly into trunk or a
>> release branch.
>> Check them into a development branch. I'll review and merge.
> Sure, although these are both miniscule changes...
> I've learned my lesson, I won't try and contribute to ZODB development
> in future...
I think that's the wrong lesson to take. repozo had several fatal
bugs when I inherited it, and part of the reason is that there were no
tests of any kind. As the checkin comment said when I added
Better Than Nothing -- which is what we had before.
There wasn't time then to finish the job (i.e., to automate the
testing and dope out some way to make failure output more /helpful/
than just "guts don't match"). What I checked in then was essential,
though, to verify the slew of bugfixes that went in around the same
Alas, 5 1/2 years later, repozo testing apparently remains just barely
"Better Than Nothing", but that's really not good enough for a
So the right lessons are: (1) to do development on a development
branch; and, (2) to finish the job I started if repozo is to be
treated as more than just another random piece of flotsam in the ZODB
If nobody is interested in doing that work, fine by me ;-)
For more information about ZODB, see the ZODB Wiki:
ZODB-Dev mailing list - ZODB-Dev@zope.org