@hasufell, it has been eight weeks since the issue was filed. As soon as we were made aware of the bug we advised users to avoid the release, noting that a follow-up release would be forthcoming.
In this case, characterisation of the issue and its cause took only a few days. We determined fairly early in the process that a revert would be the most appropriate course of action. However, we did not want to make the situation worse by blindly reverting and potentially producing out another release that was affected by similar issues. Consequently we took a more holistic view, leaving time to assess the surrounding logic for related pathologies and improving our testing infrastructure to ensure that these issues would be reliably caught.
With this work done, we turned to preparing the release. While 9.12 is minimal, even a minimal release takes time. In particular, there were other issues with 9.12.1 which we wanted to ensure did not persist in 9.12.2 (e.g. #25687, various minor submodule inconsistencies). Such issues require time to resolve and test. This is especially true for GHC’s release pipeline, which takes the better part of a day to run, severely hampering iteration cadence. In practice this means that one might get a perhaps three to five attempts per work-week at a viable release pipeline with no other major obligations.
This iteration time hits particularly hard when one encounters new or otherwise unexpected failures. One such case in this cycle was a set of unexpected failures on Darwin platforms due to Rosetta (#25793). Identifying this failure as reproducible, isolating it, identifying the cause, and proposing a fix stalled the release by several days, despite not even warranting a patch in the final release branch.
Another source of delay in this cycle has been on-going infrastructure work. As you may know, GHC is currently in the process of moving away from our primary infrastructure hosting provider, Equinix. The preparation for this migration has both taken engineering effort and has had unfortunate side-effects on our infrastructure (specifically, necessitating changing and rebuilding a number of Docker images used by the release pipeline, a process which is not always straightforward).
Finally, all of this happens concurrent to the usual GHC maintenance workload. Ticket triage, review, preparations on other release series, work on other issues, and life outside of GHC all compete for engineering time. While in principle we could drop all other work in favor of release engineering, doing so would represent an enormous cost. Release work is very much a “hurry-up-and-wait” sort of activity and consequently is best undertaken concurrently with other (often, by necessity, shallow) work.
In sum, all of this meant that six weeks passed from the opening of the ticket (and public communication warning users of the issue) to the release candidate. In my opinion it would have been better if this had been closer to four weeks. However, in light of everything currently in flight, I think this release’s time-frame is not unreasonable.
Of course, I do hope that we can further streamline the release process. In particular, recent work on 9.6.7 has made it clear that we need to further decentralize and perhaps automate some steps of the process.