New maintainers?

[jonathanjouty]

There are a few open PRs and issues with no replies, it seems like @bos is not actively contributing since a few years, which is understandable given his current position.

@basvandijk is listed as a maintainer on Hackage, but with little activity on this library.

I know @scrive would be happy to take over maintenance, but perhaps @hasura are interested too? (cc/ @0x777, @Vladciobanu: due to the unpublished fork with recent commits).

From comments in #38 it seems like @Simspace might also be interested (cc/ @asivitz, @mjrussell), or even @parsonsmatt.

The library is very good as it is, and there is not much that needs to change, and it would be best to not have to publish a fork given the usefulness of this library and its widespread use: https://packdeps.haskellers.com/reverse/resource-pool

[jonathanjouty]

Ping: anyone willing to help with this topic?

[gelisam]

Have you tried the formal process for taking over a package?

[jonathanjouty]

@gelisam no, but thanks for pointing that out. Let's get the ball rolling...

---

@bos or @basvandijk are you willing to add myself [1] or a colleague [2] to the maintainers list?
https://hackage.haskell.org/package/resource-pool/maintainers/

If there is no reply within a few weeks we can initiate the process with the Hackage administrators.

[1] jonathanjouty_scrive
[2] arybczak i.e. @arybczak

[eviefp]

Apologies for the late reply. I would also be interested in reviving this library.

I have no experience as a hackage library author, but I would love to see some of the patches we've been doing on our Hasura fork discussed as possible additions to the official pool library.

On the other hand, I would not want to simply be pushing Hasura-specific patches onto a general purpose library, which means I think it would ideally be a process where multiple people talk it over and decide. Perhaps some form of "joint custody/maintenance" over this package?

What are your thoughts?

[avanov]

The library is very good as it is, and there is not much that needs to change, and it would be best to not have to publish a fork given the usefulness of this library and its widespread use: https://packdeps.haskellers.com/reverse/resource-pool

If there is no reply within a few weeks we can initiate the process with the Hackage administrators.

while I agree that preserving the original name of the package on Hackage is the best scenario, I can't help by notice that giving a time limit on a decision to add new maintainers looks like a hostile takeover involving Hackage admins. Authors should have an exclusive control over package permissions on Hackage, otherwise the platform is not trustworthy enough, and one may choose to never publish there again.

Why not forking and uploading it under a different name with preserved module namespaces (resource-pool-fork-<maintainer>)? Should the original maintainers express a desire to merge changes in the future, that can be done easily. It's also a no-issue from a third-party perspective - if a dependency requires a version/boundaries bump, changing the name of the package along the way takes no extra effort. The new maintainers don't have to wait for the decision of the original authors either.

[avanov]

I can volunteer to publish my fork with one merged PR from the current list of PRs if that works for the rest. I'm also happy to merge it back here, if and when @bos and @basvandijk are ready for it. My interest in doing it is to benefit from stock Nix binary cache of Hackage packages, as right now I have to keep a local cache for updated resource-pool locally for my projects.

[eviefp]

There are already multiple forks, including one managed by Hasura. The problem with forks is that it makes it a lot harder to justify working together. Our fork already has some commits in that I'm sure at least some folks would disagree with. So instead of having one single library driven by common sense, we'll end up with multiple forks driven by specific use-cases.

That's probably better on the short term for the companies involved, but worse in the long term, and worse for the Haskell ecosystem overall.

[avanov]

So instead of having one single library driven by common sense, we'll end up with multiple forks driven by specific use-cases.

Merging/porting other forks into another fork that encompasses some of them is ok in my book. If maintainers of the new fork are willing to include other forks into their version, they usually don't need a consent from other forks' maintainers, as the license permits that and there's no violation of authorship and it doesn't take control from the forks. It's definitely better than taking over the main package without a verbal and/or written consent from the authors on the basis of timing.

The principle here is whether a particular fork is generic enough (in the spirit of the original repo) and whether inclusion of other forks contributes to the possibility of successful merge with the original repo in the future. Kernel development is somewhat similar - there are many vendors with their own patches, and some patches get accumulated together in "aggregate" forks that serve particular domain goals, and sometimes they successfully get merged into the upstream, if they are found to be beneficial to wider audiences. If README sections of the forks clearly explain their differences, it's enough to guide the users.

Note that the scenario with forks is free from the following concerns that one has to answer in the scenario of taking over the original package:

• if the original maintainers and the author of the package express a desire to take their control over the package back after a while, would they be able to do that at once or will it require a consent from new maintainers?
• if it will require a consent, why was that consent not necesssary at the time of taking over the control from the original maintainers?
• what happens if the interests of the new maintainers are not aligned with the interests of the original maintainers, when they return back? I suppose in that case they would be offered to create their own fork, which gets us back to square 1.

[jonathanjouty]

@avanov you make valid points, and are asking important questions, and ultimately these issues do concern the wider Haskell community.

However, there are no concrete and specific answers to those questions as of today.

On the other hand, as pointed out by @gelisam, there is an existing formal process [see 1 & 2], with powers that have been granted by the community to Hackage Trustees.

If the scenarios you describe do arise, I imagine answers to your questions can be handled on a case-by-case basis by the Hackage Trustees.

Hopefully, with that information, we can keep this issue on-topic, but please do feel free to discuss the problems of this approach in other community forums.

[1] https://github.com/haskell-infra/hackage-trustees/blob/master/policy.md#4-full-transfer-of-ownership
[2] https://wiki.haskell.org/Taking_over_a_package

[arybczak]

How do we move this forward @jonathanjouty ?

[jonathanjouty]

@arybczak Thanks for the reminder.

From the page on taking over packages:

1. Try to contact the maintainer. Give him/her reasonable time to respond.
2. State your intention to take over the package in a public forum (we recommend the haskell-cafe and/or libraries list). CC the maintainer.
3. Wait a while.
4. Send an email to the hackage administrators (admin@hackage.haskell.org), with a link to the public email thread.
5. The admins will grant you maintenance rights or upload a patched version for you.

I think we have safely crossed the threshold for (3), even though I did not post in the recommended public forum I think this discussion should be sufficiently public to meet the criteria, so I will proceed with (4), cc'ing you @arybczak and requesting they grant you maintenance rights.

[gbaz]

The package takeover process is for unmaintained packages, not packages where the maintainer works at a pace that is too slow for the taste of some downstream users.

That said, I find this whole thread somewhat bizarre. Yes there are some issues and PRs without responses, but are there specific PRs that you would like to see merged which have not been? Otherwise, if there are improvements you would like to make, why not simply make those improvements and submit them as PRs? That's the best way to prove yourself as a potential co-maintainer, and if you cannot get action on those PRs, then that would indicate further why a takeover request or fork might be in order. But as it stands, I see a discussion on "new maintainers" and process etc but not a lot of discussion about specific contributions/PRs that people feel they would like action on and which have not been.

In the open source world, the first step is always to try to contribute and collaborate. Code talks, everything else walks.

[gbaz]

(further, if there is code from the forks mentioned which people have not contributed upstream -- then why not? maintainer is just a set of responsibilities coupled with certain authority/ops rights. anybody can contribute code)

[basvandijk]

Hi @jonathanjouty, sorry for the much too late response. GitHub notifications escape my attention too much these days.

I'm happy to add you as a maintainer on Hackage!

[basvandijk]

@jonathanjouty @arybczak you're both new maintainers of resouce-pool on Hackage. I hope you do a better job maintaining the package than I did.

BTW I recently started a project in which I'm using resource-pool so I've a renewed interest in the future of this package and would also help out maintaining it.