ecrockett0 at gmail.com
Thu Sep 10 15:07:59 UTC 2015
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 at scientician.net>
> 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.
> ghc-devs mailing list
> ghc-devs at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-devs