[Nix-dev] Stackage Support Will Be Discontinued

[Anthony Cowley]

Peter Simons writes:

> Hi Anthony,
>
>  > I know you didn't ask for feedback [...].
>
> I'm always happy to get feedback!
>
>  > If the top priority is receiving bug fixes, then keeping an LTS-4,
>  > LTS-5, LTS-6, etc. that tracks the most recent minor version makes
>  > sense.
>
> You seem to be saying that keeping an old major release like LTS-4
> around would somehow help us receive more bug fixes, but I can't see how
> that would be true. According to git://github.com/fpco/lts-haskell.git,
> the last time any LTS-4 update occurred was on 2016-01-18 -- almost half
> a year ago. Surely, there have been point updates that fix bugs between
> then and now, but LTS-4 does not seem to receive them, no? That is
> because no-one maintains LTS-4. Stackage has moved on to LTS-5, or
> rather: LTS-6 by now.
>
> So how exactly do we receive more bug fixes by distributing LTS-4?

I meant that just tracking the latest minor version gets you everything possible regarding bug fixes. This was by way of agreement with your point that newer minor releases obsolete older ones. I go on to draw a distinction between newer minor versions obsoleting old ones for purposes of bug fixes vs. for purposes of freezing packages.

>
>  > You say, "Stackage does not "maintain" any of its LTS releases," but
>  > the minor releases are precisely the offered maintenance.
>
> The thing is just that minor releases occur only for the latest major
> release. LTS-6 has minor release at the moment, but LTS-5, LTS-4, etc.
> do not! I agree that it would make sense to continue to distribute LTS-4
> if there were further minor releases to come out for that package set.
> But there won't be any. As far as Stackage is concerned, LTS-4 is dead.

The Stackage design is such that they *can* release bug fixes for older versions to help their users. You are removing that opportunity because it hasn't been used yet. Stackage is, relative to Haskell, very new. I think LTS-5 is far more widely used than previous major releases, and therefore stands a much greater chance of seeing a bugfix release even now, after the advent of LTS-6.

The use of this safety feature is correlated to adoption: as companies adopt Stackage package sets, they will have applications in production that they, A) really want bug fixes for; and B) do not want to keep on the hackage treadmill by following new releases. If a bug is found in an LTS-5 package within the next few months, a stink will be raised.

>  > Furthermore, there is no reason a new LTS-5 release can not be issued
>  > after the first release of LTS-6.
>
> Sure, this *could* happen and it would be great! Then we'd have a real
> long-term supported package set that would be worth-while to distribute.
>
>
>  > The cultural prominence of Stackage means that the need for security
>  > fixes to older versions can actually be promulgated because Stackage
>  > has users.
>
> I am sorry, but I have no idea what that sentence means.

It means that problems get publicity. When there are notable changes to package versions in Stackage (e.g. with aeson), there is a reddit discussion, posts on twitter, and chatter on IRC. This is the kind of herd immunity that Stackage provides: if one person finds a problem with a version of a library included in a Stackage package set, they can raise an alarm that is easy for everyone to interpret and address. Pre-Stackage, this rarely if ever happened because every application in production was running against a unique collection of versions that the cabal solver picked on an arbitrary day.

>
>  > For a modest application, specifying a particular Stackage release is
>  > a concise way of freezing Haskell dependencies.
>
> In Nix, we can solve these things by tagging a specific version of
> Nixpkgs and sticking to that. Not only will that freeze the Haskell
> dependencies, but it will also freeze all other dependencies, too.

This is a big step backwards. You object that Stackage has not yet used their existing mechanism for releasing bug fixes for older Haskell libraries, and respond by promoting a mechanism that admits no bug fixes for any software at all.

>
>  > A typical Stackage definition is about 70KB.
>
> Huh? That's not what I am seeing in git://github.com/fpco/lts-haskell.git:
>
>    $ ls -lh lts-6.2.yaml
>    -rw-r--r-- 1 simons users 4.7M Jun  6 11:58 lts-6.2.yaml

Your data here is quite disingenuous: that file contains lists of github users, six hashes per package, a kind of reverse dependency information (users), and I do not know what else to aid with Stackage maintenance. If you are a Haskell programmer and wish to use Stackage versions, you do this,

$ curl https://www.stackage.org/lts-6.2/cabal.config > cabal.config
$ ls -lh cabal.config 
-rw-r--r--  1 acowley  staff    69K Jun  8 20:22 cabal.config

Those are the versions of packages on hackage that constitute a Stackage release. nixpkgs will need additional data to address your point about official Stackage only being tested on one platform, hence me calling the space blow-up "unfortunate," rather than a bug.

>
>  > Nix definitions require nearly 10x that space is unfortunate, but I
>  > had expected a Nix solution to this issue rather than giving up on
>  > versions altogether.
>
> Oh, come on. I wrote a very long and detailed explanation of *why* we
> give up on tracking Hackage, and to boil that whole article down to "it
> was using too much disk space" is just silly.

I didn't mean that remark as a response to your entire message, which is why I wrote so much else, but to the link you offered as evidence that there is a problem. I apologize that it came across as dismissive.

Anthony