[Python-Dev] Draft PEP: Maintenance of Python Releases
"Martin v. Löwis"
martin at v.loewis.de
Mon May 14 23:29:33 CEST 2007
> 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.
More information about the Python-Dev