GPS Haskell's death, and the birth of Stack

cover.md

This is an email I sent regarding GPS Haskell on September 7, 2014. This was a planned collaboration of Haskell Platform, Hackage, cabal, and Stackage (before Stack was released). The Hackage and Haskell Platform maintainers never responded to the email, although two days later I sent a follow up explaining all Stackage-related tasks were complete.

Had this succeeded, there likely would never have been a need for Stack, all users would have easy access to curated package sets, and Haskell Platform would have been the accepted installer.

In reality: Hackage never added support for curation, cabal-install refused to work with the stackage.org curation information, Haskell Platform made no changes for two years (ultimately releasing the HP Minimal with Stack and no global DB), and both LTS Haskell and Stack filled the void.

email.md

I'm writing this from the plane back from Germany to Israel, so apologies if the ideas are half-baked, or facts inaccurate. I think we four are the right people to be discussing this, but if you think there are others who should be included, just add them.

I'd like to break down the work to be done for making GPS Haskell a reality into concrete steps that we can work on. Here's a first pass. Note that this is optimized for getting something out into community hands to help them understand our aims, and get them on board.

1. Community infrastructure: we start a new Github repository for GPS Haskell, and with plans to utilize the Wiki extensively, and the repo itself for package configurations (described in a moment).
2. Work on getting all current Stackage patches merged into upstream and released to Hackage.
3. Some time in September, make a GPS 1 release (yes, I'm serious). This will not be a full release. Instead, this will be a preview release, consisting of only a snapshot on stackage.org which is labeled "GPS 1". This will not include any custom patches versus Hackage, and like the Stackage nightlies I'm already generating, consist of the newest possible versions of all packages.
   • In addition to the stackage.org URL, we'll create a package configuration, which is simply a list of package-version referencing Hackage packages.
   • This package configuration will be stored in the GPS Haskell repo, under e.g. gps-1.0.txt.
4. At this point, we advertise the availability of this to early adopters, and begin working with the community on the backporting process. We use the Github Wiki to make clear which packages have guaranteed backported bugfixes, and who's maintaining them. Ultimately, that list will become the definition of the Haskell Platform subset of GPS.
5. At some point, create a Haskell Platform installer based on this release. The installer should be explicitly labeled as experimental/preview. I propose the following setup:
   • cabal is tweaked so that its default remote-repo points to the appropriate stackage.org URL.
   • Unlike current Haskell Platform, do not include extra packages in the global package repo bundled in (motivation for this is simplicity in setting up the distribution, and making it easier to release a GPS 1.1 which, for example, includes a modified text package).
   • One exception: on Windows, we do need to include the network package due to the msys configuration issue. This should obviously be whatever version of network GPS 1/Stackage includes.
6. Release a GPS 1.1 point release when we get our first backported bugfix, and use this to start shaking out quirks in the system.
7. In parallel, we need to have a discussion about the long-term plans for hosting the GPS Haskell 00-index files. This functionality could be added to Hackage, we could maintain the Stackage setup, or host somewhere else entirely (these will, after all, be simple, immutable static files, so just about any file hosting will work). The top priority is high reliability, ideally without the need for mirroring.
8. Regardless of where the index files and sdist tarballs are served from, we need to provide some place on Hackage to list the available GPS releases in a machine-parsable format, and then add support to cabal to take advantage of it (I'm fuzzy on the details here).
9. At any point in this work, we may choose to do extra preview release of GPS, either full release (2, 3, 4, etc) or point releases. I think we should err on the side of releasing more often, to give the community the sense that this project is developing quickly, and is responding to their feedback.
10. Once the backporting, installer, Hackage, and cabal pieces all feel stable enough to us, we make the next major release of GPS the first official release, and promote it for general availability. Note that the following will continue unchanged until that point:
    • The recommended Haskell Platform release will be 2014.2.X (unless Mark decides to make a separate HP release in the interim).
    • Hackage will have no discernible shift in how it works for most users.
    • Furthermore, cabal-install will still default to Wild West mode.
    • Stackage nightlies will still be made available regularly, though I believe as soon as we start minting stable/GPS Stackages, I'll begin recommending Yesod users use those instead (the Yesod installation instructions have already shifted to using Stackage).

Community issues we need to be sure to address:

• Benefits to Haskell developers from using this stack:
  • Simple installation method via installers.
  • Stable APIs with bug fixes.
• Library maintainers will be reticent to accept extra burden in terms of backporting. We should spin this as a plus (which it is): we're now providing you with a well defined means of backporting bugfixes, which will let users put more faith in your code.
• Many library authors are quite intimidated by the Haskell Platform submission process. By contrast, the Stackage process does not seem to scare people at all (since it's basically placing no burden on them). I think we need to explicitly set some new policy, either to be the new HP policy, or the middle ground between HP and Stackage (perhaps GPS-maintained), which would be something like:
  • A basic manual review process to weed out completely unstable/untested code. This is guaranteed not to become a bikeshedding discussion around APIs, but rather a simple "your package says it does X, does it do X in a non-braindead way?".
  • You agree to provide bugfixes for the duration of whichever GPS release your package is included in. We'll obviously need to give authors a support window, so this requirement will only be properly enforced once we hit point (10) above- the first stable GPS release.