Closed gaby closed 1 year ago
TBH I don't really have time/motivation to maintain this anymore. I would be happy to give publish access to new maintainers; because of the wide fanout these would need to be well known already to avoid supply chain issues. I'll ask around a few places like the tokio discord to see if I can get some interest.
In the meantime I'll at least try and merge the smaller things like updating dependencies soon.
@Nemo157 I'm willing to help. While I'm not very familiar with this project, I can at least merge PR that updates dependencies, plus I can pick things up bit by bit.
I use this project indirectly through reqwest, so I'm willing to take time to help with this.
Since reqwest depends on this, would it makes sense for this project to be moved into hyperium?
Hyperium would be a good maintainer pool to take over, IIRC they use the tokio discord server so I'll ask them about it there. I'll move the repo itself where whoever takes over wants it.
@Nemo157 I can help with PR's and updating dependencies/github workflows. I found this repo while tracking an issue with zstd. The version used by this library suffers from a bug that was fixed in v1.5.5
I'd be willing to help with maintenance of this crate. We don't use it in Actix Web (yet) but I suppose due to that fact, I have experience with using the underlying crates themselves in our compression tools.
I'm using this at work so have some interest in seeing it maintained. Would prefer not to take over yet another crate to maintain at this time, though.
@NobodyXu, @robjtede thanks for the offers, I've sent you both invites to the repo and crates.io.
I'm not really sure how much access a collaborator gets, if you have an idea of an organization the repo could be moved to let me know, or I have an org I've been moving some of my projects to so could move it and add you there to give you full owner access.
Thanks for the access 👍🏻
I think it's mainly triage perms by default. If we are able to control bors for merging that might be enough. (I'll need to learn bors.)
An org would be more suitable, imo. Not too worried about which one though.
Bors is going away, so moving to an org would also be needed to migrate to using merge queues (or you could just remove it and use normal merging if you want).
TIL GitHub has native merge queues now, sounds good.
Thank you @Nemo157
I think even using regular merge is ok, we can configure GitHub to require branches to be ip-to-date before merging.
@NobodyXu I've been using this strategy for a number of years with Actix Web, here's my view on it: https://github.com/Nullus157/async-compression/pull/199#issuecomment-1538627243
Closing as the repo migration and ownership assignments have completed.
@robjtede I agree that merge queue is better than requiring up-to-date branches.
Last time I tried merge queue, it's quite buggy, so I'm a bit worried.
I've been using merge queue on another project for a while without bugs (though I just hit one which seems to be triggered by having a non-ascii branch name, currently testing migrating to main
in another repo).
The default branch name in this repo did give me some pause, I'll admit :P
@robjtede Any chance of getting the updates to zstd merged? The current version used has a bug that was fixed in v1.5.5
Yep, I'm planning on going through open issues and PRs tomorrow.
Hello @Nemo157 can we get a status of this project? There's quite a few PR's that need attention. There is also some fixed that were introduced with zstd v1.5.5 that this repo is missing.
Thanks!