Growing Haskell Platform

[Michael Snoyman]

On Fri, Dec 7, 2012 at 10:50 AM, Edward Z. Yang <ezyang at mit.edu> wrote:

> Excerpts from Michael Snoyman's message of Fri Dec 07 00:29:14 -0800 2012:
> > Let me give a more extreme example: suppose that the bug in text hadn't
> > simply been slower compile times, but instead it segfaulted every time
> you
> > appended two empty strings. What would be our response to users? Should
> we
> > tell them to stick with the current HP until the next one is released,
> and
> > hope they don't trigger the bug? Should they try and convince their whole
> > system to get rebuilt?
>
> I think the pragmatic solution here is to roll a platform point-release,
> just fixing the particular major bug.
>
> Edward
>

That seems suboptimal from a few different standpoints:

* HP maintainers will have to do a lot of work every time a bug is detected.
 * Users will need to redownload and reinstall the HP every time a bug is
detected. In this process, they will almost certainly need to recompile
*all* of their packages, instead of just the packages depending on the
broken package.
* Package maintainers cannot always get version bumps they need. The text
example I gave is a perfect case: I would not expect the HP team to turn
around and release a brand new HP to improve compile times of my users. But
persistent users would have liked to be able to opt-in to getting that
update, even if it meant recompiling everything.

Perhaps we need to think about this as OSes do. Ubuntu will release version
12.04 (LTS), and then provide security patches as necessary. When enough
security patches come in, they'll ultimately create a point release and
then go through the effort of spinning a new CD. We're in a trickier
situation due to the ABI issues, but I don't think we can solve this by
simply forgoing interim updates and requiring a new point release for every
fix we need.

Michael
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20121207/d4f8f51c/attachment-0001.htm>