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

Stephen J. Turnbull stephen at xemacs.org
Mon May 14 17:32:39 CEST 2007

"Martin v. Löwis" writes:

The objective is to reduce load for the release manager. Any kind of release that is worth anything takes several hours to produce, in my experience (if it could be made completely automatic, it wouldn't be good, since glitches would not be detected).

I absolutely agree.

See PEP 101. A release involves many more steps, and it's not clear whether a release candidate could be skipped.

My point is that if those steps are required for a release, the branch is not "immediately releasable" by my standards if they're not done. Especially if a release candidate is required.

I guess you only meant that a security commit must meet the technical requirements of any other commit (plus being a security fix, of course), so that the release process can be started at any time?

In general, I recognize the burden on the release engineer, and obviously any burdensome policy needs his OK. But I think the policy should be effective too, and I just don't see that a policy that allows such long lags is a more effective security response than a policy that says "the tarballs are deprecated due to security fixes; get your Python by importing the branch, not by fetching a tarball."

More information about the Python-Dev mailing list