[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

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

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

Reply via email to