[Python-Dev] Draft PEP: Maintenance of Python Releases
barry at python.org
Tue May 15 16:01:40 CEST 2007
-----BEGIN PGP SIGNED MESSAGE-----
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
>> patches and that the tarballs are a convenience. They are an
>> 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
>> we need to be that exact about spelling out when that happens.
>> (I personally would like to see it within "weeks" of a security
>> 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
> 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
> 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)
-----END PGP SIGNATURE-----
More information about the Python-Dev