Mike Miller writes:
Sounds like automating until it is "just a push of a button," should be a goal. According to Victor there has been progress, but always room for more.
When XEmacs was releasing betas regularly, everything from tagging the local authoritative repo to pushing to the public repo to making tarballs to signing and authenticating them to Mad-Libbing the form for announcement was invocation of a single script. "Somehow" the typical release was a me-day's work and three calendar days (and unlike GNU Emacs with its "kitchen sink" standard library or Python with its batteries from CR-25s to Prius power replacements, XEmacs was just the Lisp interpreter and basic editor functions).
What takes the time?
1. A courtesy pre-announcement to core devs that the release was coming (yes, it's on the schedule, no, they don't check their calendars). 2. Triaging incomplete tasks other folks labeled as "important" or above. 3. Writing news (somebody always forgets, and typically the choice was write it myself or delay the release). 4. Triaging last-minute "urgent" commits. (They rarely were.) 5. Triaging and where possible fixing test failures. 6. Rolling back premature commits. 7. Scheduling future work that didn't *need* to be in a beta release (we had a couple of developers who were trying but couldn't write documentation grammatically to save their commits; it just didn't make sense to force them to do work I could do in 1/10 the effort). 8. Coordination with the dev who built Windows installers. (A few Windows users could get pretty cranky if they didn't get an installer within a couple hours after the Unix-oriented tarball releases.)
The Python process is more disciplined, and has a lot of automation to help with the QA stuff. But there's always last-minute "people work", which is what Brooks would call an "essential difficulty." It's pretty irreducible. I would imagine the same is true for Python RMs.
I would argue that security releases are of higher importance than most,
*Some* of them are, but this just isn't true most of the time. Take the very recent CVE-2021-3177, rated 9.8 ("critical", 9.8 out of 10, I believe) because it *might* lead to remote code execution (RCE) under (implausible, AFAICS) conditions in current Python. There is no RCE exploit for arbitrary Python webapps: there are a bunch of other conditions that must be satisfied. It might be possible to create a denial of service for some webapps, but that still depends on only somewhat more plausible conditions.
Then, why 9.8? Well, "remote code execution". The critical rating is a *threat* assessment, based on *everything* going right for the attacker, not a *risk* assessment, based on likelihood and degree of damage. Most reported vulnerabilities have no known exploit and potential RCE is not the common case: risk is quite small.
Such vulnerabilities must be fixed: as time goes on, risk increases. Not just more time = more time for the black hats, but the hazard rate increases too. The particular currently implausible kill chain may be generalized or others may arise in future versions of Python, or more webapps may incorporate the risky behavior, etc. But there's no reason to believe it will be a known exploit soon, and anybody with a million dollars at risk can (and should) keep a couple of hours of junior developer time on call to assess risk and apply the patch if needed. Not to mention that in 2025 there will still be a bunch of vulnerable 3.8 and 3.9 installations online, which are still whatever the patchlevel was when they were originally installed.
I believe that had they let this one wait until the scheduled release, the odds are 1000:1 that *no harm whatsoever* would have been done in that window. Nevertheless, the relevant release managers (3.8, 3.9, and Windows) chose to make a quick release. I think "customer relations" (which are important, I'm not deprecating them!) had as much to do with the decision as the assessment of risk to Python users. I am not going to second-guess the actual decision, but I do think that this is very much a case by case issue not very different from any "urgent" defect, and in many cases "wait for scheduled release" is going to be a no-brainer, and in others that will be the outcome chosen.
Some of the time, there will be an emergency release. That has been demonstrated to be possible and realistic, even in a case like this where the need is not open-and-shut. I don't see a need for anything except more love for the release managers. Of course IWBNI we had the resources to pay release managers. But we're doing OK.