The Haskell Infrastructure Needs New Maintainers

Development
1

Fellow Nix & Haskell Hackers,

For the last couple of years, I felt responsible for the Haskell infrastructure in Nixpkgs, but now the time has come to pass the torch on to other people. I’ll happily continue to contribute to pkgs/development/haskell-modules, obviously, but I’d rather not feel “responsible” for it any more. The maintenance aspect of it all has grown a little old on me. I’d particularly like to remove myself from .github/CODEOWNERS so that Github no longer assigns every PR that changes the Haskell code to me for reviewing. I feel like there are plenty of other contributors who can take that function over from me and do a much better job at it than I’d do.

So consider this a call for volunteers. If you care about the Haskell infrastructure in Nixpkgs, please consider putting your name into the CODEOWNERS file (https://github.com/NixOS/nixpkgs/blob/master/.github/CODEOWNERS#L54-L59) to help ensuring that new contributors don’t break anything by innocently trying to override foo = dontCheck self.foo. Help out newbies who edit hackage-packages.nix directly and point them to the configuration files. And please peer review changes made to the generic builder, the ghc wrapper, and all the other useful code that we offer so that people who extend and improve those facilities have the benefit of a second pair of eyes.

I’ll be around to answer questions as much as I can and I’ll also make an effort to document the current procedures a bit (in the form of an RFC?) so that everyone can look at the status quo for guidance.

Best regards
Peter

7 Likes
2

Hi, Peti.

Thank you for all you’ve done to build and maintain the Haskell infrastructure and for working to pass the torch instead of letting it burn out.

Do you have any comments on updating the Haskell packages? Are you planning to keep doing that? I know how to run the Haskell updater scripts and I’d be willing to do that, but I do not know what process (if any) you have to ensure the updates don’t break a bunch of stuff.

Ryan

3 Likes
3

I made a PR to add myself https://github.com/NixOS/nixpkgs/pull/43894

Ryan

2 Likes
4

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:

LANG=en_US.UTF-8
MAILTO=foo@example.org
NIX_REMOTE=daemon
PATH=$HOME/.bin:/run/wrappers/bin:$HOME/.nix-profile/bin:/nix/var/nix/profiles/default/bin:/run/current-system/sw/bin

# minute hour  mday month wday   cmd
30       02    *    *     *      cd ~/src/cabal2nix && git pull -q && ./update-nixpkgs.sh

The new hackage-packages.nix version is then pushed to the haskell-updates branch in https://github.com/peti/nixpkgs, which Hydra - 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. :slight_smile: 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.

2 Likes
5

Hi Peter,

I, and probably many others, owe you a big debt of gratitude for keeping the Haskell infrastructure in such good shape. 3 years ago I started using Nix in anger at LumiGuide and succeeded partly because Haskell was so well integrated into nixpkgs.

To be in CODEOWNERS requires write access to the repository. What would it take for me to get commit access to nixpkgs so that I can review PRs?

Bas

6

@basvandijk note that anyone can review PR’s. Commit access is not needed, nor does one need to be in the CODEOWNERS file. That file is only for exactly that; describing who owns what.

7

note that anyone can review PR’s.

Actually, I don’t think that’s accurate. Anyone can comment on PRs, but only members of the project can review them.

@basvandijk, I’ll see what we can do about getting you added to the team on Github. That shouldn’t be a problem.

8

I can confirm that even as a non-member of the nixos project I can review PRs. The only difference is that the icons for my review don’t have the pretty deeply saturated colour of member reviews :wink:

The reason we want people in CODEOWNERS is that they will automatically be notified and reviews will be requested from them for PRs modifying the files in question, which I’m sure is good for reducing time-to-merge.

9

That is interesting, thank you for letting me know. I just played around for a bit, and one thing I noticed is that I cannot assign any reviews to the github user basvandijk. Github lets me request reviews only from members, not contributors. Not sure what the reasoning behind those choices are … Anyhow, let’s not derail the thread.

10

I think we owe you a lot Peter for all of the hard work you’ve done. I must admit that due to Haskell nixpkgs outstanding infrastructure, it inspired me to learn Haskell.

I hope we can find another way to maintain infrastructure and come to mutual agreement in the future and keep making Haskell the best language support in Nix :slight_smile:

Domen

1 Like
11

Done. Hydra - Jobset nixpkgs:haskell-updates now builds the haskell-updates branch from the main Nixpkgs repository and updates are pushed there once a day, too. Case in point: LTS 12.2 came out just a few hours ago. https://hydra.nixos.org/eval/1470385 is the first evaluation that uses the new version.

3 Likes
12

I’ve now added myself to the Haskell section in CODEOWNERS.

2 Likes
13

I’m pretty late to this thread, but I’d also like to help with maintenance of the Haskell infrastructure.

1 Like
14

A big thanks also from me, peti!

Your work has made many Haskell projects possible, including many of my side projects and some of my professional work.

:+1:

1 Like