[Python-Dev] Draft PEP: Maintenance of Python Releases (original) (raw)

Barry Warsaw barry at python.org
Tue May 15 16:01:40 CEST 2007

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On May 14, 2007, at 7:19 PM, Martin v. Löwis wrote:

Still, I'm in agreement with you that the repository holds the security patches and that the tarballs are a convenience. They are an important convenience though, so I would say that they should be released in a timely manner after the commit of the security patches. I don't think we need to be that exact about spelling out when that happens.

(I personally would like to see it within "weeks" of a security patch, not "months" or "years".) Couldn't that lead to many more 2.x.y releases in the "security fixes" period than in the "active maintenance" period? For active maintenance, we don't do roll security fixes into releases more often than every six months. I would dislike a quick succession of 2.3.7, 2.3.8, 2.3.9, etc. (also because these numbers should not grow above 10 :-)

I think we could reasonably batch security releases, if we know that
there are a few critical issues in the pipeline. That ought to be
part of the job of the PSRT. Personally, I don't care much if the
micro release number goes above 10 although I know there are many
here who don't like that. We should definitely try to reduce churn.
It's a balancing act.

Also, I would like to document explicit that it is the responsibility of the PSRT (or its designate) to commit security patches to revision control. The act of committing these patches is a public event and has an important impact on any embargoes agreed upon by the PSRT with other organizations. I also disagree. Regular committers should continue to do that. I haven't seen a single activity from the PSRT (or, perhaps one), so for all I can tell, it doesn't exist. If a security patch is reported to the Python bug tracker, it's as public as it can get.

Right, but hopefully people know to report them to security at python
dot org instead. Also hopefully, the new tracker will support
private/security bug reports that won't be made public (I don't
actually know if this is the case or not).

If PSRT members (who are they, anyway) also happen to be committers, they can commit these changes at the time the PSRT deems appropriate. If they are not committers, they need to post the patch to SF as anybody else.

(you can tell that I come from a country where people are quite skeptical about the secret service).

There's no secret police here, since almost anyone who's foolish
enough to volunteer to do some work could easily infiltrate that most
cloistered of organizations.

I believe there is value in having a PSRT that coordinates security
reports, fixes, and disclosures. If the community disagrees, that's
cool. But in that case there's not much point in a security at
python dot org mailing list or a PSRT, so let's disband them.

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBRkm9RHEjvBPtnXfVAQKO5gP+IE+AhsUo28ayVojGWbIyupV0eIYBrOke R+Hvulllcr9LAVmlxlWNZV+TeReavKL+SSzmoyzj/Dv2U5szvTRld7Ca4PBl+mJ8 mfyjqg6uWp1At4OVhf93J6JCrLZkw2sY1lH+yAfcvmxivTr7Rf5+vugDJ822enUt pKtcowVQCwI= =ms5P -----END PGP SIGNATURE-----

More information about the Python-Dev mailing list