Tim Peters wrote: > That's what he said -- and you made him repeat it several times by now.
Yes, I find it hard to believe that someone would deliberately break something that someone else has taken the trouble to fix (and run the tests for!)... >> 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. I'm not arguing with the above, and I'm not asking for anything more supported than already exists. However, requiring someone to completely rewrite a test suite for software that they're never needed to understand on the basis that they corrected some imports to make them compatible with a newer version of python seems unreasonable. > So the right lessons are: (1) to do development on a development > branch; Where is the development process that requires this documented? > 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. I'm fine with the status quo... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk _______________________________________________ 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