Speaking as a user, I think Johan's concern is well-founded. For us, ghc-7.8.3 was the first of the 7.8 line that was really usable in production, due to #8960 and other bugs. Sure, that can be worked around in user code, but it takes some time for developers to locate the issues, track down the bug, and implement the workaround. And even 7.8.3 has some bugs that cause minor annoyances (either ugly workarounds or intermittent build failures that I haven't had the time to debug); it's definitely not solid. Similarly, 7.6.3 was the first 7.6 release that we were able to use in production. I'm particularly concerned about ghc-7.10 as the AMP means there will be significant lag in identifying new bugs (since it'll take time to update codebases for that major change).
For the curious, within the past few days we've seen all the following, some multiple times, all so far intermittent:
> ghc: panic! (the 'impossible' happened)
> (GHC version 7.8.3.0 for x86_64-unknown-linux):
> kindFunResult ghc-prim:GHC.Prim.*{(w) tc 34d}
> ByteCodeLink.lookupCE
> During interactive linking, GHCi couldn't find the following symbol:
> some_mangled_name_closure
> ghc: mmap 0 bytes at (nil): Invalid Argument
> internal error: scavenge_one: strange object 2022017865
Some of these I've mapped to likely ghc issues, and some are fixed in HEAD, but so far I haven't had an opportunity to put together reproducible test cases. And that's just bugs that we haven't triaged yet, there are several more for which workarounds are in place.
John L.