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 _______________________________________________ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
