"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 ge
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
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 W
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)
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.
Medi
"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
-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 *immediat
-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 yea
"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 commi
> > 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 pr
"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 prom
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
>> la
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
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
> 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
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.
Impl
>> 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 curr
17 matches
Mail list logo
