pool
pool copied to clipboard
bos
New maintainers?
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
@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
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?
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.
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.
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.
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.
@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 Thanks for the reminder.
From the page on taking over packages:
- Try to contact the maintainer. Give him/her reasonable time to respond.
- State your intention to take over the package in a public forum (we recommend the haskell-cafe and/or libraries list). CC the maintainer.
- Wait a while.
- Send an email to the hackage administrators ([email protected]), with a link to the public email thread.
- 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.
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.
(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)
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!
@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.
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.
The last upload for resource-pool was in 2014. A PR was made in 2015 that received no response from any maintainer. How do you distinguish "unmaintained" and "too slow for the taste of some downstream users"?
As I described, you make some PRs and prod for a response. Or make more serious efforts to contact the package maintainer. I'm glad this situation worked out well. But I just want to caution that package takeover requests should be used when other channels have been exhausted, not proactively, no matter how one feels or presumes that a package is maintained. Ideally a takeover request would only be filed if there were pending and important changes that had not received attention over some notable span of time, and only filed if there was a specific PR that needed addressing, and which, despite repeated efforts, had not been addressed. It is a tool of last resort.
@basvandijk Thank you! Sorry if GitHub notifications was not the best way to contact you, should have tried to find your email address as well.
FYI I have replied to the Hackage admins, since we don't need to move forward with the take-over process anymore.
@basvandijk One more request: are you able (and willing) to add @arybczak as a collaborator to this GitHub repository?
I contacted @basvandijk by email and he does not have admin rights to grant collaborator access to this repository. We will therefore be forking the repository and updating the Cabal file, and aim to grant all existing maintainers admin rights on the new repository.
Instead of having the repository under a personal account, we could use an existing community org. or create a new one. Anybody have any suggestions on this front?
I merged one, two, three into my fork and I'm going to release it under a separate name. @bos @basvandijk do let me know if you want to merge it back into the upstream. I still largely prefer it to be a non-takeover transition in the end, hence the reason for the fork for now.
@avanov note that @jonathanjouty and @arybczak both have hackage upload rights as per the above discussion. You can contact either of them about prodding for a release as well
I mean, sure. I can even create the accumulated PR, but I needed the merged changes asap, hence the fork that everyone else can also test against their projects with a minimal effort.
@eviefp feel free to file PRs that improve footprint/stability/observibility/performance, I'm eager to merge them regardless of the progress here, and then contribute them back via accumulated PRs. But not so much regarding PRs with new features, as they may diverge from the initial intent of the package.
Another point regarding community benefits and forks that I didn't have during our last interaction but which I do have now: after trying Backpack I'm now confident that forks do not worsen Haskell ecosystem at all. Package maintainers should embrace mixins and drop-in replacements that Backpack enables. Given the signature packages are implemented, any fork could be as maintainable and embeddable as the main upstream package, and the community will be able to easily choose/experiment with the alternatives.
@jonathanjouty Any update on where the new repository is? Hackage hasn't seen an upload since 2014 still and the page points here.
If this is a problem of maintenance time/energy then I don't mind volunteering time to help work on this.
@parsonsmatt it's at https://github.com/scrive/pool. I wanted to wait a little bit with the announcement after more testing, but since you're asking, here it goes.
The implementation was rewritten based on Control.Concurrent.QSem for fairness and much better throughput (especially in multithreaded environments). AFAIK it fixes at least #27, #31, #36 and #38.
We're running this in production without issues. I want to add support for maximum amount of waiting threads, maybe also #35 (or at least apply the suggestion of making the pool config a data type so it can be extended easily in the future), then write a bit more about the changes in the README.md and release a new version.
Great, thank you so much @arybczak, I haven't done so well following up so it's amazing to see you have :)
@bos would you be willing to have this package moved to https://github.com/haskell as many of your other projects have been?
For those curious I've opened a PR that compares the current state of the repo with the scrive fork, which will (at some point?) get released and become the new official repo https://github.com/bos/pool/pull/45
@arybczak I'd like to suggest making a release on hackage. it looks like the scrive fork is much better then what's currently on hackage, (after reading parsonsmatt review). I also suggest bringing the fork under scrive's maintainership permenantly and deprecating this github repository. You can modify the source url and issue tracker in the cabal file for example.
Having two resource-pool libraries is currently causing me a bit of a headache, because flora wants the scrive fork, whereas odd-jobs uses the hackage one. so when I wanted to add odd-jobs to flora it broke down (the withResource function suddenly had a different type signature).
