-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Find a backup maintainer #848
Comments
Some more CCs: @Bodigrim @michaelpj @fendor @tomjaguarpaw @jonathanknowles @wz1000 @gbaz @chshersh |
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). |
I'm not interested in ghcup itself, but I do care about FreeBSD CI's for various Haskell projects. With that I can help. |
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. |
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. |
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? |
I think there are some ways forward short-term:
Indeed there are two or three main areas:
|
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. |
@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! |
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. |
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. |
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:
There are many other things, but those don't need immediate handover:
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:
I hope this gives some more clarity as to how I hope things can move forward. |
@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? |
Huge thanks to @hasufell. ghcup has become a critical part of Haskell infrastructure in a very short time, which is a testament to both your design expertise and engineering excellence. I really hope that others feel able to step up to contributing, as part of the ghcup team. Please just say here "I'd be happy to help" and what sorts of things you could do (looking at @hasfell's list of tasks above). I hope that the HF might help with leadership/coordination, alongside @hasufell. We are a community. Heroic efforts by individuals can get things going, but to make them sustainable in the medium term takes a team. And that team is us. |
I'd like to chime in to add my voice to those thanking @hasufell. Julian, you've done a huge amount of work for the Haskell community and I am very grateful for that. I first used GHCup about four years ago and it was a wonderful improvement to the onboarding process. Since then GHCup has added even more critical features, for example becoming an installation method for Stack and HLS, and becoming the one official recommended way of installing Haskell. Julian, you have a very clear and constructive technical vision which has contributed to the success of GHCup, and the Haskell community in general. Your deep technical expertise in software distribution and related systems programming is second to none in the community, as far as I can tell. We are very fortunate to have had the benefit of your expertise for so long. There is far more work that needs to be done in the Haskell community than there are people to do it. The unfortunate consequence is that our most prolific contributors can easily become exhausted. I'd love to see the HF do more to tackle this problem. I would also love to be able to chip in to help with this particular issue, but I've been on the threshold of burning out all of 2023, so I've stepped back quite considerably in my contributions too. |
You were(are) the best, Julian. Thanks for everything ! |
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:
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
The text was updated successfully, but these errors were encountered: