[Haskell] SLURP: a single unified registry for Haskell packages

[Simon Peyton Jones via Haskell]

Friends

Hackage has been extraordinarily successful as a single repository through 
which to share Haskell packages. It has supported the emergence of variety of 
tools to locate Haskell packages, build them and install them (cabal-install, 
Stack, Nix, ...). But in recent years there has been increasing friction over,

  *   Hackage's policies, especially concerning version bounds;
  *   Hackage's guarantees, especially around durability of package content and 
metadata;
  *   Hackage's features, especially the visual presentation and package 
documentation.

If we do not resolve this friction, it seems likely that the Haskell library 
ecosystem will soon "fork", with two separate repositories, one optimised for 
Cabal and one for Stack. This would be extremely counter-productive for Haskell 
users.

Thus motivated, over the last few months we have talked a lot to colleagues, 
including ones in the Hackage and Stack communities. We have emerged with 
SLURP, a proposal that could go a long way towards supporting the upsides of a 
diverse ecosystem, without the sad downsides of forking into mutually-exclusive 
sub-communities.

Here is the SLURP 
proposal.
 We invite the Haskell community to debate it.

SLURP is meant to enable both Hackage and Stackage (and perhaps more services 
in the future) to in the future make choices autonomously without hurting other 
package services. But it will only work if the implementors of both Hackage and 
Stackage are willing to participate. We respect their autonomy in this matter, 
but we urge them to give this proposal serious consideration in the best 
interests of the community and Haskell's success. We have carefully designed 
SLURP to be as minimal and non-invasive as possible, so that it can be adopted 
without much trouble. Of course, we are open to debate about the specific 
details.

We do have an offer from someone willing to implement SLURP.

We also strongly urge members of the community to express clear views about the 
importance --- or otherwise --- of adopting something like SLURP. You are, 
after all, the community that GHC, Hackage, Stackage, Cabal, etc are designed 
to serve, so your views about what best meets your needs are critically 
important.

Mathieu Boespflug (@mboes)
Manuel Chakravarty (@mchakravarty)
Simon Marlow (@simonmar)
Simon Peyton Jones (@simonpj)
Alan Zimmerman (@alanz)

___
Haskell mailing list
Haskell@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell

Re: [ANNOUNCE] GHC 8.4.1-alpha2 available

[George Colpitts]

installed fine on my mac
primitive can now be compiled
unordered-containers does not compile, even with allow-new. This has been
reported by Neil Mitchell
haskell-src-exts does not compile, not clear where to report this

On Sun, Jan 21, 2018 at 4:15 PM Ben Gamari  wrote:

>
> The GHC development team is pleased to announce the second alpha release
> of the 8.4.1 release. The usual release artifacts are available from
>
> https://downloads.haskell.org/~ghc/8.4.1-alpha2
>
> Note that this alpha, like alpha1, is unfortunately afflicted by #14678.
> We will try to get an alpha3 out as soon as this issue has been resolved.
> However, as this alpha has a number of fixes since alpha1, we have
> decided it would be best not to delay it any further.
>
> Also, due to user demand we now offer a binary distribution for 64-bit
> Fedora 27; this distribution links against ncurses6. This is in contrast
> to the Debian 8 distribution, which links against ncurses5. Users of
> newer distributions (Fedora 27, Debian sid) should use this distribution.
>
> Note that this release drops compatibility with GCC 4.6 and earlier.
> While we generally try to place as few constraints on system toolchain
> as possible, this release depends upon the __atomic__ builtins provided
> by GCC 4.7 and later (see #14244).
>
>
> === Notes on release scheduling ===
>
> The 8.4.1 release marks the first release where GHC will be adhering to
> its new, higher-cadence release schedule [1]. Under this new scheme,
> major releases will be made in 6-month intervals with interstitial minor
> releases as necessary.
>
> In order to minimize the likelihood of schedule slippage and to ensure
> adequate testing, each major release will be preceeded by a number of
> regular alpha releases. We will begin issuing these releases roughly
> three months before the final date of the major release and will issue
> roughly one every two weeks during this period. This high release
> cadence will allow us to quickly get fixes in to users hands and allow
> better feedback on the status of the release.
>
> GHC 8.4 is slated to be released in mid-February but, due to technical
> constraints, we are starting the alpha-release cycle a bit later than
> planned under the above schedule. For this reason, it would be greatly
> appreciated if users could put this alpha through its paces to make up
> for lost time.
>
> As always, do let us know if you encounter any trouble in the course of
> testing. Thanks for your help!
>
> Cheers,
>
> - Ben
>
>
> [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule
> ___
> ghc-devs mailing list
> ghc-d...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users