RetroSearch Browse

Mon May 14 17:32:39 CEST 2007 · https://mail.python.org/pipermail/python-dev/2007-May/073131.html

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

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2007-May/073131.html below:

[Python-Dev] Draft PEP: Maintenance of Python Releases