Hello,
A data corruption issue has been discovered in the C IO lib in Python 3.1 (http://bugs.python.org/issue6629). I've applied a fix, and I wonder whether we should make a release quickly to minimize the probability of users hitting the problem? (Georg tells me Benjamin is on holiday, however)
Regards
Antoine.
On Thu, Aug 6, 2009 at 14:01, Antoine Pitrou solipsis@pitrou.net wrote:
Hello,
A data corruption issue has been discovered in the C IO lib in Python 3.1 (http://bugs.python.org/issue6629). I've applied a fix, and I wonder whether we should make a release quickly to minimize the probability of users hitting the problem?
Probably, or at least make the patch available directly.
(Georg tells me Benjamin is on holiday, however)
Yeah, I think he is in Sweden. Anyone know when he is due back?
-Brett
A data corruption issue has been discovered in the C IO lib in Python 3.1 (http://bugs.python.org/issue6629). I've applied a fix, and I wonder whether we should make a release quickly to minimize the probability of users hitting the problem?
There are always two dimensions in which to evaluate criticality of an issue: how serious is the problem it can cause when it hits, and in how many real applications is it likely to occur?
In the first dimension, I agree it's a serious problem. In the second dimension, it only affects applications that seek on files, and so I believe the problem is only of minor relevance.
I think posting a patch on the 3.1 release page would be sufficient for now, along with a summary description on the circumstances that may trigger the bug, and the consequences it may cause.
Regards, Martin
Le vendredi 07 août 2009 à 00:02 +0200, "Martin v. Löwis" a écrit :
There are always two dimensions in which to evaluate criticality of an issue: how serious is the problem it can cause when it hits, and in how many real applications is it likely to occur?
In the first dimension, I agree it's a serious problem. In the second dimension, it only affects applications that seek on files, and so I believe the problem is only of minor relevance.
It doesn't depend on seek() actually (this was the reporter's diagnosis, which turned out wrong). It happens when writing more than the buffer size after the buffer was filled for readahead but not entirely consumed.
The fact that it wasn't reported before may have to do with either the fact that it indeed doesn't affect a lot of applications, or that not many people have been using 3.1 "seriously" yet.
As a side note, when I was working on the IO lib, I regularly ran the Durus stress test script in addition to our test suite. So the problem might indeed be unlikely in the real world.
I think posting a patch on the 3.1 release page would be sufficient for now, along with a summary description on the circumstances that may trigger the bug, and the consequences it may cause.
I'm fine with this decision. The patch can be trivially extracted from one of the commits or svnmerges, but I don't know how to post it on the release page.
Regards
Antoine.
PS : Obviously, having our own brand new IO subsystem rather than relying on a venerable standard C library is not without risks.
Antoine Pitrou schrieb:
Hello,
A data corruption issue has been discovered in the C IO lib in Python 3.1 (http://bugs.python.org/issue6629). I've applied a fix, and I wonder whether we should make a release quickly to minimize the probability of users hitting the problem? (Georg tells me Benjamin is on holiday, however)
FWIW, I also think we should make a new micro release right now. We can't be seen to take data corruption issues with the most basic file operations lightly, especially in Python 3; otherwise, people will think we still don't consider it ready for use.
We can either make a release with only that patch applied, or a release of the full 3.1-maint branch, but the latter would need alphas and betas.
Georg
On Thu, Aug 6, 2009 at 4:28 PM, Georg Brandlg.brandl@gmx.net wrote:
Antoine Pitrou schrieb:
Hello,
A data corruption issue has been discovered in the C IO lib in Python 3.1 (http://bugs.python.org/issue6629). I've applied a fix, and I wonder whether we should make a release quickly to minimize the probability of users hitting the problem? (Georg tells me Benjamin is on holiday, however)
FWIW, I also think we should make a new micro release right now. We can't be seen to take data corruption issues with the most basic file operations lightly, especially in Python 3; otherwise, people will think we still don't consider it ready for use.
We can either make a release with only that patch applied, or a release of the full 3.1-maint branch, but the latter would need alphas and betas.
+1
Georg
-- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
On Thu, Aug 6, 2009 at 16:42, Guido van Rossum guido@python.org wrote:
On Thu, Aug 6, 2009 at 4:28 PM, Georg Brandlg.brandl@gmx.net wrote:
Antoine Pitrou schrieb:
Hello,
A data corruption issue has been discovered in the C IO lib in Python 3.1 (http://bugs.python.org/issue6629). I've applied a fix, and I
wonder
whether we should make a release quickly to minimize the probability of users hitting the problem? (Georg tells me Benjamin is on holiday, however)
FWIW, I also think we should make a new micro release right now. We
can't
be seen to take data corruption issues with the most basic file
operations
lightly, especially in Python 3; otherwise, people will think we still
don't
consider it ready for use.
We can either make a release with only that patch applied, or a release
of
the full 3.1-maint branch, but the latter would need alphas and betas.
+1
Is that for the former or latter solution? Assuming the former, who is going to organize this since Benjamin is on vacation? And do we want just a source release or a full binary release (I assume the latter but the former is a lot easier)?
-Brett
On Thu, Aug 6, 2009 at 5:42 PM, Brett Cannonbrett@python.org wrote:
On Thu, Aug 6, 2009 at 16:42, Guido van Rossum guido@python.org wrote:
On Thu, Aug 6, 2009 at 4:28 PM, Georg Brandlg.brandl@gmx.net wrote:
Antoine Pitrou schrieb:
Hello,
A data corruption issue has been discovered in the C IO lib in Python 3.1 (http://bugs.python.org/issue6629). I've applied a fix, and I wonder whether we should make a release quickly to minimize the probability of users hitting the problem? (Georg tells me Benjamin is on holiday, however)
FWIW, I also think we should make a new micro release right now. We can't be seen to take data corruption issues with the most basic file operations lightly, especially in Python 3; otherwise, people will think we still don't consider it ready for use.
We can either make a release with only that patch applied, or a release of the full 3.1-maint branch, but the latter would need alphas and betas.
+1
Is that for the former or latter solution? Assuming the former, who is going to organize this since Benjamin is on vacation? And do we want just a source release or a full binary release (I assume the latter but the former is a lot easier)?
I just meant to +1 the "we need to make a new micro-release right now" paragraph. Logistically, I think it needs to be a full binary release but it could be identical to 3.1 except for the one patch. Hopefully that obviates the need for alphas and betas. Who? Not me :-(
I just meant to +1 the "we need to make a new micro-release right now" paragraph. Logistically, I think it needs to be a full binary release but it could be identical to 3.1 except for the one patch.
Looking at Misc/NEWS, there are a number of worthy bugfixes already in. Why not just do a regular micro-release, reflecting the state of release31-maint? We could stick to the normal procedures -- the only thing different is that we're doing it sooner than planned.
Raymond
Le jeudi 06 août 2009 à 23:32 -0700, Raymond Hettinger a écrit :
I just meant to +1 the "we need to make a new micro-release right now" paragraph. Logistically, I think it needs to be a full binary release but it could be identical to 3.1 except for the one patch.
Looking at Misc/NEWS, there are a number of worthy bugfixes already in.
Indeed, a couple of which could be considered serious:
Issue #6573: set.union() stopped processing inputs if an instance of self occurred in the argument chain.
Issue #6415: Fixed warnings.warn segfault on bad formatted string.
Issue #6344: Fixed a crash of mmap.read() when passed a negative argument.
As a sidenote: I'm a relatively young core developer here, are there any precedents of such critical bugs? How has the situation been handled then?
Regards
Antoine.
Antoine Pitrou schrieb:
Le jeudi 06 août 2009 à 23:32 -0700, Raymond Hettinger a écrit :
I just meant to +1 the "we need to make a new micro-release right now" paragraph. Logistically, I think it needs to be a full binary release but it could be identical to 3.1 except for the one patch.
Looking at Misc/NEWS, there are a number of worthy bugfixes already in.
Indeed, a couple of which could be considered serious:
Issue #6573: set.union() stopped processing inputs if an instance of self occurred in the argument chain.
Issue #6415: Fixed warnings.warn segfault on bad formatted string.
Issue #6344: Fixed a crash of mmap.read() when passed a negative argument.
Less serious, but a showstopper nevertheless: #6126, which basically renders pdb unusable. I'll try to remember to commit the fix as soon as SVN is back.
Georg
On Thu, Aug 6, 2009 at 8:28 PM, Georg Brandlg.brandl@gmx.net wrote:
FWIW, I also think we should make a new micro release right now. We can't be seen to take data corruption issues with the most basic file operations lightly, especially in Python 3; otherwise, people will think we still don't consider it ready for use.
+1
On Thu, Aug 6, 2009 at 7:28 PM, Georg Brandlg.brandl@gmx.net wrote:
Antoine Pitrou schrieb:
Hello,
A data corruption issue has been discovered in the C IO lib in Python 3.1 (http://bugs.python.org/issue6629). I've applied a fix, and I wonder whether we should make a release quickly to minimize the probability of users hitting the problem? (Georg tells me Benjamin is on holiday, however)
FWIW, I also think we should make a new micro release right now. We can't be seen to take data corruption issues with the most basic file operations lightly, especially in Python 3; otherwise, people will think we still don't consider it ready for use.
+1 for a micro release.
-- Alexandre
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Georg Brandl wrote:
A data corruption issue has been discovered in the C IO lib in Python 3.1 (http://bugs.python.org/issue6629). I've applied a fix, and I wonder whether we should make a release quickly to minimize the probability of users hitting the problem? (Georg tells me Benjamin is on holiday, however)
FWIW, I also think we should make a new micro release right now. We can't be seen to take data corruption issues with the most basic file operations lightly, especially in Python 3; otherwise, people will think we still don't consider it ready for use.
+1. Messing with people files is probably the worst you can do.
Jesus Cea Avion _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ jabber / xmpp:jcea@jabber.org _/_/ _/_/ _/_/_/_/_/ . _/_/ _/_/ _/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/ _/_/ _/_/ _/_/ _/_/ "My name is Dump, Core Dump" _/_/_/ _/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz
Hi everyone, I'm just getting back from the nice trip to the Olympic Peninsula. I should be able to do a release sometime next week. In the meantime, could someone post the patch to the 3.1 download site? (We should add a note to the quick links section, too.)
2009/8/6 Georg Brandl g.brandl@gmx.net:
We can either make a release with only that patch applied, or a release of the full 3.1-maint branch, but the latter would need alphas and betas.
Why does that require doing alphas and betas? I believe the 2.5.x releases only had a RC and the 3.0.1 and 2.6.x had no preview releases before the final bugfix release.
I have in the past done a microrelease without a release candidate. It didn't go well.
On Fri, Aug 7, 2009 at 1:22 PM, Benjamin Peterson benjamin@python.orgwrote:
Hi everyone, I'm just getting back from the nice trip to the Olympic Peninsula. I should be able to do a release sometime next week. In the meantime, could someone post the patch to the 3.1 download site? (We should add a note to the quick links section, too.)
2009/8/6 Georg Brandl g.brandl@gmx.net:
We can either make a release with only that patch applied, or a release
of
the full 3.1-maint branch, but the latter would need alphas and betas.
Why does that require doing alphas and betas? I believe the 2.5.x releases only had a RC and the 3.0.1 and 2.6.x had no preview releases before the final bugfix release.
-- Regards, Benjamin _______________________________________________ python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
Benjamin Peterson schrieb:
Hi everyone, I'm just getting back from the nice trip to the Olympic Peninsula. I should be able to do a release sometime next week.
Just at the right time! :)
In the meantime, could someone post the patch to the 3.1 download site? (We should add a note to the quick links section, too.)
2009/8/6 Georg Brandl g.brandl@gmx.net:
We can either make a release with only that patch applied, or a release of the full 3.1-maint branch, but the latter would need alphas and betas.
Why does that require doing alphas and betas? I believe the 2.5.x releases only had a RC and the 3.0.1 and 2.6.x had no preview releases before the final bugfix release.
OK, maybe alphas and betas were a bit too skeptical; but there needs to be *something* that people can test before final. Otherwise, another release may be necessary just afterwards :|
Georg
Georg Brandl wrote:
OK, maybe alphas and betas were a bit too skeptical; but there needs to be *something* that people can test before final. Otherwise, another release may be necessary just afterwards :|
As has been noted, release candidate -> maintenance release is the approach that has worked well in the past. Only including bug fixes means the alpha/beta stages aren't needed, but going through an RC makes sure the installers and the like are all in a happy state as well.
Cheers, Nick.
Its also about preventing the brown paper bag releases caused by stupid screwups.
On Aug 7, 2009 8:08 PM, "Nick Coghlan" ncoghlan@gmail.com wrote:
Georg Brandl wrote: > OK, maybe alphas and betas were a bit too skeptical; but there needs to be > *... As has been noted, release candidate -> maintenance release is the approach that has worked well in the past. Only including bug fixes means the alpha/beta stages aren't needed, but going through an RC makes sure the installers and the like are all in a happy state as well.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
_______________________________________________ python-committers mailing list python-committers@pyt...
On Aug 7, 2009, at 2:20 AM, Georg Brandl wrote:
Why does that require doing alphas and betas? I believe the 2.5.x releases only had a RC and the 3.0.1 and 2.6.x had no preview
releases before the final bugfix release.OK, maybe alphas and betas were a bit too skeptical; but there needs
to be *something* that people can test before final. Otherwise, another
release may be necessary just afterwards :|
I'm skeptical about pre-releases for micro releases. Nobody outside
dedicated insiders really tests them and y'all can test the source
branches anyway. I also don't think it's /that/ big of a deal to
release a new micro release right away for the occasional brown bag
moment.
An alternative may be to embargo a micro release from the public for a
day or so. Build it and upload it, and announce it here. Let people
at least test installs and a few very simple things, and then 24 hours
later, update the public links and make the announcement.
OTOH, if and when snakebite.org is part of our normal development
process, the RM can just use that to make sure nothing horrible is
broken.
I'd say JFDI :)
-Barry