Some people had asked what the users want and about typical usage, so I'll give the my perspective. I consider myself a pretty typical user of Haskell: PhD student (in theory, not languages), but still pushing the boundaries of the compiler. I've filed quite a few bugs, so I have experience with having to wait for them to get fixed. My code at various points has been littered with "see ticket #xxx for why I'm jumping through three hoops to accomplish this". As a result, I would be interested in getting builds with bugfixes. For example see the discussion on #10428: https://ghc.haskell.org/trac/ghc/ticket/10428. It's hard for a user to tell if/when a patch will be merged. I'm using 7.10.1 at the moment, but I was unsure if the patch for #10428 made it to 7.10.2.

Ben: I download the GHC bindist directly from the GHC page precisely because the one on the PPA is (inevitably) ancient.

Upgrading GHC (even minor releases; I just tried 7.10.2 to confirm this) is a pain because I have to spend an hour downloading and re-building all of the packages I need. However, I'd certainly be willing to do that for bugs that affect my code. Richard said, "Then a user's package library doesn't have to be recompiled when updating". If he means that I wouldn't have to do that, that's fantastic. However, I still wouldn't download every tiny release due to the 100mb download+install time to fix bugs that don't affect me (I'd only do that for bugs that *do* affect me).

In short: I'd really like to have builds for every bug (or maybe every day/week) that I can easily download and install.


On Mon, Sep 7, 2015 at 12:05 PM, Bardur Arantsson <spam@scientician.net> wrote:
On 09/07/2015 04:57 PM, Simon Peyton Jones wrote:
> Merging and releasing a fix to the stable branch always carries a cost:
> it might break something else.  There is a real cost to merging, which
> is why we've followed the lazy strategy that Ben describes.
>

A valid point, but the upside is that it's a very fast operation to
revert if a release is "bad"... and get that updated release into the wild.

Regards,

_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs