I don't understand the point of a "security release" made up to a year after commit, especially in view of the first quoted paragraph.
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 would like get Anthony's opinion on this aspect.
A commit may not be made without confirming *immediate* releasability. Isn't that the painful part of a release? If so, shouldn't an immediate release should be made, and not be that much burden? (At least in my practice, all that's left is an announcement -- which is going to be about 2 lines of boilerplate, since detailed explanations are prohibited -- and rolling tarballs.)
See PEP 101. A release involves many more steps, and it's not clear whether a release candidate could be skipped.
I think we would need to restrict the total number of releases made per year. The one-year limit may be debatable, and immediate releases might be possible, as long as there is some provision that releases are not made at a too-high rate.
If rolling tarballs etc is considered a burden, a "tag release" could be made. OS distributors are going to import into a vendor branch anyway, what they want is python-dev's certification that it's been checked and (as much as possible given the urgency of a security patch) is safe to apply to their package trees.
I think OS distributors typically *do* use official tar balls, even if they import them as a vendor branch somewhere. Also, creating the tar ball is not the only activity: creating a new web page on pydotorg, running the test suite, etc. all is still necessary.
In any case, the patch gets certified by being committed (with the indication that it is a security fix), so if they want certified patches, they can just import the maintenance branch.