> Oops, lost a bit too much context when I changed the thread title. > > This discussion started with Barry looking for a "smoke test" that > would be quick enough to run that more people would be willing to use > it to pick up gratuitous breakage due to a bad merge rather than > leaving it for the buildbots to discover. Then many people will start running the "smoke test" rather than the whole suite, which will create new kinds of problems. It's IMO a bad idea. Let Barry learn about "-j" :) > Currently even "make quicktest" takes too long to run to be suitable > for that task. Leaving out a couple more egregiously slow tests and > possibly updating it to use the "-j" switch might make for a usable > option. "-j" will precisely help cover the duration of these long tests. By the way, you should use a higher "-j" number than you have CPUs, since some tests spend most of their time sleeping and waiting. "make quicktest" already skips test_io and test_socket, which test fundamental parts of Python. I would vote for removing "make quicktest" rather than promote such a questionable command. Regards Antoine.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4