[Python-Dev] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS (original) (raw)
Georg Brandl g.brandl at gmx.net
Thu Apr 13 18:28:20 CEST 2006
- Previous message: [Python-Dev] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
- Next message: [Python-Dev] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Tim Peters wrote:
[Georg Brandl]
Well, it's tempting to let the buildbots run the tests for you 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 ;-)
No objection, mylord ;)
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.
Until now, I've always run with -uall. Running "make quicktest" is fine, but if the buildbots starts failing with -uall afterwards, no one will accept that as an excuse ;)
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.
I see, and I'm sorry I was part of it.
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.
For excuse, I posted here immediately after I saw that the tests failed, asking whether to change doctest or revert my change.
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.
Fine. There's another one, python.org/sf/1326077, which looks suspicious to me too.
Georg
- Previous message: [Python-Dev] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
- Next message: [Python-Dev] [Python-checkins] r45321 - in python/trunk: Lib/test/test_traceback.py Lib/traceback.py Misc/NEWS
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]