Find a backup maintainer

[hasufell]

Life is full of surprises. GHCup is a small tool, but has seen such wide adoption that having only a single active maintainer is problematic for the project and the community.

My concerns with finding such a backup maintainer are:

• sharing of similar visions (user experience/interface)
• sufficient knowledge of distribution issues (experience in linux distro development is a huge plus)
  • lots of times I build unofficial bindists, maintain FreeBSD CI etc.
• good communication skills (ghcup is where all tools come together... I have frequent meetings with GHC devs, HLS devs, etc.)
• being on top of latest tooling development is important
  • e.g. tracking progress on cabal releases, the regressions, when to bump 'recommended' channel etc.

Code wise, I consider GHCup rather simple. So it doesn't require a lot of engineering experience. However, a lot of effort has gone into making it safe, esp. wrt filesystem operations. So a healthy level of paranoia is warranted.

Since GHCup is the entry point to Haskell tooling, it has also become a nexus of bug reports about all sorts of things. I like to think that the project drives general improvements to end user experience, whether that's specific to GHCup, related to release management of other tools or features that are specific to HLS/vscode-haskell etc.

---

CCing some people that might be interested or have ideas: @david-christiansen @Kleidukos @juhp @angerman @mpilgrem @mpickering @bgamari @arrowd @chreekat

[hasufell]

Some more CCs: @Bodigrim @michaelpj @fendor @tomjaguarpaw @jonathanknowles @wz1000 @gbaz @chshersh

[mpilgrem]

I recognise the problem - I have similar thoughts about the Stack project - but I don't have a solution. In the case of Stack, I've been mulling over 'advertising' on the Haskell Community. In trying to look after Stack, I've realised the challenge is not so much 'depth of knowledge' but 'breadth of knowledge'. Sometimes it feels that to fix a Stack thing I have to learn about half-a-dozen non-Stack things (which is fine; I like learning).

[arrowd]

I'm not interested in ghcup itself, but I do care about FreeBSD CI's for various Haskell projects. With that I can help.

[chshersh]

My view on this is that HF should pay a full-time developer to work on GHCup. If the budget allows, having more developers is even better.

My experience with Iris shows that it's almost impossible to make volunteers stay in the project (even though, Iris was designed from the very beginning with the primary goal of mentorship and eventually passing the project away to others).

I have huge respect for @hasufell for doing all this complicated and (at times) ungrateful work with volunteering efforts only. But I can't see how someone else can be motivated enough and have enough knowledge to continue supporting GHCup for free.

[tomjaguarpaw]

I appreciate your proactive attitude @hasufell. It's well worth thinking about how we make our critical projects and infrastructure resilient. I'd love to see the HF contribute in some way. I don't have the bandwidth to drive something like that myself but I will definitely pay a keen interest to how it develops.

[chreekat]

I think being a backup maintainer for GHCup would be a good use of the Haskell Foundation DevOps role. GHCup is an important consumer of GHC and I'm already watching this repo and trying to help triage issues.

But I do need to be careful about focusing on my priorities, which are still purely the GHC contributor workflow. @hasufell, have you thought about how you would want to have other maintainers contribute?

[david-christiansen]

One way to see GHCUp is as a system for delivering the results of GHC's CI into users' hands - this is even more true with the advent of #130. I think it definitely makes sense for @chreekat to be seeing the process from both sides, and helping out on this one is a great way to do that!

[hasufell]

I think there are some ways forward short-term:

• take any help we can get, even if it's narrow scope contributions... one doesn't have to cover everything
• document all processes, development practices etc. better

have you thought about how you would want to have other maintainers contribute

Indeed there are two or three main areas:

1. ghcup development: new features, bug fixes
2. ghcup-metadata maintenance: adding new GHC/cabal/stack/HLS versions, deciding when to bump 'recommended'
   • also gets us involved in those tools release management processes (especially HLS)
   • sometimes we need to build bindists manually or fix them (e.g. alpine, FreeBSD, ...)
3. all things CI and release management

[hasufell]

I'm stepping away from my Haskell community involvements for now.

That means there won't be any new releases for the time being (at least from me). @bgamari has commit access to both repositories (ghcup-metadata and ghcup-hs). His GPG key is documented here. So he can merge metadata PRs, but has to sign the metadata files as well.

That also means there probably won't be any unofficial bindists for stack, cabal, GHC alpine linux/FreeBSD etc.

I've also added a couple of other maintainers to the metadata repo (including @mpilgrem), in case they're interested in maintaining it.

You can reach me via email in case of emergency.

[david-christiansen]

@hasufell - thank you so much for all the work you've put in here, and for handing things over in an orderly manner.

To users: @bgamari will be keeping things running smoothly in the near future. He's got a lot on his plate, however! For the longer term, the HF and our partners are in the process of coordinating the ongoing maintenance and further development of GHCUp so we can build on the excellent work done by @hasufell.

Thanks again, @hasufell!

[adamgundry]

Huge thanks @hasufell for all your work on GHCup! It's been a great service to the Haskell community. You really have dramatically improved the user experience with the Haskell toolchain, not just for new users but also for those of us who have been installing GHC upgrades for more years than we care to remember. I wish you all the best.

[simonmichael]

Hear hear, well said ! I didn't want to "make it real", but thank you @hasufell and good luck, whether you return to ghcup or not.

[hasufell]

Thanks all.

After talking with @simonpj, we agree that it's probably essential that I stay in an overseeing and supporting capacity, at least mid-term, ensuring ghcup stays on track and true to its original philosophy.

Short term, I'll be available in emergency cases and will support efforts to get more developers and maintainers on board.

But it's clear that I can't be the only one running the show anymore.

The two most time consuming tasks in GHCup are as follows:

1. maintaining the GHCup metadata: this is a distribution channel. We track releases of tools, communicate with maintainers regularly, test bindists (manually as well), keep an eye on downstream consumers (github images use ghcup too), evaluate when to bump the 'recommended' version etc.
2. giving support: since GHCup is the entry point into the Haskell ecosystem, it's also the entry point to both positive and negative experiences. We need maintainers who are able to debug installation and bindist issues and contemplate improvements to the user experience.

There are many other things, but those don't need immediate handover:

• the whole ghcup <-> HLS <-> haskell-vscode chain is somewhat involved and I think only a couple of developers have a good understanding of how the pieces fall in place. This is essential for the end user experience.
• development of new features: nightlies, cross compilers, bindist revisions, etc.
• driving user experience

The last point is what started this whole thing. In my opinion, we have to look at Haskell not as a language, not as a compiler and maybe not even as a product, but as a user experience. I'm obsessed with user experience. This is hard, because of sometimes diverging ideas of what a good user experience is.

Under this vision, it's easy to get burned out, because the user experience is everywhere: release policies of GHC, changes to the language, changes to base and core libraries, platform support, editor support, distribution issues, integrations between tools, etc.

This has been too much. I've described some of these over-arching ideas in the HF thread: haskellfoundation/tech-proposals#48

But it was too broad and too ambitious. It's also a full time job and occupies large amounts of my time just thinking about these things. Additionally, as some may know, I'm having certain health issues that make it harder for me to code through an entire weekend and finalize all the ideas I might have. The backlog keeps piling up and it's getting harder and harder to prioritize. Especially myself.

I feel I also have to express the ideas behind GHCup more clearly. I think a common misconception is that it's just an installer. But it's in fact a distribution channel and this has certain implications and is one of the reasons it's a lot of work.

---

So, long story short: this project needs fresh blood. People with more motivation to maintain and give support and also implement new stuff (e.g. TUI improvements: #850).

It should be a community project (e.g. nightlies were initiated by the HF). But it also needs someone to keep the original vision alive, which I'm happy to do mid-term.

As for the immediate short term plan:

• @bgamari will keep things running, but this should be temporary
• I hope some of the stack folks, e.g. @mpilgrem or @juhp can help maintain the metadata portion of GHCup
• current contributors like @arjunkathuria need to stay engaged and receive timely reviews. I can't promise to be able to do that at the moment, so we need someone experienced, who's ok to dig into the codebase. I'd hope @fendor could chime in, but he's one of those people already contributing literally everywhere and I'm worried it'll be too much.
• I'll occasionally chime in on design decisions on PRs if I have the capacity
• Until we have a more stable setting, @bgamari can merge bugfixes and the like on his own judgement, but give me a week or two to veto in case I see something obviously is wrong
• someone needs to start doing the next ghcup release. The current prerelease can be released as proper. This is a good opportunity to see if the release documentation is sufficient: https://www.haskell.org/ghcup/dev/#releasing (I'd actually suggest to do another version bump)
• someone needs to do basic project management and make sure people are actually talking to each other and are informed (I've been having meetings with @mpickering for example and attended HLS monthly meetings regularly). Maybe @Kleidukos can help out here, but she's already spread quite thin.

I hope this gives some more clarity as to how I hope things can move forward.

[chreekat]

@hasufell thanks from me as well. I'm glad you're able to take care of yourself, and I hope this step you're taking brings a lot of personal results. I think GHCup is in capable hands and a lot of people are invested in it, myself included.

For the sake of continuity of vision, when you think of a distribution channel, what are other good examples that are worth emulating?