<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Oct 6, 2014 at 11:28 AM, Herbert Valerio Riedel <span dir="ltr"><<a href="mailto:hvriedel@gmail.com" target="_blank">hvriedel@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 2014-10-06 at 11:03:19 +0200, <a href="mailto:p.k.f.holzenspies@utwente.nl">p.k.f.holzenspies@utwente.nl</a> wrote:<br><span class="">> The danger, of course, is that people aren't very enthusiastic about<br>
> bug-fixing older versions of a compiler, but for<br>
> language/compiler-uptake, this might actually be a Better Way.<br>
<br>
</span>Maybe some of the commercial GHC users might be interested in donating<br>
the manpower to maintain older GHC versions. It's mostly a<br>
time-consuming QA & auditing process to maintain old GHCs.<br>
</blockquote></div><br></div><div class="gmail_extra">What can we do to make that process cheaper? In particular, which are the manual steps in making a new GHC release today?</div><div class="gmail_extra"><br></div><div class="gmail_extra">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.)</div><div class="gmail_extra"><br></div></div>