Python 2.5.3: call for patches

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

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/pytho...lease25-maint/
[2] http://bugs.python.org/

[Ben Finney]

"Martin v. Löwis" <ma****@v.loewis.dewrites:

Within a few weeks, we will release Python 2.5.3.

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

The word “RELEASED� is a strong indicator that a new version of
Python (in this case) is *released*, not merely available in a
pre-release form. The only one that qualifies in the above list is the
last one where Python 2.8 is *actually* released. Otherwise, the word
becomes overburdened with too many meanings and doesn't indicate
anything strongly.

It would be much less confusing if the word “release� in such
announcements was reserved for the release *of that version* (in this
case, 2.8), and not for the availability of some pre-release. Perhaps
simply using the word “ANNOUNCED� or abbreviated “ANN�:

[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 recall making this point some while ago to positive effect (thank
you!), but it seems to have been ignored in the recent progression of
announcements for Python 2.6. I didn't want to complain at that point,
with such a good job being done otherwise by the Python 2.6 release
team.

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?

--
\ “I used to work in a fire hydrant factory. You couldn't park |
`\ anywhere near the place.� —Steven Wright |
_o__) |
Ben Finney

[Terry Reedy]

Ben Finney wrote:

"Martin v. Löwis" <ma****@v.loewis.dewrites:

>Within a few weeks, we will release Python 2.5.3.

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

[Ben Finney]

Terry Reedy <tj*****@udel.eduwrites:

Ben Finney wrote:

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.

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 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 presume you would not be happy either with "[ANN] Python
x.y.whatever released".

I hope it's clear why that's so, yes.

(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.)

Note that you are using a “release candidate�, i.e. a version of
software *that has not yet been released*. It would surely be clearer
if the availability of that version were not announced with an
implication that the software is both released and not-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 suggest “AVAILABLE�, then, to clearly limit the scope of what
state is being announced.

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�.

--
\ “The generation of random numbers is too important to be left |
`\ to chance.� —Robert R. Coveyou |
_o__) |
Ben Finney

[=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=]

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

[Ben Finney]

"Martin v. Löwis" <ma****@v.loewis.dewrites:

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.

Thank you.

If it matters to you, please submit a patch to that document (which
is in subversion)

Can do.

to bugs.python.org.

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

Is there an appropriate email destination for such patches?

--
\ “You've got the brain of a four-year-old boy, and I'll bet he |
`\ was glad to get rid of it.� —Groucho Marx |
_o__) |
Ben Finney

[skip]

BenIs there an appropriate email destination for such patches?

You might try re****@bugs.python.org.

[Ben Finney]

sk**@pobox.com writes:

BenIs there an appropriate email destination for such patches?

You might try re****@bugs.python.org.

Thank you.

--
\ “I put contact lenses in my dog's eyes. They had little |
`\ pictures of cats on them. Then I took one out and he ran around |
_o__) in circles.� —Steven Wright |
Ben Finney

[Benjamin]

On Oct 8, 12:42*am, Ben Finney <[e-mail]>
wrote:

"Martin v. Löwis" <[e-mail]:

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.

Thank you.

If it matters to you, please submit a patch to that document (which
is in subversion)

Can do.

to bugs.python.org.

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

And yet one that will never let you down. :)

[troelswh]

On Oct 7, 9:27*am, "Martin v. Löwis" <[e-mail]:

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...=CVE-2008-3144
http://cve.mitre.org/cgi-bin/cvename...=CVE-2008-3142
http://cve.mitre.org/cgi-bin/cvename...=CVE-2008-2316
http://cve.mitre.org/cgi-bin/cvename...=CVE-2008-2315
http://cve.mitre.org/cgi-bin/cvename...=CVE-2008-1887
http://cve.mitre.org/cgi-bin/cvename...=CVE-2008-1721
http://cve.mitre.org/cgi-bin/cvename...=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

[=?ISO-8859-1?Q?Michael_Str=F6der?=]

tr******@gmail.com wrote:

On Oct 7, 9:27 am, "Martin v. Löwis" <[e-mail]:

>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...=CVE-2008-3144
http://cve.mitre.org/cgi-bin/cvename...=CVE-2008-3142
http://cve.mitre.org/cgi-bin/cvename...=CVE-2008-2316
http://cve.mitre.org/cgi-bin/cvename...=CVE-2008-2315
http://cve.mitre.org/cgi-bin/cvename...=CVE-2008-1887
http://cve.mitre.org/cgi-bin/cvename...=CVE-2008-1721
http://cve.mitre.org/cgi-bin/cvename...=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]

tr******@gmail.com wrote:

On Oct 7, 9:27 am, "Martin v. Löwis" <[e-mail]:

>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...=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...=CVE-2008-3142
http://cve.mitre.org/cgi-bin/cvename...=CVE-2008-2316
http://cve.mitre.org/cgi-bin/cvename...=CVE-2008-2315
http://cve.mitre.org/cgi-bin/cvename...=CVE-2008-1887
http://cve.mitre.org/cgi-bin/cvename...=CVE-2008-1721
http://cve.mitre.org/cgi-bin/cvename...=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]

On Wed, 08 Oct 2008 08:19:33 +1100, Ben Finney wrote:

>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.

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.


--
Steven

[Terry Reedy]

Steven D'Aprano wrote:

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.