-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Both you (i.e. your earlier you) and Antoine are somewhat correct. The mailbox module *is* broken, and such large patches *shouldn't* go in during rc phase.
However, I don't think people are "playing games" with the release process. No core developer has any profit from delaying patches for as long as possible, and we have to remember this is all volunteer work. Nobody is liable for bugs in the mailbox module and can be fired because these problems were discovered or handled too late in the process.
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.
Am 29.01.2011 02:05, schrieb Steve Holden:
Antoine is quite correct. The strict process would be to include a note it the NEWS file pointing out that this deficiency was found too late for the necessary fixes to be applied in a controlled manner.
I was not thinking straight: I remember arguing in the past that multiprocessing should be excluded from its first release because it was being introduced too late in the cycle, and the ensuing work when it was indeed prematurely included (from my PoV; and I do not negate the significant benefits its existence has since provided).
If a note is required for the NEWS file I would be happy to author it if nobody else has time. We can perhaps provide a patch in the sandbox for anyone who is curious about the kinds of problems that can be raised by Unicode issues and some of the progress that has been made towards solving them. The same may be true of David's other partially-funded work on the email package.
It's also clear that the next release would benefit from David and/or other developers being able to spend more time on these issues. If any reader is able to help the PSF find sponsorship to fund this or other developments please write to the board, or to me directly.
On Jan 28, 2011, at 6:00 PM, Antoine Pitrou wrote:
While I agree the mailbox module is basically useless right now, the fact that we are using the rc phase for common bug fixing means the rc phase has become useless too. That may become a quality problem in the middle term. On the other hand, if the RM refused all non-trivial patches during the rc phase, that would force people to stop playing games with the release process. The mailbox module's brokenness was, after all, known for quite some time.
Le vendredi 28 janvier 2011 à 14:51 -0800, Raymond Hettinger a écrit :
On Jan 28, 2011, at 12:35 PM, Steve Holden wrote:
As teh reporter of that bug I should like to say in Victor's, Antoine's and David's support that the module is so broken without this patch that the module should not really have been included in a production release.
Even if the current patch is broken, I believe the results of using that code would be less negative than the results of using the module from the previous release.