[Python-Dev] Draft PEP: Maintenance of Python Releases
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