Re: Windows release quality

Just to make this clear it's not my intention to blame anyone or point fingers. Given the resources at hand I think Phyx and you have done an amazing job so far to keep things working! The core of the issue is that if someone sits down and installs a "stable" GHC today he will either get a version that hangs on any dependency using TH (8.6.3) or run into weird errors if he tries to profile an executable. Both of which I would call rather mundane development activities. But what I take issue with is not that there is some brokenness. It's how we deal with that fact from a user perspective. Pretty much all distribution channels currently provide 8.6.3 or 8.6.4 as stable. Haskell Platform: "The latest version of the Haskell Platform for Windows is 8.6.3." Stackage: * LTS 13.13 for GHC 8.6.4 https://stackage.org/lts-13.13, published 3 days ago * LTS 13.11 for GHC 8.6.3 https://stackage.org/lts-13.11, published a week ago haskell.org: Current Stable Release: 8.6.4 And none of the download pages give any indication of issues. Neither does the user guide. How much effort can we really expect from a user to find out something basic like profiling or TH is simply broken in a release marked as stable? I've actually got hit by both issues despite at least following ghc development somewhat. We don't have to be debian. But as a windows user a release being stable has lost all meaning to me. And I imagine it's worse for people not looking behind the curtain. Ben Gamari schrieb:

Phyx writes:

...

Hi Andreas,

GHC 8.6.4 not supporting profiling libs was the first thing mentioned in the release email

- A regression resulting in segmentation faults on Windows introduced by the fix for #16071 backported in 8.6.3. This fix has been reverted, meaning that 8.6.4 is once again susceptible to #16071. #16071 will be fixed in GHC 8.8.1.

It was also stated that it would be back in 8.8.1. At this point there was no way to get profiling libs on 8.6.x without a major backport of linker changes from master. The choice was made to revert the change and release 8.6.4 without profiling libraries because of a stack allocation bug that was dormant for years but completely killed the 32 bit distribution. That said the changelog linked to the wrong issue, the second two should have been #15934 but that's not hard to figure out by looking at the ticket.

I will reiterate that having functional profiling in 8.6.4 was never in the cards (unless a contributor was willing to step up to backport Phyx's linker patch).

However, I will also say that the fact that the omission of the profiling libraries and haddock from the release tarball (#16408) was not my intention. Rather this was an accidental side-effect of an oversight in the release CI job. This is something I only realized rather recently (leading to !516) and thought I would fix after when I re-spun the Windows tarballs to include an i386 build.

In hindsight I should have advertised this more widely and perhaps even pulled the bindist. However, in my defense I did not expect it to more than a few days to get the fixes through CI and have a new set of bindists ready for release. On the whole I agree that it is not fair to users to expect them to discover this sort of thing by browsing the issue tracker. This is something that I will improve on in the future.

In general I'm not sure how to handle signalling of release stability. Tamar has done an absolutely amazing job keeping the Windows boat afloat (and even improving it, c.f. his new IO manager), However, I cannot deny that there are indeed issues, as evidenced by the fact that my patch making Windows a mandatory-green CI platforms needs to disable quite a number of flaky or failing tests. Should we be signalling that this is stable? It's hard to say; many of these cases are rather niche. Needless to say if there's consensus that this doesn't constitute a production ready compiler then I will advocate adjusting the priorities of our efforts at Well-Typed to put more weight on fixing the Windows issues.

Cheers,

- Ben