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.
+1.
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?
Regards,
Vinay Sajip