Hello,
I may be missing something, but do we have a policy of what we're supposed to commit to the 2.7 branch at this point? I was under the impression that it's only bug fixes, documentation, and maybe tests. But it seems that there are developers who see it otherwise.
For example, Raymond's changeset 5accb0ac8bfb (which was reverted by Benjamin today). Alas, Raymond did not explain the change even when challenged by multiple other core devs. Changeset f1dc30a1be72, which he committed today, also doesn't appear to belong in a bugfix branch.
It would be great if we could document this somewhere - the 2.7 branch is not a usual bugfix-mode branch, I realize, and hence maybe there's some special treatment it deserves.
Thanks in advance, Eli
Le samedi 22 juin 2013 à 12:02 -0700, Eli Bendersky a écrit :
Hello,
I may be missing something, but do we have a policy of what we're supposed to commit to the 2.7 branch at this point? I was under the impression that it's only bug fixes, documentation, and maybe tests. But it seems that there are developers who see it otherwise.
For me it's *definitely* bug fixes (and documentation and tests) only. The amount of regressions we had in recent 2.7.x bug fix releases makes me want to revert anything that doesn't fall in those categories :-)
Regards
Antoine.
On Jun 22, 2013, at 12:02 PM, Eli Bendersky wrote:
I may be missing something, but do we have a policy of what we're supposed to commit to the 2.7 branch at this point? I was under the impression that it's only bug fixes, documentation, and maybe tests. But it seems that there are developers who see it otherwise.
Strongly agree. One additional allowed category of changes are build system fixes, e.g. so that 2.7 can still be built on newer versions of operating systems it already supports.
It would be great if we could document this somewhere - the 2.7 branch is not a usual bugfix-mode branch, I realize, and hence maybe there's some special treatment it deserves.
IMO, Benjamin being the 2.7 RM has ultimate[1] say in the matter. I'm very glad he's conservative in what he allows in the branch.
-Barry
[1] Well, maybe penultimate, but I wouldn't mind seeing the Mercurial equivalent of a wrastlin' match between him and the BDFL. :)
On Sat, 22 Jun 2013 15:35:41 -0400, Barry Warsaw <barry@python.org> wrote:
On Jun 22, 2013, at 12:02 PM, Eli Bendersky wrote:
I may be missing something, but do we have a policy of what we're supposed to commit to the 2.7 branch at this point? I was under the impression that it's only bug fixes, documentation, and maybe tests. But it seems that there are developers who see it otherwise.
Strongly agree. One additional allowed category of changes are build system fixes, e.g. so that 2.7 can still be built on newer versions of operating systems it already supports.
It would be great if we could document this somewhere - the 2.7 branch is not a usual bugfix-mode branch, I realize, and hence maybe there's some special treatment it deserves.
IMO, Benjamin being the 2.7 RM has ultimate[1] say in the matter. I'm very glad he's conservative in what he allows in the branch.
My understanding is that there is an additional category that we allow beyond what Barry mentioned: things that add support for "stuff" that is analogous to the build enhancements: platform changes we really want to support that are trivial to add. The non-controversial example of this is adding mime types. The somewhat more controversial (but we've done it, IIRC) is adding support for new browsers (ie: Chrome) to the webbrowser module.
But IMO we should be considering the 2.7 branch to be starting to harden into immobility at this point. The bar for even bug fixes to be applied to 2.7 should be higher than for 3.3, and should continue to get higher still as time passes.
--David
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 22/06/13 22:39, R. David Murray wrote:
My understanding is that there is an additional category that we allow beyond what Barry mentioned: things that add support for "stuff" that is analogous to the build enhancements: platform changes we really want to support that are trivial to add. The non-controversial example of this is adding mime types. The somewhat more controversial (but we've done it, IIRC) is adding support for new browsers (ie: Chrome) to the webbrowser module.
bsddb module was recently updated to compile against current Oracle Berkeley DB releases.
http://bugs.python.org/issue17477
Oracle just released Berkeley DB 6.0.19... :-).
Jesús Cea Avión _/_/ _/_/_/ _/_/_/ jcea@jcea.es - http://www.jcea.es/ _/_/ _/_/ _/_/ _/_/ _/_/ Twitter: @jcea _/_/ _/_/ _/_/_/_/_/ 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQCVAwUBUceb45lgi5GaxT1NAQKu2QP+PmSMCM+iqF+MLcV6UNja+cg/LiQ1xCyv aoHCwi/W3+PcmI8JbKcBMNrG7BXXbWZ0DadtdTREC71kwBCuFW2O6BZRsVbHMWtE k/RA52imheySN7oQjNWoMxvY7GCTnD5bvx8+tL6lZd2GUJckiqEPVSk9YsMZQ3Ix kNIG1v/66RA= =Gq4N -----END PGP SIGNATURE-----
On Sat, Jun 22, 2013 at 12:35 PM, Barry Warsaw <barry@python.org> wrote:
On Jun 22, 2013, at 12:02 PM, Eli Bendersky wrote:
I may be missing something, but do we have a policy of what we're supposed to commit to the 2.7 branch at this point? I was under the impression that it's only bug fixes, documentation, and maybe tests. But it seems that there are developers who see it otherwise.
Strongly agree. One additional allowed category of changes are build system fixes, e.g. so that 2.7 can still be built on newer versions of operating systems it already supports.
Yes, this makes sense too.
In general there seems to be an agreement, so it would be great to document in some place. Many years will pass before we have another "special" release like Python 2.7, so it's worth spending an extra few minutes to have this written down. PEP 404 seems to be a reasonable place - any objections? Benjamin, what do you think?
Eli
Maybe time it so when we *would* have released a 2.8 (18 months or so after 2.7) is when it goes into critical/security fixes only? On Jun 22, 2013 11:50 PM, "Eli Bendersky" <eliben@gmail.com> wrote:
On Sat, Jun 22, 2013 at 12:35 PM, Barry Warsaw <barry@python.org> wrote:
On Jun 22, 2013, at 12:02 PM, Eli Bendersky wrote:
I may be missing something, but do we have a policy of what we're supposed to commit to the 2.7 branch at this point? I was under the impression that it's only bug fixes, documentation, and maybe tests. But it seems that there are developers who see it otherwise.
Strongly agree. One additional allowed category of changes are build system fixes, e.g. so that 2.7 can still be built on newer versions of operating systems it already supports.
Yes, this makes sense too.
In general there seems to be an agreement, so it would be great to document in some place. Many years will pass before we have another "special" release like Python 2.7, so it's worth spending an extra few minutes to have this written down. PEP 404 seems to be a reasonable place - any objections? Benjamin, what do you think?
Eli
python-committers mailing list python-committers@python.org http://mail.python.org/mailman/listinfo/python-committers
2013/6/22 Eli Bendersky <eliben@gmail.com>:
Yes, this makes sense too.
In general there seems to be an agreement, so it would be great to document in some place. Many years will pass before we have another "special" release like Python 2.7, so it's worth spending an extra few minutes to have this written down. PEP 404 seems to be a reasonable place - any objections? Benjamin, what do you think?
PEP 373 is better given in that it deals with 2.7 and not a non-existent 2.8 release. :)
I agree not every theoretically applicable bugfix needs to land in 2.7. If it's been broken for all of the 2.x series, it probably doesn't need to be fixed now. (The most important bugs to fix are the ones we introduced in the last bugfix release.) I'm also open to and have been open to build system changes that keep Python compiling even though they can break things (see cross-compiling). Even limited not-build system "features" like retrofitting bsddb so it could compile with a non-ancient version of bsddb can be acceptable.
-- Regards, Benjamin
On 23 June 2013 12:56, Benjamin Peterson <benjamin@python.org> wrote:
2013/6/22 Eli Bendersky <eliben@gmail.com>:
Yes, this makes sense too.
In general there seems to be an agreement, so it would be great to document in some place. Many years will pass before we have another "special" release like Python 2.7, so it's worth spending an extra few minutes to have this written down. PEP 404 seems to be a reasonable place - any objections? Benjamin, what do you think?
PEP 373 is better given in that it deals with 2.7 and not a non-existent 2.8 release. :)
I agree not every theoretically applicable bugfix needs to land in 2.7. If it's been broken for all of the 2.x series, it probably doesn't need to be fixed now. (The most important bugs to fix are the ones we introduced in the last bugfix release.) I'm also open to and have been open to build system changes that keep Python compiling even though they can break things (see cross-compiling). Even limited not-build system "features" like retrofitting bsddb so it could compile with a non-ancient version of bsddb can be acceptable.
FWIW, this aligns with my understanding of the purpose of the extended maintenance period for Python 2.7 - not so much that it receives "new" bug fixes, but more that we ensure it keeps building and otherwise working reliably as the wider technology ecosystem changes around it (for example, the cross-compilation changes to help cope with the rise of ARM systems, especially the Raspberry Pi).
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sat, Jun 22, 2013 at 12:35 PM, Barry Warsaw <barry@python.org> wrote:
[1] Well, maybe penultimate, but I wouldn't mind seeing the Mercurial equivalent of a wrastlin' match between him and the BDFL. :)
You wouldn't see that this summer though -- I could just tackle him in the office. :-)
-- --Guido van Rossum (python.org/~guido)
Everything I read in this thread says that 2.7 only gets bug fixes, and even at that it has to be a pretty bad bug. (Benjamin: "If it's been broken for all of the 2.x series, it probably doesn't need to be fixed now.") I don't see even mild dissent; the replies have been strongly unanimous.
Less than a day ago Benjamin relented on reverting Raymond's deque-block-size changeset. He has since reapplied the change. Therefore as of now this change will go into 2.7.6. Although it looks like a fine idea, AFAICT this is not a bug fix--unless a longstanding performance regression can be considered a bug fix. So I don't understand why this change was reapplied.
I'm not questioning the decision--I'm asking, what is the heuristic I can apply in the future to predict whether or not a change will be accepted into the 2.7 branch. My current heuristic ("only bad bug fixes") seems to be on the fritz.
//arry/
On 06/25/2013 07:10 PM, Larry Hastings wrote:
Everything I read in this thread says that 2.7 only gets bug fixes, and even at that it has to be a pretty bad bug. (Benjamin: "If it's been broken for all of the 2.x series, it probably doesn't need to be fixed now.") I don't see even mild dissent; the replies have been strongly unanimous.
Less than a day ago Benjamin relented on reverting Raymond's deque-block-size changeset. He has since reapplied the change. Therefore as of now this change will go into 2.7.6. Although it looks like a fine idea, AFAICT this is not a bug fix--unless a longstanding performance regression can be considered a bug fix. So I don't understand why this change was reapplied.
I'm not questioning the decision--I'm asking, what is the heuristic I can apply in the future to predict whether or not a change will be accepted into the 2.7 branch. My current heuristic ("only bad bug fixes") seems to be on the fritz.
+1
-- ~Ethan~
On 26.06.2013 04:10, Larry Hastings wrote:
Everything I read in this thread says that 2.7 only gets bug fixes, and even at that it has to be a pretty bad bug. (Benjamin: "If it's been broken for all of the 2.x series, it probably doesn't need to be fixed now.") I don't see even mild dissent; the replies have been strongly unanimous.
Less than a day ago Benjamin relented on reverting Raymond's deque-block-size changeset. He has since reapplied the change. Therefore as of now this change will go into 2.7.6. Although it looks like a fine idea, AFAICT this is not a bug fix--unless a longstanding performance regression can be considered a bug fix. So I don't understand why this change was reapplied.
I'm not questioning the decision--I'm asking, what is the heuristic I can apply in the future to predict whether or not a change will be accepted into the 2.7 branch. My current heuristic ("only bad bug fixes") seems to be on the fritz.
Let's not forget that Python 2.7 is the currently most used Python version there is. It's being used in production and many people rely on it.
I think that bug fixes (including fixes for performance regressions) should continue to go into the 2.7 branch, as well as fixes that allow compiling Python 2.7 on more recent platforms.
The current schedule is to provide bug fix releases at least until 2015:
http://www.python.org/download/releases/2.7/ http://www.python.org/dev/peps/pep-0373/
Given that the transition to Python 3 is just starting to pick up speed this year, we may have to revisit the 2015 end-of-support next year.
-- Marc-Andre Lemburg eGenix.com
Professional Python Services directly from the Source (#1, Jun 26 2013)
Python Projects, Consulting and Support ... http://www.egenix.com/ mxODBC.Zope/Plone.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
2013-06-18: Released mxODBC Django DE 1.2.0 ... http://egenix.com/go47 2013-07-01: EuroPython 2013, Florence, Italy ... 5 days to go 2013-07-16: Python Meeting Duesseldorf ... 20 days to go
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
2013/6/25 Larry Hastings <larry@hastings.org>:
I'm not questioning the decision--I'm asking, what is the heuristic I can apply in the future to predict whether or not a change will be accepted into the 2.7 branch. My current heuristic ("only bad bug fixes") seems to be on the fritz.
I realize everyone wants a nice heuristic. Unfortunately, I don't think one exists that explains why every change does or does not land in 2.7.
-- Regards, Benjamin
On 27 June 2013 10:14, Benjamin Peterson <benjamin@python.org> wrote:
2013/6/25 Larry Hastings <larry@hastings.org>:
I'm not questioning the decision--I'm asking, what is the heuristic I can apply in the future to predict whether or not a change will be accepted into the 2.7 branch. My current heuristic ("only bad bug fixes") seems to be on the fritz.
I realize everyone wants a nice heuristic. Unfortunately, I don't think one exists that explains why every change does or does not land in 2.7.
The best one I have is that simplifying cross-version maintenance and addressing issues that arise due to changes in the underlying platforms seem to be the two main reasons we do it :)
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
participants (12)
-
Anthony Baxter -
Antoine Pitrou -
Barry Warsaw -
Benjamin Peterson -
Eli Bendersky -
Ethan Furman -
Guido van Rossum -
Jesus Cea -
Larry Hastings -
M.-A. Lemburg -
Nick Coghlan -
R. David Murray