I don't know whether this has ever been considered as an idea, but what about having a notion of Long Term Support version (similar to how a lot of processor and operating systems vendors go about this).


The idea behind an LTS-GHC would be to continue bug-fixing on the LTS-version, even if newer major versions no longer get bug-fixing support. To some extent, there will be redundancies (bugs that have disappeared in newer versions because newer code does the same and more, still needing to be fixed on the LTS code base), but the upside would be a clear prioritisation between stability (LTS) and innovation (latest major release).


The current policy for feature *use* in the GHC code-base is that they're supported in (at least) three earlier major release versions. Should we go the LTS-route, the logical choice would be to demand the latest LTS-version. The danger, of course, is that people aren't very enthusiastic about bug-fixing older versions of a compiler, but for language/compiler-uptake, this might actually be a Better Way.


Thoughts?


Ph.





From: John Lato <jwlato@gmail.com>
Sent: 06 October 2014 01:10
To: Johan Tibell
Cc: Simon Marlow; ghc-devs@haskell.org
Subject: Re: Tentative high-level plans for 7.10.1
 
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.

On Sat, Oct 4, 2014 at 2:54 PM, Johan Tibell <johan.tibell@gmail.com> wrote:
On Fri, Oct 3, 2014 at 11:35 PM, Austin Seipp <austin@well-typed.com> wrote:
 - Cull and probably remove the 7.8.4 milestone.
   - Simply not enough time to address almost any of the tickets
     in any reasonable timeframe before 7.10.1, while also shipping them.
   - Only one, probably workarouadble, not game-changing
     bug (#9303) marked for 7.8.4.
   - No particular pressure on any outstanding bugs to release immediately.
   - ANY release would be extremely unlikely, but if so, only
     backed by the most critical of bugs.
   - We will move everything in 7.8.4 milestone to 7.10.1 milestone.
     - To accurately catalogue what was fixed.
     - To eliminate confusion.
#8960 looks rather serious and potentially makes all of 7.8 a no-go for some users. I'm worried that we're (in general) pushing too many bug fixes towards future major versions. Since major versions tend to add new bugs, we risk getting into a situation where no major release is really solid.


_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs