Hi guys,
this is just a heads-up that I'll be freezing py3k for the rc2 release in a bit less than 48 hours -- Sunday morning in CET.
Please get all changes that you already know are necessary reviewed and committed *before* that: the goal is zero commits between rc2 and final (although I know it's unlikely to be reached) -- or rather the necessity of an rc3 depends on how stable rc2 proves to be.
cheers, Georg
Hi,
Le vendredi 28 janvier 2011 à 12:06 +0100, Georg Brandl a écrit :
this is just a heads-up that I'll be freezing py3k for the rc2 release in a bit less than 48 hours -- Sunday morning in CET.
Please get all changes that you already know are necessary reviewed and committed *before* that: the goal is zero commits between rc2 and final (although I know it's unlikely to be reached) -- or rather the necessity of an rc3 depends on how stable rc2 proves to be.
What about the mailbox module? R. David Murray, Antoine Pitrou, I (and others) worked on a patch to fix this module (which is "partially broken" in Python 3).
http://bugs.python.org/issue9124
It's an huge patch, and it's already the 3rd version. Is it too late for such change?
Victor
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.
regards Steve
On Jan 28, 2011, at 3:27 PM, Victor Stinner wrote:
Hi,
Le vendredi 28 janvier 2011 à 12:06 +0100, Georg Brandl a écrit :
this is just a heads-up that I'll be freezing py3k for the rc2 release in a bit less than 48 hours -- Sunday morning in CET.
Please get all changes that you already know are necessary reviewed and committed *before* that: the goal is zero commits between rc2 and final (although I know it's unlikely to be reached) -- or rather the necessity of an rc3 depends on how stable rc2 proves to be.
What about the mailbox module? R. David Murray, Antoine Pitrou, I (and others) worked on a patch to fix this module (which is "partially broken" in Python 3).
http://bugs.python.org/issue9124
It's an huge patch, and it's already the 3rd version. Is it too late for such change?
Victor
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
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
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
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
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
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
On Fri, 28 Jan 2011 20:05:30 -0500, Steve Holden steve@holdenweb.com wrote:
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 think a warning in the documentation for the module would also be required (and in 3.1 as well).
body 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
Well, the patch is in the tracker.
solving them. The same may be true of David's other partially-funded work on the email package.
I have ideas about that, but I'm waiting until after the release of 3.2 to put them forward.
I am OK with the patch going in, and OK with it not going in. I don't think it is quite parallel to Multiprocessing, though: it is a much smaller codebase, with good test coverage, and the fix itself, although non-trivial, is at its base simple (replace the ASCII-string-only calls to email by bytes-capable calls to email, and allow those bytes in and out via extensions to the appropriate APIs). In addition, the module is already *in* 3.2, it just doesn't work.
I agree with Antoine that the RC phase is not the right place to be doing this. However, it is rather disheartening to think that we need to wait for 3.3 to have this working, whereas if we put the patch in but there turn out to be edge case bugs, we can fix those bugs in 3.2.1...
If the module weren't already broken for most real-world purposes I'd no question want to wait. As it is I'm on the fence.
-- R. David Murray www.bitdance.com
On Jan 29, 2011, at 12:04 AM, R. David Murray wrote:
If the module weren't already broken for most real-world purposes I'd no question want to wait. As it is I'm on the fence.
Me too, but I did want to acknowledge the correctness of Antoine's argument. Yes, I reminded people (using multiprocessing as an example, which I agree was probably not a fair parallel) that ignoring process can have negative consequences, but I do agree with you about the desirability of not having to wait for 3.3.
Who'd be a release manager?
regards Steve
W dniu 2011-01-29 06:15, Steve Holden pisze:
If the module weren't already broken for most real-world purposes I'd no question want to wait. As it is I'm on the fence. Me too, but I did want to acknowledge the correctness of Antoine's argument. Yes, I reminded people (using multiprocessing as an example, which I agree was probably not a fair parallel) that ignoring process can have negative consequences, but I do agree with you about the desirability of not having to wait for 3.3.
Gentlemen. It was disappointing to see serious ideas about pushing feature commits after the beta (and even during the RC phase) or sneaking in controversial changes in respect to the moratorium. All these risky suggestions came from the fact that we are afraid to miss a release and be forced to wait another year or two. Maybe let's eat the cake and have it too. We could do that by shortening the release cycle from now on. How about that?
PS. Please, let's release 3.2 as it is.
Best regards, Łukasz Langa
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 29.01.2011 11:16, schrieb Łukasz Langa:
W dniu 2011-01-29 06:15, Steve Holden pisze:
If the module weren't already broken for most real-world purposes I'd no question want to wait. As it is I'm on the fence. Me too, but I did want to acknowledge the correctness of Antoine's argument. Yes, I reminded people (using multiprocessing as an example, which I agree was probably not a fair parallel) that ignoring process can have negative consequences, but I do agree with you about the desirability of not having to wait for 3.3.
Gentlemen. It was disappointing to see serious ideas about pushing feature commits after the beta (and even during the RC phase) or sneaking in controversial changes in respect to the moratorium. All these risky suggestions came from the fact that we are afraid to miss a release and be forced to wait another year or two. Maybe let's eat the cake and have it too. We could do that by shortening the release cycle from now on. How about that?
Sure -- I take it you're volunteering to be RM?
Georg -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1D6ywACgkQN9GcIYhpnLCaXgCePUa00PitA9Tr0s5Vm1h8ZS+g fzEAn3STkH1evzytNuw7fZR7+F+bkAS+ =3hsV -----END PGP SIGNATURE-----
W dniu 2011-01-29 11:25, Georg Brandl pisze:
Gentlemen. It was disappointing to see serious ideas about pushing feature commits after the beta (and even during the RC phase) or sneaking in controversial changes in respect to the moratorium. All these risky suggestions came from the fact that we are afraid to miss a release and be forced to wait another year or two. Maybe let's eat the cake and have it too. We could do that by shortening the release cycle from now on. How about that? Sure -- I take it you're volunteering to be RM?
That goes without saying. I wouldn't mind doing all the work. :-)
Best regards, Łukasz
Le samedi 29 janvier 2011 à 11:16 +0100, Łukasz Langa a écrit :
W dniu 2011-01-29 06:15, Steve Holden pisze:
If the module weren't already broken for most real-world purposes I'd no question want to wait. As it is I'm on the fence. Me too, but I did want to acknowledge the correctness of Antoine's argument. Yes, I reminded people (using multiprocessing as an example, which I agree was probably not a fair parallel) that ignoring process can have negative consequences, but I do agree with you about the desirability of not having to wait for 3.3.
Gentlemen. It was disappointing to see serious ideas about pushing feature commits after the beta (and even during the RC phase) or sneaking in controversial changes in respect to the moratorium. All these risky suggestions came from the fact that we are afraid to miss a release and be forced to wait another year or two.
Of course, this is all solved if people actually take the planning into account instead of ignoring it :)
cheers
Antoine.
2011/1/29 Łukasz Langa lukasz@langa.pl:
We could do that by shortening the release cycle from now on. How about that?
The long-term fix is actually the ongoing effort to split the standard library off from the core language implementation. A faster release cycle is reasonably appropriate for the former, but highly inappropriate for the latter.
PS. Please, let's release 3.2 as it is.
Agreed.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
2011/1/29 Nick Coghlan ncoghlan@gmail.com:
2011/1/29 Łukasz Langa lukasz@langa.pl:
PS. Please, let's release 3.2 as it is.
Agreed.
Although I can accept Georg's reasoning on the topic as well.
Regards, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Dnia 29-01-2011 o godz. 14:00 Nick Coghlan ncoghlan@gmail.com napisał(a):
2011/1/29 Nick Coghlan ncoghlan@gmail.com:
2011/1/29 Łukasz Langa lukasz@langa.pl:
PS. Please, let's release 3.2 as it is.
Agreed.
Although I can accept Georg's reasoning on the topic as well.
Me too. Practicality beats purity once again:-)
-- Łukasz
Steve Holden wrote:
On Jan 29, 2011, at 12:04 AM, R. David Murray wrote:
If the module weren't already broken for most real-world purposes I'd no question want to wait. As it is I'm on the fence.
Why not add a deprecation warning to the module and point users to a version on PyPI which you can then develop independently of the current Python release cycle ?!
Adding a new module during an RC release is a no-go. We'd then have to go back to beta again.
-- Marc-Andre
-----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-----
Georg Brandl
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
Le samedi 29 janvier 2011 à 12:24 +0000, Vinay Sajip a écrit :
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?
Okay, I don't mind if mailbox gets "fixed", but -1 on making the release schedule any longer because of that. OTOH, if mailbox *needs* a lengthening of the release schedule, then it's 3.3 material (or 3.2.1, depending on the other RM's view :-)).
Regards
Antoine.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 29.01.2011 13:52, schrieb Antoine Pitrou:
Le samedi 29 janvier 2011 à 12:24 +0000, Vinay Sajip a écrit :
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?
Okay, I don't mind if mailbox gets "fixed", but -1 on making the release schedule any longer because of that. OTOH, if mailbox *needs* a lengthening of the release schedule, then it's 3.3 material (or 3.2.1, depending on the other RM's view :-)).
Not if it's a few days, otherwise I'd agree.
Georg -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1EI+8ACgkQN9GcIYhpnLCpqACglNZB0ZKLbif+7ruxqIRJn/63 nQkAn1wW5dm3EDNKqbrGXxbBE2w998rO =Rqgw -----END PGP SIGNATURE-----
On Jan 29, 2011, at 11:22 AM, Georg Brandl wrote:
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.
I completely agree. We have precedence for delaying final releases to fix known issues with existing fixes. If we had an established release cadence the it would be a different matter, but as it is, we release when it's ready. If I were RM, I'd make the same decision.
-Barry
On Jan 29, 2011, at 7:56 AM, Barry Warsaw wrote:
On Jan 29, 2011, at 11:22 AM, Georg Brandl wrote:
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.
I completely agree. We have precedence for delaying final releases to fix known issues with existing fixes. If we had an established release cadence the it would be a different matter, but as it is, we release when it's ready. If I were RM, I'd make the same decision.
The current RM and a former RM have spoken.
Please give them your support instead of second-guessing them.
Raymond
P.S. Even though it's late in the release cycle, I think we should be thrilled at the quality and intensity of efforts to fixup mailbox and the OS X issues. If these guys (Ned, Ronald, David, Steffen, Antoine, and Victor) had not poured in effort, these issues may have lingered for long time.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Am 29.01.2011 20:55, schrieb Raymond Hettinger:
P.S. Even though it's late in the release cycle, I think we should be thrilled at the quality and intensity of efforts to fixup mailbox and the OS X issues. If these guys (Ned, Ronald, David, Steffen, Antoine, and Victor) had not poured in effort, these issues may have lingered for long time.
Indeed, big cheers to all the volunteers who make it so pleasant to be the RM :)
Georg -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk1EhLsACgkQN9GcIYhpnLDMJACdGqrYvpSSK5Tu/pK3T0VCIrUj DRIAnjYEwUJTC4gwGMPpOMB8I6uax5f3 =X7xk -----END PGP SIGNATURE-----
participants (12)
-
Antoine Pitrou -
Barry Warsaw -
Georg Brandl -
Georg Brandl -
M.-A. Lemburg -
Nick Coghlan -
R. David Murray -
Raymond Hettinger -
Steve Holden -
Victor Stinner -
Vinay Sajip -
Łukasz Langa