[Jim Fulton]
>> I need to review the changes before the release. I'll probably reject the
>> repozo change without an automated test.
[Chris Withers]\
> 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
testrepozo.py:
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
time.
Alas, 5 1/2 years later, repozo testing apparently remains just barely
"Better Than Nothing", but that's really not good enough for a
supported approach.
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
ocean.
If nobody is interested in doing that work, fine by me ;-)
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zodb-dev
