> 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4