Abandoned Haskell Packages

#21

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.

#22

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).

2 Likes
#23

I did lift an eyebrow when I read your previous message TBH :slight_smile:

1 Like
#24

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.

4 Likes
#25

The Haskell Github Trust was created to help with this situation. Haskell Github Trust is for Other People’s Packages.

I sent you an ownership invitation.

3 Likes
#26

Thank you! I’ve accepted it

1 Like
#27

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.

1 Like
#28

Some packages are simply done from an engineering perspective and not every package has a corresponding github repo that you can monitor.

We already have enough processes for that:

  • NMU for GHC compat patches
  • package takeover for new maintainers

See hackage-trustees/policy.md at master · haskell-infra/hackage-trustees · GitHub

If hackage would automatically transfer ownership of my packages, I’d probably stop publishing them there.

1 Like
#29

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).