Then it seems to me like there’s room for improvement in this process, because we are still in this situation where popular packages can fall behind despite the fact that there are users who will send fixes within days.
The last package that pushed me over the edge to start this thread was beam-postgres, which isn’t in the latest Stackage LTS, so it requires tweaking to get it to compile with GHC 9.6, which I had no trouble doing on my end, but I was left with disappointment to see the package in this state.
I’m going to take this opportunity to make a self-promotional aside to point out that Opaleye typically supports a new GHC within days of release (although its dependencies don’t always).
Stackage LTS for GHC 9.6 is the largest snapshot ever, containing 3300+ packages. So if beam-postgres is not there, I think this package is not that popular after all, simple as that. No need for gloom and doom.
I assume we are talking about Support GHC 9.6 in beam-postgres by kmicklas · Pull Request #694 · haskell-beam/beam · GitHub? Note that the author of this PR is a maintainer of beam-postgres himself, so it’s not like the package is abandoned; things just fall through the cracks from time to time. It seems to be a simple Hackage revision, so you can raise an issue for Hackage Trustees, but I would start by simply pinging the maintainer in the PR.
Can I suggest that we allow ownership to decay? Decay would happen if the package isn’t updated over time and if PRs aren’t processed over time.
If package ownership has decayed below some limit, then some other interested party could get access – this would require some (undefined) technical and (undefined) process implementation.
The point of my comment is that the above topic is another symptom of something we see all the time, namely a public request to take over a package. The process to take over a package takes time and is rather cumbersome. Moreover, not everyone wants to take over the package, they just want the PR to be executed, or possibly refused, but at least dealt with. Letting others have some kind of update access would simplify all this.
I like this idea, with some caveats. Firstly, I wouldn’t want it to be forced upon maintainers. Secondly, I don’t want a package to be taken over just because feature development has stopped – that is a valid state for a maintained package!
I agree that the current update procedure is cumbersome and I would prefer a more straightforward procedure that is worked out ahead of time.
This is my intention for Opaleye’s policy of backup maintainers. There is a specific criterion for when the policy is triggered (I am “unavailable or unresponsive to maintenance requests for n months”) and a specific outcome in that case (a particular person becomes entitled to full ownership of the package).
I’d be happy if other maintainers wanted to adopt a similar policy for their own packages (and perhaps they have ideas for improving the policy).
