New maintainers? #39
Comments
|
Ping: anyone willing to help with this topic? |
|
Have you tried the formal process for taking over a package? |
|
@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? If there is no reply within a few weeks we can initiate the process with the Hackage administrators. [1] |
|
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? |
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 ( |
|
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 |
|
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. |
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:
|
|
@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 |
|
How do we move this forward @jonathanjouty ? |
|
@arybczak Thanks for the reminder. From the page on taking over packages:
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 BTW I recently started a project in which I'm using |
The last upload for |
|
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! 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. Instead of having the repository under a personal account, we could use an existing community org. or create a new one. |
|
@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 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. |
|
Awesome, thank you so much! 😄 |
|
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 |
|
@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). 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 |
|
@jappeace Hopefully I'll make a release next week. |
|
|
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
The text was updated successfully, but these errors were encountered: