[GHC DevOps Group] GHC 8.4.3 release, and release policies?

[Simon Marlow]

Will Stack also be broken for other GHC versions on Ubuntu 18.04, or does
it only enable -g for 8.4+? i.e. even if we roll a new 8.4.3, will people
still using 8.2.x have problems?

The "purist" side of me agrees with you that this is a downstream issue.
However, Stack doesn't have its own builds of GHC unlike Ubuntu, so it
can't easily fix this by patching GHC. They could fix Stack to not use -g
on affected distros / GHC versions though.

Cheers
Simon


On 12 May 2018 at 18:23, Gershom B <gershomb at gmail.com> wrote:

> I believe this list/group is intended to help set GHC release policies
> and plan when releases occur.
>
> I'd like to draw people's attention to
> https://ghc.haskell.org/trac/ghc/ticket/15068
>
> I think that the "nay" side has the right of it.
>
> 1) To summarize my understanding: there is an issue with upstream gnu
> binutils that are included in Ubuntu 18.04 and is triggered by GHC
> _only_ when the -g flag for debug symbol output is passed. This bug is
> triggered by GHCs going back through the 8.2 series. Note that 18.04
> was released _after_ ghc 8.4.2.
>
> There is a patch to GHC to work around this issue, that also
> incidentally improves another possible issue with debug symbol
> emitting.
>
> Normally the -g flag is relatively rarely used, and by those who would
> be able to work around such things. However, stack runs with -g by
> default, unless users explicitly compile with symbol stripping turned
> on.
>
> The proposed solution is an 8.4.3 release of GHC with _just_ this patch.
>
> 2) To summarize my objection to the plan -- I do not think that
> spinning up a full new release to just patch one thing to work around
> an upstream bug is a good precedent for GHC release management. I can
> imagine exceptional circumstances, but in general the right answer
> should happen downstream of a full GHC release. We already want a more
> timely cadence. That cadence should suffice for these sorts of things.
>
> In the meantime, the binary provided by hvr's ubuntu ppa already
> incorporates this patch.
>
> One might say -- what about stack and platform users? My suggestion
> would be that since stack provides its own binaries, patched binaries
> can be provided by stack in this circumstance, just as the ubuntu ppa
> includes the patch. Similarly we could respin a platform release with
> the patch, just for linux, rather than across all three major
> platforms. (Or not -- I don't think that users that know about -g
> would mind too much using the ppa for the patched release, and I
> suspect those users are more likely ppa users already anyway, or wise
> enough not to immediately upgrade to a new ubuntu system for devwork
> without time for bugs to shake out).
>
> Anyway, I can't recall a precedent for a point-release over an issue
> like this in the past, and I think if we start to do so too much it
> will overstrain resources away from the important goals of regularity
> and stability we do want in releases.
>
> I would like to know what others think.
>
> Cheers,
> Gershom
> _______________________________________________
> Ghc-devops-group mailing list
> Ghc-devops-group at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devops-group
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devops-group/attachments/20180513/af9d4809/attachment.html>