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


Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk
For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to