Re: [Python-Dev] Official version support statement
Terry Reedy writes: 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. 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Official version support statement
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). 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. 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. 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Draft PEP: Maintenance of Python Releases
This PEP attempts to formalize the existing practice, but goes beyond it in introducing security releases. The addition of security releases addresses various concerns I heard over the last year about Python being short-lived. Those concerns are typically raised by Linux distributors which see that they have to maintain Python releases much longer than python-dev does, and are now concerned about the manpower and Python expertise they need. When looking in detail, they are primarily concerned with security fixes. They will not add new features to old releases, and they can ignore bug fixes, but they cannot ignore security fixes. So what I really think they want is some form of commitment that security fixes are still considered for a much longer period of time. In discussions, people often consider short-lived as shorter than five years. So the PEP proposes to produce security releases for five years after the initial release; this would mean that we are willing to make security releases for 2.3 (until July 2008) and 2.4 (until November 2009). To reduce the work-load, the PEP promises no more than one security release per branch per year (if no security fixes get contributed, no release needs to be made). Notice that this setup significantly relies on *no* bug fixes (other than security fixes) being committed to a branch after the final bugfix release. Addition of bug fixes would require much more extensive testing, with release candidates and everything, so it is essential that there are very very few new patches in each security release. Please let me know what you think. Regards, Martin PEP: XX Title: Maintenance of Python Releases Version: $Revision$ Last-Modified: $Date$ Author: Martin v. Löwis [EMAIL PROTECTED] Discussions-To: python-dev@python.org Status: Draft Type: Process Content-Type: text/x-rst Created: 12-May-2005 Abstract This PEP defines the policy for the maintenance of release branches for Python. Overview The Python core developers maintain two major branches at any point in time: the trunk, which will eventually become the next major release, and the current release branch, from which bug-fix releases are made. As a special case, the number of branches may duplicate while Python 2.x and Python 3.x is developed in parallel. Older releases of Python see no regular maintenance, however, security flaws will be fixed in older releases, eventually resulting in a security release. Major Releases == Major releases are numbered x.y (despite the .y being commonly named minor release in other projects). The release process is described in PEP 101. Major releases should be produced roughly every 18 months, but the actual release frequency may vary significantly. With a major release x.y, this release becomes the current release. For the previous current release (x.(y-1)), a final bug fix release is produced shortly after the x.y release. Bugfix Releases === Bug fix releases (numbered x.y.z) are described in PEP 6. As stated there, they may only include bug fixes (no new features), and they are produced typically every six months. Bug fixes should be committed to the release branch as an ongoing activity (e.g. along with fixing them in the trunk), rather than being backported just before the release. After the final bug fix release for a branch has been made, the branch becomes unmaintained except for security fixes. No bug fix patches must be applied to the branch. Security Releases = As users operate Python releases long after the release branch has become unmaintained, they still like to see security patches fixed. The Python source repository can act as a repository for security fixes even after the branch has become unmaintained. Users wishing to contribute security patches must clearly indicate that a certain patch is a security patch, and to what branches they want to see it applied. Commit messages of security patches on unmaintained branches must indicate that the commit was done for security reasons; an explicit description of potential exploits should be avoided. A security fix must not risk the releasability of the branch, i.e. the maintenance branch should be in a shape to produce a release out of it as-is at all times. From time to time, security releases will be made from an unmaintained branch. A security release will be a source-only release (i.e. no Windows or Macintosh binaries are provided); they will follow the numbering of minor releases (i.e. x.y.z). Security releases should be made at most one year after a security patch has been committed to the branch; users wishing to deploy security patches earlier can safely export the maintenance branch, or otherwise incorporate all committed security fixes into their code base. Security releases should be made for a period of five years after the initial major release. Copyright = This document has been placed in the public domain. ..
Re: [Python-Dev] Draft PEP: Maintenance of Python Releases
Martin v. Löwis wrote: Please let me know what you think. This appears to be an accurate description of the way releases have been handled for the last few years (which appears to be working well), so +1 here. Regards, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] New operations in Decimal
Tim Peters wrote: [Raymond Hettinger] ... My intention for the module is to be fully compliant with the spec and all of its tests. Code written in other languages which support the spec should expect to be transferrable to Python and run exactly as they did in the original language. I'm with Raymond on this one, especially given the triviality of implementing the revised spec's new logical operations. After thinking about it some more, I'm also supporting maintaining full compliance (and withdrawing my suggestion of using a separate subclass for the logical operands). Be maintaining full compliance, it should be possible for a developer to prototype an algorithm using Python's decimal module and then use that exact same algorithm on any GDS compliant arithmetic logic unit. While *Python* has the luxury of other means of doing logical operations, an embedded algorithm with only a decimal ALU available may not be so fortunate. Regards, Nick. P.S. Spending an hour at work yesterday discussing some of the ways the bus architecture of a digital signal processor can affect algorithm performance may have had more than a little to do with my change of heart ;) -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Official version support statement
Martin v. Löwis writes: 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. 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Official version support 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. 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. 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. 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. Right. It's fine to rephrase (para-phrase?) the consensus achieved in a PEP. However, that rephrasing cannot precede the PEP. 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. 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Draft PEP: Maintenance of Python Releases
Martin v. Löwis writes: A security fix must not risk the releasability of the branch, i.e. the maintenance branch should be in a shape to produce a release out of it as-is at all times. [...] Security releases should be made at most one year after a security patch has been committed to the branch; users wishing to deploy security patches earlier can safely export the maintenance branch, or otherwise incorporate all committed security fixes into their code base. Security releases should be made for a period of five years after the initial major release. I don't understand the point of a security release made up to a year after commit, especially in view of the first quoted paragraph. A commit may not be made without confirming *immediate* releasability. Isn't that the painful part of a release? If so, shouldn't an immediate release should be made, and not be that much burden? (At least in my practice, all that's left is an announcement -- which is going to be about 2 lines of boilerplate, since detailed explanations are prohibited -- and rolling tarballs.) If rolling tarballs etc is considered a burden, a tag release could be made. OS distributors are going to import into a vendor branch anyway, what they want is python-dev's certification that it's been checked and (as much as possible given the urgency of a security patch) is safe to apply to their package trees. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft PEP: Maintenance of Python Releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 12, 2007, at 4:29 AM, Martin v. Löwis wrote: This PEP attempts to formalize the existing practice, but goes beyond it in introducing security releases. The addition of security releases addresses various concerns I heard over the last year about Python being short-lived. Those concerns are typically raised by Linux distributors which see that they have to maintain Python releases much longer than python-dev does, and are now concerned about the manpower and Python expertise they need. Martin, I like this PEP; it addresses the issues I was trying to get at with my initial posting[1]. Stephen brings up some interesting points which I'll comment on in a follow up to his post. Since one of the major focuses of this PEP is security releases, I wonder if we shouldn't mention that security issues should be reported to security at python dot org instead of public forums or trackers, so that the Python Security Response Team can take the appropriate and responsible actions? - -Barry [1] I still think we should craft some text for the website, but it can now be as simple as: For the policy on Python version maintenance and release, see PEP XXX. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) iD8DBQFGRdXb2YZpQepbvXERAudHAKCxlTXyO15aRS0GypVKbP0U/y3bCACfVrX6 2TcbU5/oe7GiIwhesRsT45g= =dcr9 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Draft PEP: Maintenance of Python Releases
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On May 12, 2007, at 9:02 AM, Stephen J. Turnbull wrote: I don't understand the point of a security release made up to a year after commit, especially in view of the first quoted paragraph. A commit may not be made without confirming *immediate* releasability. Isn't that the painful part of a release? If so, shouldn't an immediate release should be made, and not be that much burden? (At least in my practice, all that's left is an announcement -- which is going to be about 2 lines of boilerplate, since detailed explanations are prohibited -- and rolling tarballs.) Security releases should be coordinated with the Python Security Response Team (security at python dot org). There are legitimate reasons for wanting to coordinate security releases with this team, such as to ensure adequate and responsible reporting to vendors and other security organizations. Once a set of patches have been generated and (after an embargo period) committed to the public repository, I think we should indeed make a release fairly quickly. If rolling tarballs etc is considered a burden, a tag release could be made. OS distributors are going to import into a vendor branch anyway, what they want is python-dev's certification that it's been checked and (as much as possible given the urgency of a security patch) is safe to apply to their package trees. I don't think rolling out tarballs is all that much additional burden once everything else is said and done, so I think we should do it. I don't want to give Anthony more work than he wants to do, but I feel confident we can find volunteers to roll out the tarballs if necessary. I would certainly offer to do so. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (Darwin) iD8DBQFGRdyX2YZpQepbvXERAm8RAJ9GhDaT6UKTY8YCLKRUPV75Nb0IgQCcCm38 O9/TyXRgB1sR8T97PhqxZ2I= =wA9j -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Official version support statement
Stephen J. Turnbull [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | 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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Tracker Issues
ACTIVITY SUMMARY (05/06/07 - 05/13/07) Tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1650 open ( +0) / 8584 closed ( +0) / 10234 total ( +0) Average duration of open issues: 791 days. Median duration of open issues: 743 days. Open Issues Breakdown open 1650 ( +0) pending 0 ( +0) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Official version support statement
Terry Reedy writes: Stephen J. Turnbull [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | 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. 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Tracker Issues
On 5/12/07, Tracker [EMAIL PROTECTED] wrote: [...] I clicked on the tracker link out of curiosity noticed that the tracker has been spammed -- issues 1028, 1029 and 1030 are all spam (1028 seems a test by the spammer). These issues should be deleted and their creator's accounts disabled. BTW What's the hold-up for making roundup live? I'm sick of sf. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Tracker Issues
On 5/12/07, Guido van Rossum [EMAIL PROTECTED] wrote: On 5/12/07, Tracker [EMAIL PROTECTED] wrote: [...] I clicked on the tracker link out of curiosity noticed that the tracker has been spammed -- issues 1028, 1029 and 1030 are all spam (1028 seems a test by the spammer). We know. Skip is working on something for this. These issues should be deleted and their creator's accounts disabled. The user accounts will be created from scratch when we do the actual transition. Plus all of the existing tracker items will be wiped. BTW What's the hold-up for making roundup live? I'm sick of sf. Well, the tracker you are sick of is holding us up. The data dump that we were depending on stopped working properly last month. We are trying to bug them to fix it as they don't see any issues with it while all of us cannot get a complete dump. -Brett -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Official version support statement
Stephen J. Turnbull [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | 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!) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
