Official version support statement
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This came up in a different context. I originally emailed this to the python.org admins, but Aahz rightly points out that we should first agree here that this actually /is/ our official stance. - -----snip----- We have an "official unofficial" policy of supporting only Python 2.current and 2.(current - 1), and /not/ supporting anything earlier. Do we already have an official statement to this effect on the website? The closest thing I could find was on the download page, but that's not really definitive. What do you think about adding something like the following to the top of the download page: "The Python Software Foundation officially supports the current stable major release and one prior major release. Currently, Python 2.5 and 2.4 are officially supported. Where appropriate and necessary, patches for earlier releases may be made available, but no earlier versions are officially supported by the PSF. We do not make releases of unsupported versions, although patched versions may become available through other vendors." - -Barry P.S. On re-reading this, I realize this text would need amending when Python 3.x is released, but I don't care about that right now. pdo admins: I also slightly changed the proposed text. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRkM1/XEjvBPtnXfVAQJufwP9E4A7cbHyDRk0v/hONjlt3ZJ2eCtwYZL6 hlitMIBb8YxJsGNo6p1kC0KkB/DObqmCarTy8YXIM+v8j32UmEbiRmJFxexuKdVw I0EqziHnYdSkkp3cN+EGP2jahfLFVMaA2A2Ohj0o0mLGZEQU7TTF4F6U33PlooXs G6zKmDzuLT4= =BWxm -----END PGP SIGNATURE-----
"Barry Warsaw" <barry@python.org> wrote in message news:343F26A5-7DFE-4757-BA4D-2A666CE85215@python.org... | -----BEGIN PGP SIGNED MESSAGE----- | Hash: SHA1 | | This came up in a different context. I originally emailed this to | the python.org admins, but Aahz rightly points out that we should | first agree here that this actually /is/ our official stance. | | - -----snip----- | | We have an "official unofficial" policy of supporting only Python | 2.current and 2.(current - 1), and /not/ supporting anything earlier. | | Do we already have an official statement to this effect on the | website? The closest thing I could find was on the download page, | but that's not really definitive. | | What do you think about adding something like the following to the | top of the download page: | | "The Python Software Foundation officially supports the current | stable major release and one prior major release. Currently, Python | 2.5 and 2.4 are officially supported. Where appropriate and | necessary, patches for earlier releases may be made available, but no | earlier versions are officially supported by the PSF. We do not make | releases of unsupported versions, although patched versions may | become available through other vendors." This strikes me as a bit over-officious (the 'officially' adds nothing to me except a bit of stuffiness). Worse, it seems wrong and hence, to me, misleading. The current de facto policy is that when a new major release comes out, there is a *final* minor, bugfix release of the previous major version. Thus, 2.5 is being supported while 2.6 is being worked on. As I understand it, there are no more plans to touch 2.4 than 2.3 and so on. So the current message is: "If you want a 2.5 bug fixed, find it, report it, and help get it fixed now before 2.6 is released." I am aware that if a trustworthy person or persons were to backport some substantial numbers of fixes from 2.5 to 2.4, greenlight the test suite on several systems, cut release candidates, and repond to reports, the file would appear on the official Python site. But currently, as far as I know, this 'support' is as empty as the Official Help-Yourself Plate of Donated Cookies on my kitchen table. The reason, is seems to me, that prior major releases do not get support is that they do not much need it. For practical purposes, core CPython is pretty much bug free. Module bugs get reported and fixed or worked around. Old users can upgrade if they want fixes that appear later. And new users generally start with the current major release. Terry Jan Reedy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 10, 2007, at 12:53 PM, Terry Reedy wrote:
I'm happy to document whatever we decide the policy is, but I think we should decide and produce an official statement as such. It helps users and vendors to know what they can count on us for and what they might be on their own for. It's also not that big of a deal if we amend the policy later because we have volunteer release managers for earlier versions. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRkTp43EjvBPtnXfVAQJCigP9GtmkyIpI7NadM0pfPIIsLkLCvqFA8sNe oMVv5cGMtkDaw6x4kuITv+EL0CCXopXgz89vTq1bFrrmBbJpR1Bk3ToB9L2VvWPl kjxzExIwaS8xtywfw7j5Mn2vfBVpK7lewL5POwOg9QQ1r51cHcTjoL/28FD1yqf2 5rUahZFDTLY= =xQjh -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 10, 2007, at 6:46 PM, Martin v. Löwis wrote:
Is this draft any better? "The Python Software Foundation officially supports the current stable major release of Python. By "supports" we mean that the PSF will produce bug fix releases of this version, currently Python 2.5. We may release patches for earlier versions if necessary, such as to fix security problems, but we generally do not make releases of such unsupported versions. Patch releases of earlier Python versions may be made available through third parties, including OS vendors." - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRkTraHEjvBPtnXfVAQLsZAP/eOCIn77Z+wfbdX0ys8N1LWCd242alW/p 6ws9qa6BQ2At5tDBAZtwjR2QX8LKn4zlM2CgaqvVrEjvZ8hgtSDv4hC0jfa0YCHQ bUrNzu3pZfJm62S0SFs753jtcImRFwBMBHHBU47N6GqXOB+mAlMgvAtch3Zakidq 37by4Iefj84= =28A4 -----END PGP SIGNATURE-----
If such an official statement still can be superseded by an even more official PEP, it's fine with me. However, I would prefer to not use the verb "support" at all. We (the PSF) don't provide any technical support for *any* version ever released: '''PSF is making Python available to Licensee on an "AS IS" basis. PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON WILL NOT INFRINGE ANY THIRD PARTY RIGHTS.''' The more I think about it: no, there is no official support for the current stable release. We will like produce more bug fix releases, but then, we may not if the volunteers doing so lose time or interest, and 2.6 comes out earlier than planned. Why do you need such a statement? Regards, Martin
At 12:58 AM +0200 5/12/07, Martin v. Löwis wrote:
I think Fedora might want it, per recent discussions on fedora-devel-list. My impertinent attempt: "The Python Software Foundation maintains the current stable major release of Python. By "maintains" we mean that the PSF will produce bug fix releases of that version, currently Python 2.5. We have released patches for earlier versions as necessary, such as to fix security problems, but we generally do not make releases of such prior versions. Patched releases of earlier Python versions may be made available through third parties, including OS vendors." -- ____________________________________________________________________ TonyN.:' <mailto:tonynelson@georgeanelson.com> ' <http://www.georgeanelson.com/>
Tony> "The Python Software Foundation maintains the current stable major Tony> release of Python. By "maintains" we mean that the PSF will Tony> produce bug fix releases of that version, currently Python 2.5. Tony> We have released patches for earlier versions as necessary, such Tony> as to fix security problems, but we generally do not make releases Tony> of such prior versions. Patched releases of earlier Python Tony> versions may be made available through third parties, including OS Tony> vendors." Since there is (generally?) an attempt to make one last bug fix release of the previous version after the next major version is released, should that be mentioned? To make it concrete, I believe shortly after 2.5.0 was released the final bug fix release of 2.4 (2.4.4?) was released. Skip
On Saturday 12 May 2007, skip@pobox.com wrote:
Correct. Note that this is only something that's been in place while I've been doing it. The current "standard" for how we do releases is just something I made up as I went along, including - regular 6-monthly bugfix releases - only one maintenance branch (most recent) for the bugfix releases - the last bugfix release of the previous release after a new major release. I'm OK with these being formalised - but any additional requirements I'd like to discuss first :-) Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
"Tony Nelson" <tonynelson@georgeanelson.com> wrote in message news:p04330101c26ac5b79f21@[192.168.123.162]... At 12:58 AM +0200 5/12/07, Martin v. Löwis wrote: |>However, I would prefer to not use the verb "support" at all. agreed |"The Python Software Foundation maintains the current stable major |release of Python. By "maintains" we mean that the PSF will produce |bug fix releases of that version, currently Python 2.5. This strikes me as an improvement, but 'maintain' is close to 'support' and seems to make a promise that might also have unintended legal consequences. But that is what your legal consel is for. The actuality is that the legal fiction called the PSF *releases* new versions produced by a collection of volunteers, some of whom are PSF members and who perhaps consider that they do their work 'in the name of' PSF, and some of whom are not PSF members and perhaps do not have such a consideration. Defining CPython as a PSF rather than volunteer community product might discourage volunteer contributions. 'Official' statements need both motivation (what is there that is actually broken?) and care (to not break something else). | We have released patches for earlier versions as necessary, such as to fix security problems, Funny thing here is that the security releases, by necessity, are more a PSF product than normal releases. Terry Jan Reedy
Terry Reedy writes:
Unilateral statements on a web page do not constitute a contract. Implied warrantees *are* a problem, but those are taken care of by the license. (IANAL, etc.) What's left is purely an issue of marketing, ie, to real people a promise is a promise whether legally enforced or not. No matter how weaselly the wording on the website, users expect support and deprecate projects that don't provide it. And in Python practice they get it, and will continue calling it "support". Unless there are real legal consequences, I think it's a good idea for the PSF to define explicitly how the resources it either controls or can elicit from volunteers will be used, to the extent that PSF can do so. And it's best if the words "support" and "maintain" are used, because that's how the users think about it.
'Official' statements need both motivation (what is there that is actually broken?)
The impression that many people (including python-dev regulars) have that there is a "policy" of "support" for both the current release (2.5) and the (still very widely used) previous release (2.4) is a real problem, and needs to be addressed.
"Stephen J. Turnbull" <stephen@xemacs.org> wrote in message news:17989.27755.568352.465481@uwakimon.sk.tsukuba.ac.jp... | The impression that many people (including python-dev regulars) have | that there is a "policy" of "support" for both the current release | (2.5) and the (still very widely used) previous release (2.4) is a | real problem, and needs to be addressed. I agree that such mis-understanding should be addressed. So I now think a paragraph summarizing Martin's info PEP, ending with "For details, see PEPxxx.", would be a good idea. tjr
Terry Reedy writes:
FWIW, after Martin's explanation, and considering the annoyance of keeping updates sync'ed (can PEPs be amended after acceptance, or only superseded by a new PEP, like IETF RFCs?), I tend to support Barry's suggestion of a brief listing of current releases and next planned, and "Python policy concerning release planning is defined by [the current version of] PEPxxx", with a link.
"Stephen J. Turnbull" <stephen@xemacs.org> wrote in message news:17990.24299.900967.926771@uwakimon.sk.tsukuba.ac.jp... | FWIW, after Martin's explanation, and considering the annoyance of | keeping updates sync'ed (can PEPs be amended after acceptance, or only | superseded by a new PEP, like IETF RFCs?), Informational PEPs often get updated (starting with PEP 1!)
Stephen J. Turnbull wrote:
In which case doesn't it make more sense to use the existing mechanism of PEP 356 (Release Schedule)? If something isn't listed in there (even without dates) then there are no current plans to release it, and that tells the reader everything they need to know. At the moment the PEP begins with "This document describes the development and release schedule for Python 2.5." but it could just as easily say "future releases of the Python 2.X series" or something similar. Which reminds me, that PEP needs updating! regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden ------------------ Asciimercial --------------------- Get on the web: Blog, lens and tag your way to fame!! holdenweb.blogspot.com squidoo.com/pythonology tagged items: del.icio.us/steve.holden/python All these services currently offer free registration! -------------- Thank You for Reading ----------------
Steve Holden wrote:
Those release schedule PEPs are mainly a TODO list leading up to the 2.x.0 releases, though - there's a new one for each major version bump: PEP 160 - Python 1.6 PEP 200 - Python 2.0 PEP 226 - Python 2.1 PEP 251 - Python 2.2 PEP 283 - Python 2.3 PEP 320 - Python 2.4 PEP 356 - Python 2.5 PEP 361 - Python 2.6 Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
Nick Coghlan wrote:
Thanks, it wouldn't be appropriate then (and 361 *doesn't* need updating). regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden ------------------ Asciimercial --------------------- Get on the web: Blog, lens and tag your way to fame!! holdenweb.blogspot.com squidoo.com/pythonology tagged items: del.icio.us/steve.holden/python All these services currently offer free registration! -------------- Thank You for Reading ----------------
Why do you need such a statement?
I think Fedora might want it, per recent discussions on fedora-devel-list.
In that case, I would rather have somebody official of the Fedora list state the request explicitly, than basing it on hearsay.
"The Python Software Foundation maintains the current stable major release of Python.
Ah, maintains is indeed better than supports. That's what we do: we maintain Python. Regards, Martin
"Martin v. Löwis" writes:
Of course the PSF provides *excellent* technical support; you just don't acknowledge any *obligation* to do it. A declaration of support is not a warranty, of course. So I see no problem with using the word "support". You may wish to clarify with terms like "resources available".
Why do you need such a statement?
Because it expresses what IMO *actually happens* clearly, and clarifies the intent of the PSF to continue in the same way. This is useful to users making decisions, even though the PSF owns few to none of the resources needed. The generosity of the contributors and their loyalty to Python and to each other practically guarantees availability. Python can dispose of a raft of bugs present only in the older versions with WONTFIX at release of a new stable version (after double-checking that they don't exist in the stable version). Developers can respond to reports of bugs in the immediate past version with "I'm sorry, but we try to concentrate our limited resources on supporting the current version, and it is unlikely that it will be fixed. Please post to c.l.p for help." Users are disappointed, but it builds trust, and more so if supported by an official statement.
I'm all in favor of formalizing a policy of when Python releases are produced, and what Python releases, and what kinds of changes they may contain. However, such a policy should be addressed primarily to contributors, as a guidance, not to users, as a promise. So I have problems with both "official" and "support" still.
The way we make policy statements is through the PEP process. This is important, because it involves the community in setting the policy. The PSF board has often explicitly tried to stay out of managing the Python development itself, and has deferred that to python-dev and its readership. I had meant to propose a PEP on maintenance of Python releases for quite some time now; perhaps this is the time to actually write this PEP. Regards, Martin
"Martin v. Löwis" writes:
I see your point, but I don't see how you propose to keep the users from viewing the guidelines to developers as official policy regarding support, albeit hard to interpret. Also, it may just be me, but I don't see an official statement as a "promise". It's a "clarification". '''This is what we're trying to do, so you can make well-informed plans, and not be surprised when you ask for something and we say "but we never thought about doing that, and don't intend to".'''
The way we make policy statements is through the PEP process.
Creating the statement that way is important. But publishing a PEP is not enough. Non-developer users don't read PEPs. After thinking about it a bit, I do agree that "maintain" is more appropriate than "support" (this is after my reply to Terry Reedy, where I wrote that support was OK). Support implies education and adaptation to user needs, but even if that is done by the PSF, it's a separate activity from the development and release processes. While maintenance does include response to user bug reports as part of the development/release process.
And that's fine if they do. I don't mind if a statement is considered official if it is - a BDFL pronouncement, or - the result of a PSF board or members vote Otherwise, it isn't "official". There are other "officers" which can make official statements, e.g. the release manager can also make official statements, but anybody else's statement is just an opinion.
Right. It's fine to rephrase (para-phrase?) the consensus achieved in a PEP. However, that rephrasing cannot precede the PEP.
That was exactly my concern about "support". I associate with "support" that there is a hotline I can call and they will help me. I've used various support infrastructures in the past years (from Microsoft, Dell, Veritas/Symantec), and in all cases, "support" meant that somebody would help me with a specific problem. "Unsupported product" then means "if you have a problem with that product, we won't help". There is good and bad support, of course, and I know which companies provided me good support and which didn't. There are indeed various support channels for python: comp.lang.python, python-tutors, and python-help, and none of them have the notion of "unsupported Python releases". Thing become unsupported by no volunteer being willing to offer help. It's also important to understand that the bug tracker is *not* a means of user support, even though users sometimes mistake it to be so, and end their "bug report" with a call for help. It's vice versa: a bug report is a *contribution* by the user, i.e. a means for giving a gift, not for requesting one. Regards, Martin
"Barry Warsaw" <barry@python.org> wrote in message news:343F26A5-7DFE-4757-BA4D-2A666CE85215@python.org... | -----BEGIN PGP SIGNED MESSAGE----- | Hash: SHA1 | | This came up in a different context. I originally emailed this to | the python.org admins, but Aahz rightly points out that we should | first agree here that this actually /is/ our official stance. | | - -----snip----- | | We have an "official unofficial" policy of supporting only Python | 2.current and 2.(current - 1), and /not/ supporting anything earlier. | | Do we already have an official statement to this effect on the | website? The closest thing I could find was on the download page, | but that's not really definitive. | | What do you think about adding something like the following to the | top of the download page: | | "The Python Software Foundation officially supports the current | stable major release and one prior major release. Currently, Python | 2.5 and 2.4 are officially supported. Where appropriate and | necessary, patches for earlier releases may be made available, but no | earlier versions are officially supported by the PSF. We do not make | releases of unsupported versions, although patched versions may | become available through other vendors." This strikes me as a bit over-officious (the 'officially' adds nothing to me except a bit of stuffiness). Worse, it seems wrong and hence, to me, misleading. The current de facto policy is that when a new major release comes out, there is a *final* minor, bugfix release of the previous major version. Thus, 2.5 is being supported while 2.6 is being worked on. As I understand it, there are no more plans to touch 2.4 than 2.3 and so on. So the current message is: "If you want a 2.5 bug fixed, find it, report it, and help get it fixed now before 2.6 is released." I am aware that if a trustworthy person or persons were to backport some substantial numbers of fixes from 2.5 to 2.4, greenlight the test suite on several systems, cut release candidates, and repond to reports, the file would appear on the official Python site. But currently, as far as I know, this 'support' is as empty as the Official Help-Yourself Plate of Donated Cookies on my kitchen table. The reason, is seems to me, that prior major releases do not get support is that they do not much need it. For practical purposes, core CPython is pretty much bug free. Module bugs get reported and fixed or worked around. Old users can upgrade if they want fixes that appear later. And new users generally start with the current major release. Terry Jan Reedy
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 10, 2007, at 12:53 PM, Terry Reedy wrote:
I'm happy to document whatever we decide the policy is, but I think we should decide and produce an official statement as such. It helps users and vendors to know what they can count on us for and what they might be on their own for. It's also not that big of a deal if we amend the policy later because we have volunteer release managers for earlier versions. - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRkTp43EjvBPtnXfVAQJCigP9GtmkyIpI7NadM0pfPIIsLkLCvqFA8sNe oMVv5cGMtkDaw6x4kuITv+EL0CCXopXgz89vTq1bFrrmBbJpR1Bk3ToB9L2VvWPl kjxzExIwaS8xtywfw7j5Mn2vfBVpK7lewL5POwOg9QQ1r51cHcTjoL/28FD1yqf2 5rUahZFDTLY= =xQjh -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On May 10, 2007, at 6:46 PM, Martin v. Löwis wrote:
Is this draft any better? "The Python Software Foundation officially supports the current stable major release of Python. By "supports" we mean that the PSF will produce bug fix releases of this version, currently Python 2.5. We may release patches for earlier versions if necessary, such as to fix security problems, but we generally do not make releases of such unsupported versions. Patch releases of earlier Python versions may be made available through third parties, including OS vendors." - -Barry -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) iQCVAwUBRkTraHEjvBPtnXfVAQLsZAP/eOCIn77Z+wfbdX0ys8N1LWCd242alW/p 6ws9qa6BQ2At5tDBAZtwjR2QX8LKn4zlM2CgaqvVrEjvZ8hgtSDv4hC0jfa0YCHQ bUrNzu3pZfJm62S0SFs753jtcImRFwBMBHHBU47N6GqXOB+mAlMgvAtch3Zakidq 37by4Iefj84= =28A4 -----END PGP SIGNATURE-----
If such an official statement still can be superseded by an even more official PEP, it's fine with me. However, I would prefer to not use the verb "support" at all. We (the PSF) don't provide any technical support for *any* version ever released: '''PSF is making Python available to Licensee on an "AS IS" basis. PSF MAKES NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED. BY WAY OF EXAMPLE, BUT NOT LIMITATION, PSF MAKES NO AND DISCLAIMS ANY REPRESENTATION OR WARRANTY OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE OR THAT THE USE OF PYTHON WILL NOT INFRINGE ANY THIRD PARTY RIGHTS.''' The more I think about it: no, there is no official support for the current stable release. We will like produce more bug fix releases, but then, we may not if the volunteers doing so lose time or interest, and 2.6 comes out earlier than planned. Why do you need such a statement? Regards, Martin
At 12:58 AM +0200 5/12/07, Martin v. Löwis wrote:
I think Fedora might want it, per recent discussions on fedora-devel-list. My impertinent attempt: "The Python Software Foundation maintains the current stable major release of Python. By "maintains" we mean that the PSF will produce bug fix releases of that version, currently Python 2.5. We have released patches for earlier versions as necessary, such as to fix security problems, but we generally do not make releases of such prior versions. Patched releases of earlier Python versions may be made available through third parties, including OS vendors." -- ____________________________________________________________________ TonyN.:' <mailto:tonynelson@georgeanelson.com> ' <http://www.georgeanelson.com/>
Tony> "The Python Software Foundation maintains the current stable major Tony> release of Python. By "maintains" we mean that the PSF will Tony> produce bug fix releases of that version, currently Python 2.5. Tony> We have released patches for earlier versions as necessary, such Tony> as to fix security problems, but we generally do not make releases Tony> of such prior versions. Patched releases of earlier Python Tony> versions may be made available through third parties, including OS Tony> vendors." Since there is (generally?) an attempt to make one last bug fix release of the previous version after the next major version is released, should that be mentioned? To make it concrete, I believe shortly after 2.5.0 was released the final bug fix release of 2.4 (2.4.4?) was released. Skip
On Saturday 12 May 2007, skip@pobox.com wrote:
Correct. Note that this is only something that's been in place while I've been doing it. The current "standard" for how we do releases is just something I made up as I went along, including - regular 6-monthly bugfix releases - only one maintenance branch (most recent) for the bugfix releases - the last bugfix release of the previous release after a new major release. I'm OK with these being formalised - but any additional requirements I'd like to discuss first :-) Anthony -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
"Tony Nelson" <tonynelson@georgeanelson.com> wrote in message news:p04330101c26ac5b79f21@[192.168.123.162]... At 12:58 AM +0200 5/12/07, Martin v. Löwis wrote: |>However, I would prefer to not use the verb "support" at all. agreed |"The Python Software Foundation maintains the current stable major |release of Python. By "maintains" we mean that the PSF will produce |bug fix releases of that version, currently Python 2.5. This strikes me as an improvement, but 'maintain' is close to 'support' and seems to make a promise that might also have unintended legal consequences. But that is what your legal consel is for. The actuality is that the legal fiction called the PSF *releases* new versions produced by a collection of volunteers, some of whom are PSF members and who perhaps consider that they do their work 'in the name of' PSF, and some of whom are not PSF members and perhaps do not have such a consideration. Defining CPython as a PSF rather than volunteer community product might discourage volunteer contributions. 'Official' statements need both motivation (what is there that is actually broken?) and care (to not break something else). | We have released patches for earlier versions as necessary, such as to fix security problems, Funny thing here is that the security releases, by necessity, are more a PSF product than normal releases. Terry Jan Reedy
Terry Reedy writes:
Unilateral statements on a web page do not constitute a contract. Implied warrantees *are* a problem, but those are taken care of by the license. (IANAL, etc.) What's left is purely an issue of marketing, ie, to real people a promise is a promise whether legally enforced or not. No matter how weaselly the wording on the website, users expect support and deprecate projects that don't provide it. And in Python practice they get it, and will continue calling it "support". Unless there are real legal consequences, I think it's a good idea for the PSF to define explicitly how the resources it either controls or can elicit from volunteers will be used, to the extent that PSF can do so. And it's best if the words "support" and "maintain" are used, because that's how the users think about it.
'Official' statements need both motivation (what is there that is actually broken?)
The impression that many people (including python-dev regulars) have that there is a "policy" of "support" for both the current release (2.5) and the (still very widely used) previous release (2.4) is a real problem, and needs to be addressed.
"Stephen J. Turnbull" <stephen@xemacs.org> wrote in message news:17989.27755.568352.465481@uwakimon.sk.tsukuba.ac.jp... | The impression that many people (including python-dev regulars) have | that there is a "policy" of "support" for both the current release | (2.5) and the (still very widely used) previous release (2.4) is a | real problem, and needs to be addressed. I agree that such mis-understanding should be addressed. So I now think a paragraph summarizing Martin's info PEP, ending with "For details, see PEPxxx.", would be a good idea. tjr
Terry Reedy writes:
FWIW, after Martin's explanation, and considering the annoyance of keeping updates sync'ed (can PEPs be amended after acceptance, or only superseded by a new PEP, like IETF RFCs?), I tend to support Barry's suggestion of a brief listing of current releases and next planned, and "Python policy concerning release planning is defined by [the current version of] PEPxxx", with a link.
"Stephen J. Turnbull" <stephen@xemacs.org> wrote in message news:17990.24299.900967.926771@uwakimon.sk.tsukuba.ac.jp... | FWIW, after Martin's explanation, and considering the annoyance of | keeping updates sync'ed (can PEPs be amended after acceptance, or only | superseded by a new PEP, like IETF RFCs?), Informational PEPs often get updated (starting with PEP 1!)
Stephen J. Turnbull wrote:
In which case doesn't it make more sense to use the existing mechanism of PEP 356 (Release Schedule)? If something isn't listed in there (even without dates) then there are no current plans to release it, and that tells the reader everything they need to know. At the moment the PEP begins with "This document describes the development and release schedule for Python 2.5." but it could just as easily say "future releases of the Python 2.X series" or something similar. Which reminds me, that PEP needs updating! regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden ------------------ Asciimercial --------------------- Get on the web: Blog, lens and tag your way to fame!! holdenweb.blogspot.com squidoo.com/pythonology tagged items: del.icio.us/steve.holden/python All these services currently offer free registration! -------------- Thank You for Reading ----------------
Steve Holden wrote:
Those release schedule PEPs are mainly a TODO list leading up to the 2.x.0 releases, though - there's a new one for each major version bump: PEP 160 - Python 1.6 PEP 200 - Python 2.0 PEP 226 - Python 2.1 PEP 251 - Python 2.2 PEP 283 - Python 2.3 PEP 320 - Python 2.4 PEP 356 - Python 2.5 PEP 361 - Python 2.6 Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org
Nick Coghlan wrote:
Thanks, it wouldn't be appropriate then (and 361 *doesn't* need updating). regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden ------------------ Asciimercial --------------------- Get on the web: Blog, lens and tag your way to fame!! holdenweb.blogspot.com squidoo.com/pythonology tagged items: del.icio.us/steve.holden/python All these services currently offer free registration! -------------- Thank You for Reading ----------------
Why do you need such a statement?
I think Fedora might want it, per recent discussions on fedora-devel-list.
In that case, I would rather have somebody official of the Fedora list state the request explicitly, than basing it on hearsay.
"The Python Software Foundation maintains the current stable major release of Python.
Ah, maintains is indeed better than supports. That's what we do: we maintain Python. Regards, Martin
"Martin v. Löwis" writes:
Of course the PSF provides *excellent* technical support; you just don't acknowledge any *obligation* to do it. A declaration of support is not a warranty, of course. So I see no problem with using the word "support". You may wish to clarify with terms like "resources available".
Why do you need such a statement?
Because it expresses what IMO *actually happens* clearly, and clarifies the intent of the PSF to continue in the same way. This is useful to users making decisions, even though the PSF owns few to none of the resources needed. The generosity of the contributors and their loyalty to Python and to each other practically guarantees availability. Python can dispose of a raft of bugs present only in the older versions with WONTFIX at release of a new stable version (after double-checking that they don't exist in the stable version). Developers can respond to reports of bugs in the immediate past version with "I'm sorry, but we try to concentrate our limited resources on supporting the current version, and it is unlikely that it will be fixed. Please post to c.l.p for help." Users are disappointed, but it builds trust, and more so if supported by an official statement.
I'm all in favor of formalizing a policy of when Python releases are produced, and what Python releases, and what kinds of changes they may contain. However, such a policy should be addressed primarily to contributors, as a guidance, not to users, as a promise. So I have problems with both "official" and "support" still.
The way we make policy statements is through the PEP process. This is important, because it involves the community in setting the policy. The PSF board has often explicitly tried to stay out of managing the Python development itself, and has deferred that to python-dev and its readership. I had meant to propose a PEP on maintenance of Python releases for quite some time now; perhaps this is the time to actually write this PEP. Regards, Martin
"Martin v. Löwis" writes:
I see your point, but I don't see how you propose to keep the users from viewing the guidelines to developers as official policy regarding support, albeit hard to interpret. Also, it may just be me, but I don't see an official statement as a "promise". It's a "clarification". '''This is what we're trying to do, so you can make well-informed plans, and not be surprised when you ask for something and we say "but we never thought about doing that, and don't intend to".'''
The way we make policy statements is through the PEP process.
Creating the statement that way is important. But publishing a PEP is not enough. Non-developer users don't read PEPs. After thinking about it a bit, I do agree that "maintain" is more appropriate than "support" (this is after my reply to Terry Reedy, where I wrote that support was OK). Support implies education and adaptation to user needs, but even if that is done by the PSF, it's a separate activity from the development and release processes. While maintenance does include response to user bug reports as part of the development/release process.
And that's fine if they do. I don't mind if a statement is considered official if it is - a BDFL pronouncement, or - the result of a PSF board or members vote Otherwise, it isn't "official". There are other "officers" which can make official statements, e.g. the release manager can also make official statements, but anybody else's statement is just an opinion.
Right. It's fine to rephrase (para-phrase?) the consensus achieved in a PEP. However, that rephrasing cannot precede the PEP.
That was exactly my concern about "support". I associate with "support" that there is a hotline I can call and they will help me. I've used various support infrastructures in the past years (from Microsoft, Dell, Veritas/Symantec), and in all cases, "support" meant that somebody would help me with a specific problem. "Unsupported product" then means "if you have a problem with that product, we won't help". There is good and bad support, of course, and I know which companies provided me good support and which didn't. There are indeed various support channels for python: comp.lang.python, python-tutors, and python-help, and none of them have the notion of "unsupported Python releases". Thing become unsupported by no volunteer being willing to offer help. It's also important to understand that the bug tracker is *not* a means of user support, even though users sometimes mistake it to be so, and end their "bug report" with a call for help. It's vice versa: a bug report is a *contribution* by the user, i.e. a means for giving a gift, not for requesting one. Regards, Martin
participants (10)
-
"Martin v. Löwis" -
Anthony Baxter -
Barry Warsaw -
Fred L. Drake, Jr. -
Nick Coghlan -
skip＠pobox.com -
Stephen J. Turnbull -
Steve Holden -
Terry Reedy -
Tony Nelson