Georg Brandl <georg <at> python.org> writes:
About quality: It is a big fail to do a release and include a note "but hey, this module does not work, because our developers did not commit a working patch soon enough" (of course you would omit the second part, but you would probably include a link to the bug report which says the same). If that isn't a quality problem, I don't know what is.
If the module is broken and we even have a patch, written by the current expert on the subject, why don't we take the time to review and include it, even if it means that rc2 or the final is delayed a bit? It's not like anyone is standing behind me with a gun, demanding the release of 3.2. As you all know, a large part of the community is lukewarm about Python 3; releasing minor versions with whole modules known to be broken is not going to improve this.
So my "pronouncement" here is: if reviewed properly, the patch will go in 3.2rc2. If this needs a few more days, so be it. And should the testing after 3.2rc2 reveal deficiencies, we will fix them and put in another rc.
When we say "release candidate", surely that implies no known serious brokenness. Even if we have to go back to calling it beta (Marc-Andre's point), surely there's no harm in that, as long as it's made clear that it wouldn't be a free-for-all for other patches to go in?