Re: [Python-Dev] Official version support statement

2007-05-12 Thread Stephen J. Turnbull
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

Re: [Python-Dev] Official version support statement

2007-05-12 Thread Martin v. Löwis
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,

[Python-Dev] Draft PEP: Maintenance of Python Releases

2007-05-12 Thread Martin v. Löwis
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

Re: [Python-Dev] Draft PEP: Maintenance of Python Releases

2007-05-12 Thread Nick Coghlan
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

Re: [Python-Dev] New operations in Decimal

2007-05-12 Thread Nick Coghlan
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.

Re: [Python-Dev] Official version support statement

2007-05-12 Thread Stephen J. Turnbull
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.

Re: [Python-Dev] Official version support statement

2007-05-12 Thread Martin v. Löwis
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

[Python-Dev] Draft PEP: Maintenance of Python Releases

2007-05-12 Thread Stephen J. Turnbull
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

Re: [Python-Dev] Draft PEP: Maintenance of Python Releases

2007-05-12 Thread Barry Warsaw
-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

Re: [Python-Dev] Draft PEP: Maintenance of Python Releases

2007-05-12 Thread Barry Warsaw
-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*

Re: [Python-Dev] Official version support statement

2007-05-12 Thread Terry Reedy
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

[Python-Dev] Summary of Tracker Issues

2007-05-12 Thread Tracker
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.

Re: [Python-Dev] Official version support statement

2007-05-12 Thread Stephen J. Turnbull
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

Re: [Python-Dev] Summary of Tracker Issues

2007-05-12 Thread Guido van Rossum
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

Re: [Python-Dev] Summary of Tracker Issues

2007-05-12 Thread Brett Cannon
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

Re: [Python-Dev] Official version support statement

2007-05-12 Thread Terry Reedy
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