Re: 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 ,
published 3 days ago
* LTS 13.11 for GHC 8.6.3 ,
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



___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Windows release quality

[Ben Gamari]

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



signature.asc
Description: PGP signature
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Windows release quality

[Phyx]

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.

This was not an oversight, both the choice to release GHC 8.6.4 without
profiling libs (which really to the average user is not mission critical)
and the fact to release 8.6.4 at all were thought out decisions. It could
have been communicated better yes.

That 8.6.3 wasn't removed I don't know. I pulled it from chocolatey at
least.

8.6 is more production ready than 8.4 was, it just doesn't support
profiling libs for a while till 8.8 yes.

Tamar.

On Tue, Mar 19, 2019 at 5:57 PM Andreas Klebinger 
wrote:

> Hello Devs,
>
> After running into #16408 today I realized there is as of yet no released
> bindist
> of the 8.6 series which I would consider stable for windows.
>
> GHC 8.6.1 and 8.6.2 had a series of critical bugs which applied to
> multiple platforms: https://gitlab.haskell.org/ghc/ghc/issues/16408
> GHC 8.6.3 loops forever if compiling certain code using TH on windows.
> This affects some very popular hackage packages: (#16057)
> 
> GHC 8.6.4 (marked stable) currently ships without profiling libraries,
> making profiling impossible.
>
> Being stuck with 8.4 is one thing, and if properly communicated not too
> bad.
> But it requires work to even find out about these (major) issues and to
> discover that 8.6 is NOT production ready for windows.
>
> We offered the broken 8.6.3 as stable for weeks without any indication
> that it was broken.
> We still serve GHC 8.6.4 as stable without any hint about the missing
> profiling libraries.
>
> I can't offer solutions in this case but I feel like something about the
> release management has to change if .
> Having to check the GHC bugtracker to find out if the current stable
> release is actually stable is just not sustainable.
>
>
>
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Windows release quality

[Andreas Klebinger]

Hello Devs,

After running into #16408 today I realized there is as of yet no
released bindist
of the 8.6 series which I would consider stable for windows.

GHC 8.6.1 and 8.6.2 had a series of critical bugs which applied to
multiple platforms: https://gitlab.haskell.org/ghc/ghc/issues/16408
GHC 8.6.3 loops forever if compiling certain code using TH on windows.
This affects some very popular hackage packages: (#16057)

GHC 8.6.4 (marked stable) currently ships without profiling libraries,
making profiling impossible.

Being stuck with 8.4 is one thing, and if properly communicated not too bad.
But it requires work to even find out about these (major) issues and to
discover that 8.6 is NOT production ready for windows.

We offered the broken 8.6.3 as stable for weeks without any indication
that it was broken.
We still serve GHC 8.6.4 as stable without any hint about the missing
profiling libraries.

I can't offer solutions in this case but I feel like something about the
release management has to change if .
Having to check the GHC bugtracker to find out if the current stable
release is actually stable is just not sustainable.




___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs