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

["Martin v. Löwis"]

> 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.

Regards,
Martin