I’m happy to announce the completion of the handover of Stackage.org to the Haskell Foundation.
Thanks to FP Complete’s effort and dedication, Stack and Stackage have been part of the Haskell community for ten years. These tools opened up wider adoption of Haskell and introduced new ways of working on Haskell projects of all sizes. The Stack approach to dependency management—using fixed package sets—offered an alternative to the solver-based approach used by cabal-install. While useful in its own right, simply having more than one approach to dependency management spurred development across the ecosystem. Today we see friendly collaboration and cross-pollination between the Stack and Cabal communities. I believe we have already entered a period of renewed evolution of the Haskell tooling world.
The Haskell Foundation’s mission is to broaden Haskell adoption by supporting its ecosystem of tools, libraries, education, and research. Administering Stackage is a direct embodiment of that mission! As administrators, we look forward to supporting the developers and curators of Stack and Stackage. These tools have always been open to community contribution, and that is only more true now. The Foundation facilitates the community, but it’s the community that drives innovation. I’m looking forward to what comes next.
Once again, thank you to FP Complete for providing these tools, and thank you to the Haskell Foundation’s sponsors for enabling this kind of work.
Is the HF board going to make Stackage related decisions, or will the HF limit itself to paying hosting fees and server admin costs (i.e. your paycheck)?
For example, one could imagine the interval between LTS releases to be determined through HF tech proposals. I imagine that repo currently doesn’t cover Stackage, but its README doesn’t make that clear.
I am asking because I remember a discussion on when LTS-22 would be released. It’s a fairly foundational question and the comments by @andreasabel seem to suggest that there was a change in policy. Is the documentation of this something the HF has any plans to contribute to in any way, or would that somehow be considered too intrusive?
There are stable releases in the world of GHC release management, and then there is stability according to Stackage. If HF’s goal is to increase professional use of Haskell, one could argue that systematizing the stability label would be desirable. But I also imagine that it might be politically fraught somehow. In that case, would it make sense to have a tech-proposal that states what the HF doesn’t have opinions on?
I suppose HF doesn’t have the budget to sponsor curators. Is there an official HF policy on which parts of Stackage are paid for, and which parts the community is required to contribute?
Traditionally the HF tries to avoid dictating how things should be run, and so our default is to ensure community control. The tech proposal process is definitely one way we could get feedback, but it’s not really a mechanism for community control as much as it’s a formal mechanism for community input.
Nothing about how Stackage curation is managed has been changed by this handover. Bryan is willing and able to take on any possible changes, but that would need to go through our standard community processes.
Further on what jmct said, my understanding is that HF is taking over just the technical administration of the servers and such. The curators remain an independent group with their own mechanisms for managing themselves and their policies. That said, they are among the many different independent groups who have enacted a formal affiliation with the Haskell Foundation: Affiliates
Not sure where to mention this, but I saw https://haskell.love on the Affiliates list… and the SSL certificate is borked. I don’t know what that site is supposed to be, or which project it is for, so I don’t know where to mention this. Does anyone know?
@chreekat@jmct the footer at stackage.org still says " A service provided by FP Complete". If the handover is complete, I’d expect it to give credit to HF.
@hasufell, another of my followup tasks is to actually document the architecture of Stackage. Figuring out how to run a mirror would be an interesting exercise. Offhand I can’t even remember if it’s Stackage that would need to be mirrored. I know Stack hits casa.stackage.org and the Haddocks bucket, at least. (The Haddocks bucket holds https://stackage-haddock.haskell.org/snapshots.json. Refactoring the system to put that file somewhere else — maybe Casa?! — might make mirroring easier.)
Your observation has flagged that Stack’s online documentation was out of date - which is now fixed. In short, pantry-0.9.2 changed the default Casa repository prefix to casa.stackage.org. When Stack 2.13.1 adopted that version of pantry, the consequences for Stack’s documentation of the default were missed.
@chreekat I don’t see why HF should be so shy of its current and ongoing efforts, mentioned only as a passive acceptor of a donation. “A service provided by HF, originally created by FP Complete” seems a fair summary to me.
Thanks @tomsmeding , I noticed that too last night. I was in the midst of updating the text for exactly the reasons @bodigrim highlights. I’ll bang it into shape now.
I have merged some updates to the footers of 
