[Python-Dev] Draft PEP: Maintenance of Python Releases
"Martin v. Löwis"
martin at v.loewis.de
Sun May 13 21:19:37 CEST 2007
> 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.
Regards,
Martin
More information about the Python-Dev
mailing list