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

[Simon Marlow]

In that case I agree there's no urgent need for us to put out an 8.4.3. But
we should explain the rationale carefully, it looks like this is a
sensitive topic.

Cheers
Simon

On 13 May 2018 at 17:00, Gershom B <gershomb at gmail.com> wrote:

> Update: as per https://github.com/commercialhaskell/stack/issues/4019 it
> turns out that stripping is in fact enabled by default in stack, so this
> bug only hits when people _turn off_ stripping in their config files (which
> in stack just happens to also be coupled with turning on -g).
>
> So a fresh installed stack works on ubuntu, and only breaks when people
> change stripping settings. Anyway, this seems to lend more weight to the
> “no release necessary” side of things.
>
> —Gershom
>
>
> On May 13, 2018 at 4:11:06 AM, Gershom B (gershomb at gmail.com) wrote:
>
> On May 13, 2018 at 3:59:04 AM, Simon Marlow (marlowsd at gmail.com) wrote:
>
> 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?
>
> Indeed, as best I undesrtand it, it will be broken on the 8.2 series as
> well. So anyone pinned to any older ghc (via a particular lts or daily)
> will continue to have this problem. From what I can tell, the -g flag is
> added basically universally. C.f. https://github.com/
> commercialhaskell/stack/blob/master/src/Stack/Build/Source.hs#L147
>
>
> 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.
>
> As far as I know, stack does produce its own builds these days, although
> they should be conferred with, to confirm. In particular, see https://raw.
> githubusercontent.com/fpco/stackage-content/master/stack/
> stack-setup-2.yaml which is where it draws the compilers it installs
> from. Currently all the urls seem to point to files hosted on *https://github.com/commercialhaskell/ghc/releases/
> <https://github.com/commercialhaskell/ghc/releases/>* and from what I can
> tell there are far more ghc builds provided there than directly produced by
> ghchq.
>
> —gershom
>
>
>
> 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/20180514/961eef6c/attachment-0001.html>