[Python-Dev] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS

[Tim Peters]

[Georg Brandl]
> Well, it's tempting to let the buildbots run the tests for you <wink>
> Honestly, I didn't realize that doctest relies on traceback. Running
> the test suite takes over half an hour on this box, so I decided to
> take a chance.

Nobody ever expects that a checkin will break tests, so merely
expecting that a checkin won't break tests is not sufficient reason to
skip running tests.  You made a checkin that broke every buildbot
slave we have, and I suggest you're taking a wrong lesson from that
;-)

Do release-build tests without -uall take over half an hour on your
box?  Running that much is "good enough" precaution.  Even (on boxes
with makefiles) running "make quicktest" is mounds better than doing
no testing.  All the cases of massive buildbot test breakage we've
seen this week would have been caught by doing just that much before
checkin.

When previously-passing buildbots start failing, it at least stops me
cold, and (I hope) stops others too.  Sometimes it's unavoidable.  For
example, I spent almost all my Python time Monday repairing a variety
of new test failures unique to the OpenBSD buildbot (that platform is
apparently unique in assigning addresses with "the sign bit" set,
which broke all sorts of tests after someone changed id() to always
return a positive value).  That's fine -- it happens.  It's the
seemingly routine practice this week of checking in changes that break
the tests everywhere that destroys productivity without good cause.

Relatedly, if someone makes a checkin and sees that it breaks lots of
buildbot runs, they should revert the patch themself instead of
waiting for someone else to get so frustrated that they do it. 
Reverting is very easy with svn, but people are reluctant to revert
someone else's checkin.  The buildbot system is useless so long as the
tests fail, and having the tests pass isn't optional.

> ...
> I'm not the one to decide, but at some time the traceback module should be
> rewritten to match the interpreter behavior.

No argument from me about that.