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