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 <jwl...@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.tib...@gmail.com<mailto:johan.tib...@gmail.com>> wrote:
On Fri, Oct 3, 2014 at 11:35 PM, Austin Seipp
<aus...@well-typed.com<mailto:aus...@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<mailto:ghc-devs@haskell.org>
http://www.haskell.org/mailman/listinfo/ghc-devs
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
