⚠️ New maintainers needed
garyburd opened this issue · comments
I am stepping down as the maintainer of the gorilla/WebSocket project.
I am looking for a new maintainer for the project. The new maintainer should have a track record of successfully maintaining an open-source project and implementing RFCs.
Potential maintainers can gain the required experience by contributing to this project. I need help triaging issues, reviewing PRs, and fixing issues labeled "help wanted." If you are interested, jump in and start contributing.
If you rely on the quality and ongoing maintenance of this package, please get involved by helping to maintain this package or finding people to help maintain the project.
Hey guys,
I am very interested in helping maintain gorilla/websocket. I currently deal with a lot of networking in Golang and believe I could be of service to the project and team.
I'm also working on networking/sockets in Golang. Happy to help maintain/contribute ⚡️
Since people are constantly hammering on x/net/websocket as "unmaintained" and "everyone uses gorilla/websocket", please consider putting in more than a month's worth of half-baked effort to make sure you have found a suitable maintainer for this, since many production systems rely on its quality.
There’s no need for combative language here @binary132. This is an OSS project, primarily maintained by an individual.
If (commercial) production systems rely on this package, having those engineers dedicate time to contributing back or helping with triage would be a far more reasonable request vs. suggesting Gary put in more than a “half baked” effort here.
Finding maintainers & contributors is really hard. Most requests fall on deaf ears. I don’t blame Gary for putting a clear timeline around this.
@garyburd have you considered the idea of merging into the official exp. stdlib? Thus probably replacing the current websocket implementation?
Nevermjnd, i didnt read the previous comments. Still @garyburd opinion on this regard will be much appreciated!
@glerchundi I agree that the packages should be merged (by replacing the x/net/websocket package), but I do not have time to do the work and no one else has stepped up to do it.
golang/go#18152 (comment)
Merging the packages does not help with this issue. There are no maintainers for the x/net/websocket package.
What's the status of this project? I'm looking to switch to gorilla/websocket for the control message pin/pong support in my project.
@prologic I'm thinking best course of action is to just contribute. If we need to make any updates/changes fork gorilla/websocket, do whatever is needed, then make a PR. The more people we have helping out the better :D
I stepped down as regular maintainer of this project. I will fix critical bugs during the search for a new maintainer.
If you rely on the quality and ongoing maintenance of this package, then please get involved by volunteering to maintain the package or by helping to find a maintainer. If you support any of the people who volunteered to maintain the project, then comment here or send email to the address on my GitHub profile.
@MiikeWilliams and @nynhex: Thank you for volunteering to help maintain the project. As noted in the issue, I want to see some consensus on the new maintainer. That has not happened yet.
@elithrar Thank you for your help with this project and your comment above.
So far so good (y) prologic/msgbus@4b954ba
The Gofrs organization would like to help maintain this project. We have filed a help request issue to discuss ways to possibly maintain this. You can also contact us on the Gophers Slack in the #gofrs channel.
@garyburd @elithrar @kisielk I think we in the Gofrs would like to help look after gorilla/websocket. Right now our GitHub org is at about 20 people, and I assume most of them likely won't contribute to every project we work on. So I'm only expecting a handful to want to contribute to gorilla/websocket, but it could be more.
How would y'all like to start down the path of having us look after this repo? My initial thought was to become an administrator on the organization, and to then manage an org team for The Gofrs based on who wants to contribute to the repo. This would allow us to manage membership without needing to take more of your time away from the other projects.
@theckman I am looking for one or more people with a track record implementing RFCs and maintaining a non-trivial open source project. Gofrs team members are welcome to gain this experience by contributing to this project. We need help triaging bugs and reviewing PRs. The current maintainers will handle admin only tasks for those helping out.
The Gorilla maintainers want the package to remain at github.com/gorilla/websocket. Users of the package should not need to update their code to get the maintained version of the package.
@garyburd that sounds like a great fit. I've experience not only implementing RFC-compliant software, but having to troubleshoot software that was not fully compliant and causing sporadic issues. It helps you appreciate the importance of maintaining an open source project with RFC compliance and stability being the top priorities. I know that similar experience exists within the rest of the Gofrs organization as well.
Building trust through triaging of issues, and raising of PRs, makes sense. I'll happily start putting more of my time in to looking at things at this repository, including refreshing myself on the codebase. I know that @itsjamie, and maybe @jadr2ddude, from Gofrs are explicitly interested in helping as well.
Building trust through triaging of issues, and raising of PRs, makes sense. I'll happily start putting more of my time in to looking at things at this repository, including refreshing myself on the codebase. I know that @itsjamie, and maybe @jadr2ddude, from Gofrs are explicitly interested in helping as well.
Just a quick drive-by to say hello on this issue; we were discussing the status of this project in the Gofrs' slack and I wanted to add myself to the above list.
Posted again on https://groups.google.com/forum/#!topic/golang-nuts/9D2JuYsq5Lo
@IngCr3at1on - if you're still interested, let me know. We'd specifically be looking for folks to start triaging, reviewing & writing PRs, and I can provide some limited rights to help, before we consider a "commit bit" given the risk to the project & its users.
@elithrar I mean I'm happy to continue to review issues and pull requests; as you know I've been doing this anyway I can't say how much time I'll have to write anything though. I added the above note as a member of Gofrs because if anything I'd prefer a collective of maintainers anyway 😂
@IngCr3at1on - that works for me. Let’s keep this as-is going forward.
(I also asked as we’re not triaging everything just yet, and wanted to confirm the engagement level)
@elithrar ah good point, I'd be happy to assist with triaging, gives me a reason to remember to open github.
I wrote and maintain https://github.com/nhooyr/websocket
I'd be happy to maintain this package as well, of course respecting the backwards compatibility. I have a significant amount of experience with WebSockets, writing idiomatic Go libraries and contributing to open source.
I would mostly only merge in bug fixes as this package already has a very large API surface for what it does and defer users to my library where possible as it's simpler to add features for given the minimal API and approach.
I've already added a comparison table at #543 making it clear gorilla/websocket is the battle tested mature library whereas mine is newer, less used but attempts to provide a better API.
@nhooyr hello, you are doing a great work with your library, keep it up! But I believe that at moment there are no real concerns for most of Websocket users to move from Gorilla Websocket to your library. This package solves most needs that Websocket applications require, has stable API and receives security fixes. It's not broken, it's well designed and performs well enough. I'd really want the development of this package to continue. Personally I like API of this package too - with ping/pong callbacks, explicit write and read deadlines etc. Having a good alternative is always great though and I hope that your package will continue to be developed. But again - this package is still wealthy and actual.
@nhooyr hello, you are doing a great work with your library, keep it up!
I appreciate that.
But I believe that at moment there are no real concerns for most of Websocket users to move from Gorilla Websocket to your library.
I disagree. See my response at #543 (comment)
To clarify, I don't consider gorilla/websocket broken or not valuable. I've made it clear in my comparison that gorilla/websocket is the mature and battle tested option and if that's what a user wants, then that's what they should use.
This package solves most needs that Websocket applications require, has stable API and receives security fixes. It's not broken, it's well designed and performs well enough. I'd really want the development of this package to continue.
I apologize, I didn't mean to suggest I wouldn't add any features to this package. I absolutely would, but I wouldn't want to duplicate features. E.g. if user's want WASM support, they ought to use my library instead as it's already been implemented there and was much simpler to implement than it would have been here (see #432). Otherwise I'm going to just end up duplicating effort in this library and mine.
Of course if there is significant demand for a feature in this library, I would implement it.
Personally I like API of this package too - with ping/pong callbacks, explicit write and read deadlines etc
It's not the worst API but I think many users would benefit from the API in nhooyr.io/websocket. Like I mentioned, gorilla/websocket is the best option for users who want a mature and stable library but for the features my library has and gorilla/websocket doesn't, I think it's better to defer users to my library instead of duplicating effort.
The same could be said the other way. Further, “duplicate effort” isn’t
always bad - competing implementations improve each other, and APIs can’t
fit all use-cases or users.
I am more than happy for you to point out cases where users would have an
easier time with your library - those cases will always exist. Same as
React vs Vue, mux vs chi, etc.
I agree that is true in general, but I don't think it is in this case. The big benefits gorilla/websocket has are the obvious maturity, support for prepared messages, low level control, compression and configurable buffer sizes, for which I would continue to recommend gorilla/websocket.
However, excluding maturity, most people do not need these features.
- Prepared messages
- I have not added this yet as no one has ran into performance issues nor have I seen any benchmarks that this feature would improve performance significantly.
- Configurable buffer sizes
- Server side is blocked on golang/go#13870
- I'll add client side support if benchmarks make it clear there is a significant performance difference. Most WebSocket messages are very small so I don't expect there to be a big performance improvement. If there is demand for it, this is trivial to add.
- Low level control
- My goal was to provide an API expressive enough to not require low level protocol control.
- For extremely unusual cases, I would still recommend gorilla/websocket or gobwas/ws
- Compression
- See nhooyr/websocket#5 (comment) or #203
Thus, I don't see how gorilla/websocket could improve upon the nhooyr.io/websocket API/feature set and distinguish itself.
I feel it'd be unfortunate to reimplement the features nhooyr.io/websocket already has when I've already put so much time, effort and thought into it and also considering that no one has stepped up to implement these features in gorilla/websocket for well over a year now.
That could be said for any library that addresses a standard: again, there is benefit in more than one implementation.
Anyway - this is off-topic for this thread - the hunt for a new maintainer continues.
That could be said for any library that addresses a standard: again, there is benefit in more than one implementation.
There may be, but it's clear no one wants to maintain a second implementation.
For example #87 has been open since October 2015 but from what I can tell, it's just a trivial documentation fix.
Please refrain from side-tracking this thread.
Since this seems to be a touchy subject, I'd like to make a couple suggestions:
- Edit the repo description to mention that maintainers are needed.
- Edit the README to the same effect.
- Create or modify the issue and pull request templates to mention that maintainers are needed and changes may take extra time (or something to that effect).
This pinned issue is helpful, but I just didn't notice it when submitting a PR.
Any news? Have you found someone?
@garyburd while I don't necessarily want to throw my hat in the ring for the role of maintainer of this project, we rely on it for both open source and commercial projects in the organization I work for. (https://github.com/sensu/sensu-go) As such I have a vested interest in seeing the project live on, and so does the company I work for.
I'd be interested in assisting with critical bug fixes, security issues, reviewing pull requests, and possibly funding (I have no direct control over funding, but could advocate for it if it would help the project stay alive).
I'm not interested in implementing new features, as I feel the feature set of websockets is good enough. I'm also not interested in triaging issues or trimming the issue backlog (and that's why I don't want to step up to be a maintainer, if that's an expected maintainer function). I also feel like the websocket library is in a pretty good place as things stand, so I wouldn't be surprised if my help isn't needed.
But if something needs doing to keep the lights on, you have my support. Feel free to reach out, or have Kamil feed me some tasks (I work with him in maintaining another legacy project already).
Cheers ✌️
Any news? 🙁
Willing to help maintain this
任何新闻？🙁
its a maintenance-only repo, no new development targets, i understand.
Hello, I am also willing to help maintain this.
@XFrankly wrote:
its a maintenance-only repo, no new development targets, i understand.
Seems like major versions can be considered given the following the following regarding "version 2.0s":
The major libraries — mux (https://github.com/gorilla/mux), schema (https://github.com/gorilla/schema), handlers (https://github.com/gorilla/handlers), and sessions (https://github.com/gorilla/sessions) — are all reasonably mature libraries, but ongoing stewardship around bug triage, feature enhancements, and potential "version 2.0s" are all possibilities.
The Gorilla project has been archived, and is no longer under active maintainenance. You can read more here: https://github.com/gorilla#gorilla-toolkit
@elithrar thanks for the link. It looks like there are new maintainers for the Gorilla projects. I'm very happy to see this! Wishing you all capable developers a happy continuation and collaboration.
Has the Gorilla project found a new maintainer? 🎉This is exciting news, is there an announcement anywhere about the future direction of the project?