"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." _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
