[python-committers] rc2 freeze due in two days

[Georg Brandl]

-----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.

cheers,
Georg

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.
> 
> regards Steve
> 
> 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.
>> 
>> Regards
>> 
>> Antoine.
>> 
>> 
>> 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.
>>> 
>>> 
>>> +1
>>> 
>>> 
>>> Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.17 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk1D6lkACgkQN9GcIYhpnLB/dgCgkNAnf+pg9qumqXR/X9AjvgdO
dT4AoKqKcn0wurO6YhB6QqDzmRFaip19
=thhT
-----END PGP SIGNATURE-----