> If OS X is a supported and important platform for Python then fixing all > problems that it reveals (or being willing to) should definitely not be > a pre-requisite of providing a buildbot (which is already a service to > the Python developer community). Fixing bugs / failures revealed by > Bill's buildbot is not fixing them "for Bill" it is fixing them for Python. I wish people would stop using the word "supported" when they talk about free software. *No* system is "supported" by Python - not even in the sense "we strive to pass the test suite". "We" don't. Now, one may argue whether failing buildbots should be an unconditional reason to defer the release. I personally would say "no", despite what some PEP may say. People proposing that a release is postponed typically hope that somebody gets frustrated enough to step up and fix the bug, just so that the software gets released. Instead, I would propose that the only way to delay a release is by proposing to take some specific action to remedy the situation that should cause the delay. Otherwise, releasing is at the discretion of the release manager, who has the ultimate say to whether the problem is important or not. As for OSX, it seems that the only test that is failing is the ctypes test suite, and there only a single test. I don't think this is sufficient reason to block the release. Regards, Martin
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