Open armanbilge opened 2 years ago
I am planning to execute #41 next week unless someone steps up.
There's no need to be this aggressive, but I am marking it unmaintained along with some others.
@rossabaker @armanbilge I can maintain this module, as it seems there's not much work to do. It will be my first "official" maintainer experience, so I will ask you for a few tips. Is that okay for you?
I chatted with @TonioGela in Discord. Since they are not a user themselves, I'd rather let this project sit unmaintained until there is real demand (or just let it naturally EOL).
Meanwhile there are unmaintained projects such as http4s-okhttp-client which is a dependency of Scala Steward. If you are interested in building maintainer experience, I'd be happy to help you out there :)
I would caution that one is the most technically challenging of the five. I'll add some commentary to the unmaintained project discussion. Update: my rants and raves.
I would caution that one is the most technically challenging of the five. I'll add some commentary to the unmaintained project discussion. Update: my rants and raves.
So, to sum up:
async-http-client
-> Why don't you use one of the many alternative backends?boopickle
-> just merging scala-steward PRsdropwizard-metrics
-> may be maintained but moving to prometheus or otel is advisedtomcat
-> See async-http-client
or use jettyokhttp-client
-> weird thread model and it's more worth investing in replacing it in Scala Steward with http4s-jdk-http-client as it supports proxyTo me, this substantiates more or less in a PR on Scala-Steward and merging PRs on dropwizard-metrics
as it's the only tool that can't be hot-swapped with anything similar (prometeus is a different metric tool).
That's a mostly fair summation. There are bridges between Dropwizard and Prometheus, but Dropwizard and Boopickle are the two on the list with the least direct alternatives.
That's a mostly fair summation. There are bridges between Dropwizard and Prometheus, but Dropwizard and Boopickle are the two on the list with the least direct alternatives.
Okay, so, if you, @armanbilge, other TL members think it's worth maintaining http4s-boopickle
and http4s-dropwizard-metrics
, I can take care of them (with a little kickstart babysitting from @armanbilge).
Otherwise, waiting for an actual user of these modules may be an option too.
(In the mean time I'll see if replacing the client impl in Scala-Steward it's feasible)
My interest is more in developing new maintainers for organizational health than in these modules themselves. If these modules interest you, then it's a good fit for everyone.
Alternate idea: if you're interested in maintenance more than specific libraries, there are Typelevel ones that are relevant, similarly easy, and would help me to have help: jawn and jawn-fs2 come to mind.
Alternate idea: if you're interested in maintenance more than specific libraries, there are Typelevel ones that are relevant, similarly easy, and would help me to have help: jawn and jawn-fs2 come to mind.
That's definitely more interesting. I'll take a look at those repos to get some more confidence with them. 😍
I could maintain http4s-boopickle
Cool! I think it was your contribution originally.
On most repos, we have series/* and main branches so we can support the production http4s (currently, 0.23.x) and development milestones (1.0.0-Mx). I haven't done that here yet. That could be achieved here by taking the current commit and branching off series/0.23. That also gives you the latitude to cut an 0.24 if boopickle makes a breaking change before http4s-1.0 is production ready (there are several examples of this in other repos already). But ... it's your show.
I'll create the team to make sure you have the rights.
Also, you'll want to revert my changes to the README last night. :)
Please comment if you are interested in helping to maintain this module :) Thanks!