So, as it stands, GHCup distributes 9.8.2 without a warning? This means the users are still at a high risk of encountering the security issue. I don’t see how withholding 9.8.3 changes that, except as an attempt to incentivise GHC HQ to release 9.8.4
My reasoning is this: 9.8.3 is an incremental improvement over 9.8.2, so either both should be available or neither. It makes no sense to keep users at 9.8.2 that has the exact same file path issue and other issues.
As I described earlier (repeating myself again). Moving a release to GHCup also requires me to do other work (fixing non-backported bindist bugs, building some unofficial bindists for certain platforms that users already assume and don’t know aren’t actually official).
Assuming there will be a 9.8.4 release shortly would allow me to skip 9.8.3 entirely. In light of 9.8.4, there’s no reason a user would ever want to install 9.8.3.
Now the situation is that @AndreasPK is telling me there might not be such a 9.8.4 release. If I ship 9.8.3 as-is, I lose the opportunity to ship the fix! That means I’d have to ship a new GHC version (much much worse) to fix it… so basically create 9.8.4 downstream.
That’s why the two options are:
Now I understand @hasufell’s view of the seriousness of the bug in (deprecated) filepath-1.4.200.1 that was fixed in filepath-1.4.300.1, I am going to reverse the relaxation of stack-3.1.1's dependency on filepath versions on Hackage.
To be clear, we are not necessarily opposed to doing such a release but we do need to balance this need against other priorities. At the moment, our funding for GHC work is rather limited and, as such, doing work on another release necessarily comes at the expense of other work, some of which takes precedence. If we are going to do another release, we should be certain that we have identified all of the factors driving the need, have backported all of the relevant work addressing those factors, and have updated our processes to avoid this happening again in the future.
Personally, I would much rather see 9.8.3 be ignored and have to eventually prepare a 9.8.4 than see the precedent of a fragmented release process with a downstream release.
@bgamari would it help if I volunteer to work on releasing GHC 9.8.4?
I appreciate the offer, @bodigrim. However, sadly this particular release is not one where a volunteer will significantly help. In particular, the work of backporting, which is typically the bulk of the parallelizable work, is likely to be extremely light in this case. This leaves the procedural work of binary distribution preparation, verification, signing, uploading, and announcing. This work requires a fair amount of experience with the release pipeline, infrastructure, and credentials which would be rather difficult to convey in a timely manner.
@bgamari if you have means to release GHC 9.8.4 “in a timely manner”, that’s great news! It’s just that so far your hints sounded more like “never”, which, if I may be so bold, is asymptotically longer than any time a volunteer might spend. But fair enough, I will not insist on offering free labor twice.
I have done the backporting already and triggered a pipeline on my fork. To my surprise, a darwin runner consistently failed (I am pretty sure that it’s not related to the filepath bump): release-x86_64-darwin-release (#2031982) · Jobs · Julian Ospald / GHC · GitLab
Is the release process documented in a step-by-step manner with all those small little things about credentials etc? Something similar to https://www.haskell.org/ghcup/dev/#releasing.
@hasufell, the tracking ticket template serves as the primary overview documentation for the release process; it refers to further documentation elsewhere, although I cannot claim that the end-result is comprehensive and in practice some points are executed with discretion of the release manager. As you might imagine, the necessary credentials are not something that we place in public documentation.
The CI issue that you note is one of many reasons why, sadly, releases require real effort. I do not know what is going on in this particular case but I, too, have noticed that the Darwin runners having been experiencing more test timeouts in the past few weeks. This is not something that I have had the time to investigate.
However, I would reiterate: please let’s not confuse the 9.8.3 release by introducing a second set of a substantively different binaries. If there needs to be a 9.8.4 then we can discuss and provide one.
Strongly recommend letting @Bodigrim take a swing at this. I did it once myself and it was underdocumented, underspecified, but doable. Exactly the kind of thing that needs newcomers to come in and make small improvements, as I did.
Here’s the epic I created that Bodigrim could contribute to were he to work on a release:
GHCHQ may feel that it will require even more work to support a newcomer than it would be to do a release themselves. Turning away newcomers based on that belief simply makes the problem worse.
Some may turn their nose at the term “fully automatic”: something something private keys or whatever. I believe moving towards a fully automatic release, regardless of how far we get, is always useful. Time spent making life easier for a newcomer pays dividends for every future release.
Agreed:
Nobody is talking about (or practicing) continuous deployment. AT ALL. It’s like we have all forgotten it exists. It’s time to change that.
[…] their best people left in frustration. Before the year was over their ship had sunk.
And what is the primary source of those leaks and holes […]? It is everything that happens between the moment you write the code and the moment that code is live: your too-long, leaky, distended, bloated, lumped-up, misfiring software digestive system.
If any engineer on your team can merge a set of changes to main, secure in the knowledge that 15 minutes later their changes will have been tested and deployed to production, with no human gates or manual intervention required, then congratulations! You’re doing CI/CD.
I see 9.8.4 was uploaded and is available now via ghcup - I suppose the official announcement will be forthcoming in due course
Upstream provided a PR to add the new bindists to the ghcup vanilla channel: vanilla: Add GHC 9.8.4 by bgamari · Pull Request #265 · haskell/ghcup-metadata · GitHub
I consider this a “release announcement” for my purposes, so I went ahead: Add 9.8.4 proper by hasufell · Pull Request #267 · haskell/ghcup-metadata · GitHub
9.8.3 will not be added to the default channel.