Windows release quality

[Andreas Klebinger]

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<lonetiger at gmail.com>  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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20190319/42e08bde/attachment.html>