Python 2.5.3: call for patches

[Martin v. Löwis]

Within a few weeks, we will release Python 2.5.3. This will be the last
bug fix release of Python 2.5, afterwards, future releases of 2.5 will
only include security fixes, and no binaries (for Windows or OSX) will
be provided anymore (from python.org).

In principle, the release will include all changes that are already on
the release25-maint branch in subversion [1]. If you think that specific
changes should be considered, please create an issue in the bug tracker
[2], and label it with the 2.5.3 version. Backports of changes that
are already released in Python 2.6 but may apply to 2.5 are of
particular interest.

Regards,
Martin

[1] http://svn.python.org/projects/python/branches/release25-maint/
[2] http://bugs.python.org/

 

[Terry Reedy]

I'm glad to see this. Thank you to all involved in the ongoing work of
coordinating Python releases.

Can I request, in the interest of reducing confusion, that any
announcements of pre-release versions of 2.5.3 (or any other Python
release) be announced *without* saying “RELEASED: A not-really-release
version of Pythonâ€.

It's very confusing to see a progression of announcements with subject
fields like:

RELEASED: Python 2.8.not-ready-yet
RELEASED: Python 2.8.alpha-1
RELEASED: Python 2.8.beta-1
RELEASED: Python 2.8.beta-2
RELEASED: Python 2.8 release candidate 1
RELEASED: Python 2.8 release candidate 2
RELEASED: Python 2.8 final

I disagree. These say exactly what has happened and tell me what I want
to know, which is that something new has been released, which is to say,
made available for download.

[ANN] Python 2.8.not-ready-yet
[ANN] Python 2.8.alpha-1
[ANN] Python 2.8.beta-1
[ANN] Python 2.8.beta-2
[ANN] Python 2.8 release candidate 1
[ANN] Python 2.8 release candidate 2
[ANN] Python 2.8 final

That, to me at least, communicates what's actually happening far
better and leads to less confusion about what the state of release is.

I disagree. [ANN] could mean anything: planned? canceled? needs help?
("Oh, 'released', why didn't you say so?") It says nothing about what
is happening or the state of a 'distribution' but merely states a topic.
Martin's post announced Python 2.5.3 as the topic, but then went on to
request a specific type of help. I presume you would not be happy
either with "[ANN] Python x.y.whatever released".

If you want RELEASED replaced, suggest something short and not too ugly
that communicates "posted at python.org and available to be downloaded,
installed, tested, and used" at least as well. (I am currently using
3.rc1; the remaining problems do not currently affect me and I accept
the risk, which I view as small, that further changes will affect code I
write now.)

tjr

 

[Martin v. Löwis]

Is there some policy document or release management guide that could

be updated for release teams to follow on this without needing to have
this discussion every time?

It's in PEP 101. If it matters to you, please submit a patch to that
document (which is in subversion) to bugs.python.org. It doesn't matter
to me very much; English is not my native language (i.e. RELEASED is
about as good SEREALED).

Regards,
Martin

 

[skip]

Ben> Is there an appropriate email destination for such patches?

You might try (e-mail address removed).

 

[Benjamin]

Thank you.


Can do.


Requires registration and management of yet another online identity
:-(

And yet one that will never let you down.

 

[troelswh]

In principle, the release will include all changes that are already on
the release25-maint branch in subversion [1]. If you think that specific
changes should be considered, please create an issue in the bug tracker
[2], and label it with the 2.5.3 version. Backports of changes that
are already released in Python 2.6 but may apply to 2.5 are of
particular interest.

There is a number of Python 2.5.2 security vulnerabilities registered
with CVE. It would be great if the 2.5.3 release included fixes for
all of these!

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3144
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3142
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2316
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2315
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1887
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1721
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1679

For some reason none of these have made it into Python security
advisories (http://www.python.org/news/security/), but many vendors
who ship Python have released patched versions already.

Regards,
Troels

 

[Michael Ströder]

In principle, the release will include all changes that are already on
the release25-maint branch in subversion [1]. If you think that specific
changes should be considered, please create an issue in the bug tracker
[2], and label it with the 2.5.3 version. Backports of changes that
are already released in Python 2.6 but may apply to 2.5 are of
particular interest.

There is a number of Python 2.5.2 security vulnerabilities registered
with CVE. It would be great if the 2.5.3 release included fixes for
all of these!

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3144
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3142
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2316
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2315
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1887
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1721
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1679
Yes!

For some reason none of these have made it into Python security
advisories (http://www.python.org/news/security/), but many vendors
who ship Python have released patched versions already.

Yes, this is strange. I asked for this a couple of weeks ago. That the
upstream release is behind the packages shipped by vendors regarding
security patches is pretty poor.

Ciao, Michael.

 

[Terry Reedy]

In principle, the release will include all changes that are already on
the release25-maint branch in subversion [1]. If you think that specific
changes should be considered, please create an issue in the bug tracker
[2], and label it with the 2.5.3 version. Backports of changes that
are already released in Python 2.6 but may apply to 2.5 are of
particular interest.

There is a number of Python 2.5.2 security vulnerabilities registered
with CVE. It would be great if the 2.5.3 release included fixes for
all of these!

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3144

This references
http://bugs.python.org/issue2588
http://bugs.python.org/issue2589
both of which report fixes backported to 2.5.3
I will let you investigate whether the name is true of the rest, or
whether someone should be nudged to either report or submit a patch
or help review a patch.

http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-3142
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2316
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2315
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1887
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1721
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1679

For some reason none of these have made it into Python security
advisories (http://www.python.org/news/security/), but many vendors
who ship Python have released patched versions already.

Presumably, none were considered really critical, or the volunteer core
developers were busy doing something else. Also, release schedules differ.

 

[Steven D'Aprano]

Which is entirely different from the “release†implicit in e.g. “release
candidateâ€, hence they don't say what they appear to say. Since the
latter term is unlikely to change, I'm asking that the announcements
don't unnecessarily overload the meaning of “releaseâ€.

I've always hated the term "release candidate". It's been released, it is
a release. A release candidate is something which may be released, but
hasn't yet been chosen.

I disagree. [ANN] could mean anything: planned? canceled? needs help?
("Oh, 'released', why didn't you say so?")

As above, “released†is a poor term for this, since it *already* has
connotations of “all done, out the door, ready to go†as evidenced
in “release candidate†(not released, but we think it could be) and
the distinction of the triumphant announcements that accompany
*actual* releases.

I think you have it completely backwards. It's quite possible, even
sensible, to release a draft paper, release an experimental prototype, or
release an alpha version of software. I don't agree that "release" has
any connotations of "all done" at all. Being released and being ready for
release are orthogonal concepts: patients can be released from hospital
before they are ready, and software can be released before it is in a fit
state for production.

I don't know how some people have started using "released" to mean
"production-ready", but it makes no sense to me and I wish they would
stop. I think it is a poorly thought-out practice and it leads to people
being confused when inaccurately titled "pre-release" versions are
released.


[...]

Whatever is chosen, please reserve “RELEASED†for the
commonly-expected meaning of something akin to “no longer in
intensive development or bug-hunting mode, now ready to go out on its
own and be used with abandon by the massesâ€.

Commonly expected by who? That's certainly not any meaning of "released"
in any dictionary I know of.

 

[Terry Reedy]

I've always hated the term "release candidate". It's been released, it is
a release. A release candidate is something which may be released, but
hasn't yet been chosen.

I agree. They are candidates for the final release. Suffix .c1, etc,
instead of .rc1 would be sufficient.