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.
But how does that help in practice? If you find after the release that the branch was not in a releasable state, will you fire your employee that caused the mess-up? Even though no problems are expected, you still have to *check* whether there are problems, and that is time-consuming. Better safe than sorry
(at least, this is what I understand Anthony Baxter's position on release engineering is - and I agree with that view).
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?
Exactly. I wouldn't require the release manager to actually commit all security patches - and requiring so would be the only way to guarantee that the branch is releasable (i.e. you have to release it to be sure).
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."
In effect, this is what the PEP says. That's intentional (i.e. it is my intention - others may have different intentions). It's the repository that holds the security patches; the tarballs (and the version number bumps) are just a convenience.