-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On May 12, 2007, at 9:02 AM, Stephen J. Turnbull wrote:
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. 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.)
Security releases should be coordinated with the Python Security Response Team (security at python dot org). There are legitimate reasons for wanting to coordinate security releases with this team, such as to ensure adequate and responsible reporting to vendors and other security organizations. Once a set of patches have been generated and (after an embargo period) committed to the public repository, I think we should indeed make a release fairly quickly.
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 don't think rolling out tarballs is all that much additional burden once everything else is said and done, so I think we should do it. I don't want to give Anthony more work than he wants to do, but I feel confident we can find volunteers to roll out the tarballs if necessary. I would certainly offer to do so.
- -Barry