DevOps Weekly Log, 2023-11-22

Yes, it’s another weekly log.

BONUS: I’m trying a new thing where I summarize the tickets covered in the weekly GHC triage meeting. I’ll put it at the bottom of this log!

Since last time, I finished fixing head.hackage to comply with a recent bugfix in Cabal. (If you don’t know what head.hackage is, then don’t worry, this never affected you.) The problem was that head.hackage’s repo timestamp was not updated in a timely manner. I fixed this by regenerating the timestamp once a night. I implemented this as a scheduled GitLab pipeline on the head.hackage repository.

In hindsight, I’m not sure a GitLab pipeline (or any CI pipeline) is the right choice for jobs like this one. Although CI pipelines can be used to provide some UI and visibility for routine batch jobs, that’s not what they’re designed for. But I’ll leave it for now.

Once head.hackage was done, I moved back to the Stackage migration. Yesterday we migrated the hackage-metadata-refresh process to the new server. This process updates three repos:

(These are alternate views into that are used by Stack.)

Today, we migrated the hackage-mirror-update process that keeps up to date.

We’ve now migrated three background Stackage processes. These were all the “easy” ones: they are scheduled batch jobs and nobody will notice if they stop running for 10 minutes or so. That made it easy to gracefully move them to a new server with no external consequences. However, they still push to an S3 bucket owned by FPComplete, so the migration isn’t complete. The data migration will take place after the process migration.

The remaining processes are public facing: and (There is one other background process, but it needs privileged access to the Casa server, so I am considering migrating it in lockstep). These migrations will be visible to users, so I will announce the migration window once we are ready for it.

Now for the ticket triage summary. In this log I will summarize the last two triage meetings.

I may or may not keep doing this! It doesn’t add a whole lot of extra work for me, since I am mostly just observing GHC maintainers during this meeting anyway. And I think it could be valuable to give a glimpse into the workload of GHC maintainers to demonstrate how much is constantly going on. But as I am not an expert, my summary of events will be faulty and my coverage of the issues will be sparse. So if this is valuable to you, please let me know.

My best effort summary of recent tickets would be:

  • Multiple issues caused by a Darwin upgrade
  • Bugs in newish language extensions
  • Bugs in newish features, like -finfo-table-map
  • Problems with linking
    • Primarily on Windows. Both linking (in general) and Windows (in general) are perennial fonts of joy
  • Tricky issues uncovered about async exceptions
  • A long, long tail of random stuff.

Thanks for reading!

See the full dump of issues and my notes by clicking here.

Thank you for sharing this !

re. the Stackage migration: I’d be curious to know the process and data architecture, are you following or putting together a document for this?

1 Like

Yes! I needed to dig into the various components to understand the dependencies so I would avoid breaking anything during the transition. Bits and pieces of it were already documented previously, as I discovered. But I would like to make an up-to-date version of the docs I have found and fill in the gaps where they exist.


It’s great to hear about the stackage progress in these updates. Stackage starts to feel more like a core asset of the Haskell community (which I believe it is). And closer integration with the hackage machinery (or at least, one person with visibility into both) sounds like a big advantage. Congrats on the progress, it sounds like a big job.

Both your high level “outsider’s summary” and detailed commentary on current GHC dev activities are very interesting and useful ! As long as they’re not too much of a burden.