# DevOps Weekly Log, 2024-03-27

**URL:** <https://discourse.haskell.org/t/devops-weekly-log-2024-03-27/9165>\
**Category:** Haskell Foundation\
**Created:** [March 27, 2024, 10:31am UTC](https://discourse.haskell.org/t/devops-weekly-log-2024-03-27/9165 "2024-03-27T10:31:04Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![chreekat](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/chreekat/32/2669_2.png) [@chreekat](https://discourse.haskell.org/u/chreekat)\
**Post date:** [March 27, 2024, 10:31am UTC](https://discourse.haskell.org/t/devops-weekly-log-2024-03-27/9165/1 "2024-03-27T10:31:04Z")

</div>

Welcome to the next weekly log.

The main theme of this last week has been finalizing the Stackage handover. At this point I thnk I’m actually done with the technical work. All that remains is to double check everything and write the official announcement.

- I cleaned up the Stackage data migration — it’s done now!
- I set up a new Hackage mirror so FP Complete can retire theirs eventually. I think it’s ready for final testing.
- I am investigating a performance issue with the new Stackage data bucket. It only affects curators, not regular Stackage users. I’ve been in touch with the service provider and I trust they’ll be able to fix it pretty quickly.

In the next week, I want to officially wrap up the handover 🎉 and start on some important followup work. Among the followup tasks, I want to highlight two documentation projects: I want to document the history of my handover effort and the Stackage architecture itself. I am now intimately familiar with Stackage, and I want to share how it works, where it could be improved, and how it affects the stability and reliability of the Haskell ecosystem. For instance, did you know it’s valuable to get your package included in Stackage, even if you prefer to use cabal-install and believe—as I do—that conservative upper bounds on your package dependencies are a good thing™?

That’s all for the log, see you next time.

> **This week's GHC issue triage notes**
>
> _(I had another obligation and only stayed for fifteen minutes of the triage session. The GHC team actually triaged a much larger number of tickets than what I’ve listed here.)_
> 
> - [#24594: Consider adding a CI configuration that builds stage2 with -O2 for AArch64.](https://gitlab.haskell.org/ghc/ghc/-/issues/24594)
> - The suggested fix is to run the “release” flavour on the nightly run. But the nightly run is not used (hardly at all) so I don’t know if that is a good idea. (To be fair, the nighlty is getting healthier.)
> 
> - [#24593: `putEnum` in `GHC.StgToJS.Object` could be simpler and more general (and more correct)](https://gitlab.haskell.org/ghc/ghc/-/issues/24593)
> - task
> 
> - [#24592: Off by one error in seekBinNoExpand](https://gitlab.haskell.org/ghc/ghc/-/issues/24592)
> - high prio compiler-crashing bug
> 
> - [#24591: Arity analysis fails badly](https://gitlab.haskell.org/ghc/ghc/-/issues/24591)
> - SPJ talked about this in the call
> - Missed opportunity at runtime performance improvement
> 
> - [#24590: Out-of-range literal warnings interact poorly with rebindable syntax](https://gitlab.haskell.org/ghc/ghc/-/issues/24590)
> - Yeah good to fix that. It’s a bit complicated because of the interactions between a bunch of different syntax-modifying language extensions…
> 
> - [#24589: `inline` may only inline the wrapper and not the worker](https://gitlab.haskell.org/ghc/ghc/-/issues/24589)
> - “Makes complete sense, I don’t think there’s very much we can do about it”
> - `inline` just isn’t a very useful function, maybe.
> 
> - [#24588: ghc-toolchain and configure disagree on whether windres exists](https://gitlab.haskell.org/ghc/ghc/-/issues/24588)
> - high prio bug in the new ghc-toolchain utility

---

<div class="post-metadata">

**Author:** ![ocramz](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/ocramz/32/3713_2.png) [@ocramz](https://discourse.haskell.org/u/ocramz)\
**Post date:** [March 27, 2024, 12:29pm UTC](https://discourse.haskell.org/t/devops-weekly-log-2024-03-27/9165/2 "2024-03-27T12:29:16Z")

</div>

Hi @chreekat , thank you as always for the nice update!

I might have missed out on this so apologies if you answered already:

- Where will the Stackage repo live? The one that’s currently under [`github.com/commercialhaskell`](https://github.com/commercialhaskell/stackage)
- Does the Stackage frontend need overhauling as well? I see [stackage.haskell.org](http://stackage.haskell.org) still has links pointing to FPCo and `commercialhaskell`.

Thanks!

---

<div class="post-metadata">

**Author:** ![chreekat](https://sea2.discourse-cdn.com/flex002/user_avatar/discourse.haskell.org/chreekat/32/2669_2.png) [@chreekat](https://discourse.haskell.org/u/chreekat)\
**Post date:** [March 27, 2024, 1:57pm UTC](https://discourse.haskell.org/t/devops-weekly-log-2024-03-27/9165/3 "2024-03-27T13:57:47Z")

</div>

Yo!

> [@ocramz](#):
>
> Where will the Stackage repo live?

I intend to keep everything under commercialhaskell for now, which includes several things that aren’t there yet (like stackage-server).

> [@ocramz](#):
>
> Does the Stackage frontend need overhauling as well? I see [stackage.haskell.org](http://stackage.haskell.org)

Well first of all, you stumbled on to my test site. 😅 (Maybe I’ll rename it since it’s misleading.) Stackage continues to live at [https://stackage.org](https://stackage.org).

Regarding content, links to commercialhaskell are still valid, as you may have now guessed. I know there are some GitHub links to fpco, but some of those point to repos that were already historically migrated to commercialhaskell, so those get redirected on the GitHub side.

Nonetheless, pull requests welcome! The two main repos are stackage-server and stackage-content. These will be included in my architecture documentation.