Do you have any comments on updating the Haskell packages? Are you planning to keep doing that?
The process that updates the package set is basically a cron job for https://github.com/NixOS/cabal2nix/blob/master/update-nixpkgs.sh that runs once per day on my private workstation:
# minute hour mday month wday cmd
30 02 * * * cd ~/src/cabal2nix && git pull -q && ./update-nixpkgs.sh
hackage-packages.nix version is then pushed to the
haskell-updates branch in https://github.com/peti/nixpkgs, which https://hydra.nixos.org/jobset/nixpkgs/haskell-updates builds regularly. Every couple of days, I look at the state of the builds. If all good, I just squash the commits into one and merge them to
master. If there are sufficiently many new build errors, however, I usually spent an hour or two fixing them, waiting for re-builds, and merging then. I didn’t care much about a few packages breaking every now and then, but if a new version of
base-compatcomes out, fails its test suite, and therefore causes 3000+ new build errors, then that seems sufficiently important to take a look at before merging. I usually tried to get upstream involved rather than just fix things locally for Nixpkgs. More often than not, reporting an issue was all I had to do and then the build error magically disappeared after 24 hours. I think I did take seriously, though, is evaluation errors. I’ve always wanted 0 evaluation errors in the Hydra job. (The number of evaluation errors the build job for
master routinely has is a completely disgrace, IMHO.)
Now, I can keep that cron job running and make sure that it succeeds. I would love to have that job run on self-hosted nixos.org hardware, but I’ve wanted that for years and never could make it happen, so I don’t expect that to work out any time soon. Doesn’t matter much, though. The task is so lightweight that basically everyone can run that script. The more important part is to have the updates tested by Hydra before exposing
master to the new versions.
I should probably change my setup to push to the main repository rather than my private fork so that Nixpkgs committers can access it (and push to it), too. Back in the day, I set it up differently because pushing to the main repo used to trigger a notification e-mail every time and that seemed wasteful for automatic commits. Maybe it’s no longer a concern, though. I not even sure whether those e-mail notifications still exist. I think they disappeared when the mailing lists moved to Google? Anyhow, I’ll just change the script to push to
haskell-updates in the main repo and I’ll also update the Hydra config to build the branch from there. If that causes problems for anyone, we’ll see whether we can figure out a better solution, okay?
I’ll can certainly help to keep those updates in shape for a while. Ultimately, I’d be very happy to see this evolve into a community effort that has more than just 1 or 2 people involved. I suppose the first step is to increase awareness of those procedures.