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

Barry Warsaw barry at python.org
Sat May 12 17:26:14 CEST 2007

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

Version: GnuPG v1.4.6 (Darwin)


More information about the Python-Dev mailing list