Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Application as a co-maintainer #742

Open
GlenDC opened this issue Jan 9, 2025 · 0 comments
Open

Application as a co-maintainer #742

GlenDC opened this issue Jan 9, 2025 · 0 comments

Comments

@GlenDC
Copy link

GlenDC commented Jan 9, 2025

Hi, http is a critical piece of the prime FOSS project of my company, rama. And as such we even have it embedded and exposed it directly in the core http types crate and rama::http module: https://docs.rs/rama/latest/rama/http/index.html.

I love this as where it makes sense I do like to work within and with a wider ecosystem. However given that this crate is critical in the http part of that project and I honestly do not want to fork yet another project (unless it is needed) I would prefer to continue using this crate.

Same goes btw for other libraries of hyperium such as https://github.com/hyperium/headers. What you read here also applies for that crate.

There are on both crates a lot of open issues:

  • Can I help you as a co-maintainer and start tackling some of these issues?
  • I understand that you have strong opinions around RFC compliance and such, which I do respect. But would you be interested in features and escape API's so one can more easily extend this crate within their own code by building on top of a lot of what this crate has to offer. Examples are:
    • Make it more easy for someone to add headers that you do not wish to add (you use a neat macro for this, but do not expose it in any way, so one would have to copy paste it)
    • In the typed headers crate you often keep the options for a header very limited. E.g. the Content-Type as a random example has some options, but anything not fitting in there, you kinda are out of luck.
    • and so on and so on

You are the maintainers so I would respect any answer or choice. But where there is a degree of freedom I would love to weight in as an individual and as a participant of the wider community.

I also messaged to you @seanmonstar over discord about this, but I can understand that you are a busy person with probably way to many stuff going on at all times. I fully respect and understand that. It's another reason why I gladly help you out here as a co-maintainer. I could begin by chopping of open issues and whatever else you have in mind, and I could start making new proposals once we have a process and good communication setup.

These crates are really awesome and I would be very humbled if I can help maintain and grow it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant