On Mon, Oct 6, 2014 at 11:28 AM, Herbert Valerio Riedel <hvriedel@gmail.com> wrote:

On 2014-10-06 at 11:03:19 +0200, p.k.f.holzenspies@utwente.nl wrote:
> 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.

Maybe some of the commercial GHC users might be interested in donating
the manpower to maintain older GHC versions. It's mostly a
time-consuming QA & auditing process to maintain old GHCs.

What can we do to make that process cheaper? In particular, which are the manual steps in making a new GHC release today?

In the long run back porting bugfixes is the route successful OSS projects take. Once people have written large enough Haskell programs they will stop jumping onto the newer version all the time and will demand backports of bug fixes. This is already happening to some extent in cabal (as cabal is tied to a ghc release which means we need to backport changes sometimes.)