Closed garyburd closed 1 year ago
HillbillyHero
commented
6 years ago 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.
nynhex
commented
6 years ago I'm also working on networking/sockets in Golang. Happy to help maintain/contribute ⚡️
binary132
commented
6 years ago 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.
elithrar
commented
6 years ago 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.
glerchundi
commented
6 years ago @garyburd have you considered the idea of merging into the official exp. stdlib? Thus probably replacing the current websocket implementation?
glerchundi
commented
6 years ago Nevermjnd, i didnt read the previous comments. Still @garyburd opinion on this regard will be much appreciated!
garyburd
commented
6 years ago @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. https://github.com/golang/go/issues/18152#issuecomment-332949233
Merging the packages does not help with this issue. There are no maintainers for the x/net/websocket package.
prologic
commented
6 years ago 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.
HillbillyHero
commented
6 years ago @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
garyburd
commented
6 years ago 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.
prologic
commented
6 years ago This all works fine as long as there's enough folks that have "Contributor" access to the repo? i.e: Can approve/merge PRs etc?
Can I be added to the repo?
In lieu of an "official" maintainer; just expanding the list of who can "maintain" the repo is "good enough" IHMO.
James Mills / prologic
E: prologic@shortcircuit.net.au W: prologic.shortcircuit.net.au
On Tue, May 1, 2018 at 9:45 AM, Gary Burd notifications@github.com wrote:
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 https://github.com/MiikeWilliams and @nynhex https://github.com/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 https://github.com/elithrar Thank you for your help with this project and your comment above.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gorilla/websocket/issues/370#issuecomment-385720231, or mute the thread https://github.com/notifications/unsubscribe-auth/ABOv-kRN5QKBJaRMcJl7bJdtfLVieCrlks5tuJE4gaJpZM4TC8KQ .
elithrar
commented
6 years ago @garyburd, @kisielk and myself can merge any critical bugs/patches (as Gary addressed, above), and myself & @kisielk can triage in the meantime. We're both pretty strapped for time (+ maintain the other Gorilla repos), so it'll likely be "critical bugs" only.
I don't know where Gary stands on this, but if you start contributing fixes, documentation & triaging issues for some period to establish capability & trust, it will help us understand when to dole out write privileges to the repo.
On Tue, May 1, 2018 at 9:54 AM James Mills notifications@github.com wrote:
This all works fine as long as there's enough folks that have "Contributor" access to the repo? i.e: Can approve/merge PRs etc?
Can I be added to the repo?
In lieu of an "official" maintainer; just expanding the list of who can "maintain" the repo is "good enough" IHMO.
James Mills / prologic
E: prologic@shortcircuit.net.au W: prologic.shortcircuit.net.au
On Tue, May 1, 2018 at 9:45 AM, Gary Burd notifications@github.com wrote:
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 https://github.com/MiikeWilliams and @nynhex https://github.com/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 https://github.com/elithrar Thank you for your help with this project and your comment above.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/gorilla/websocket/issues/370#issuecomment-385720231 , or mute the thread < https://github.com/notifications/unsubscribe-auth/ABOv-kRN5QKBJaRMcJl7bJdtfLVieCrlks5tuJE4gaJpZM4TC8KQ
.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gorilla/websocket/issues/370#issuecomment-385722683, or mute the thread https://github.com/notifications/unsubscribe-auth/AABIcOzOwnYM1mqFslZVlGWOmdU7-_F-ks5tuJNNgaJpZM4TC8KQ .
prologic
commented
6 years ago Sounds reasonable
On Tue, May 1, 2018 at 10:02 Matt Silverlock notifications@github.com wrote:
@garyburd, @kisielk and myself can merge any critical bugs/patches (as Gary addressed, above), and myself & @kisielk can triage in the meantime. We're both pretty strapped for time (+ maintain the other Gorilla repos), so it'll likely be "critical bugs" only.
I don't know where Gary stands on this, but if you start contributing fixes, documentation & triaging issues for some period to establish capability & trust, it will help us understand when to dole out write privileges to the repo.
On Tue, May 1, 2018 at 9:54 AM James Mills notifications@github.com wrote:
This all works fine as long as there's enough folks that have "Contributor" access to the repo? i.e: Can approve/merge PRs etc?
Can I be added to the repo?
In lieu of an "official" maintainer; just expanding the list of who can "maintain" the repo is "good enough" IHMO.
James Mills / prologic
E: prologic@shortcircuit.net.au W: prologic.shortcircuit.net.au
On Tue, May 1, 2018 at 9:45 AM, Gary Burd notifications@github.com wrote:
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 https://github.com/MiikeWilliams and @nynhex https://github.com/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 https://github.com/elithrar Thank you for your help with this project and your comment above.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub < https://github.com/gorilla/websocket/issues/370#issuecomment-385720231 , or mute the thread <
.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <https://github.com/gorilla/websocket/issues/370#issuecomment-385722683 , or mute the thread < https://github.com/notifications/unsubscribe-auth/AABIcOzOwnYM1mqFslZVlGWOmdU7-_F-ks5tuJNNgaJpZM4TC8KQ
.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gorilla/websocket/issues/370#issuecomment-385724831, or mute the thread https://github.com/notifications/unsubscribe-auth/ABOv-kFg85-WN3J-sixaRdZB1Vehif5Kks5tuJUWgaJpZM4TC8KQ .
--
James Mills / prologic
E: prologic@shortcircuit.net.au W: prologic.shortcircuit.net.au
prologic
commented
6 years ago So far so good (y) prologic/msgbus@4b954ba
niaow
commented
6 years ago 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.
theckman
commented
6 years ago @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.
garyburd
commented
6 years ago @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.
theckman
commented
6 years ago @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.
eranyanay
commented
5 years ago Where does this library stands at the moment? If additional functionality (not necessarily critical bug fix of some sort) is added, will it get reviewed and merged?
@garyburd @elithrar @kisielk
elithrar
commented
5 years ago Additional functionality will be considered, but as per history:
• create an issue explaining who the feature is for • provide an example of the API you wish to change or introduce • be OK with alternate suggestions - such as writing an example using existing APIs - is a polite “no” - every new feature is both a new thing for a user to learn & maintenance burden on a very stretched group of maintainers 😉
Hope this helps clarify.
On Sun, Mar 24, 2019 at 7:48 AM Eran Yanay notifications@github.com wrote:
Where does this library stands at the moment? If additional functionality (not necessarily critical bug fix of some sort) is added, will it get reviewed and merged?
@garyburd https://github.com/garyburd @elithrar https://github.com/elithrar @kisielk https://github.com/kisielk
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gorilla/websocket/issues/370#issuecomment-475966209, or mute the thread https://github.com/notifications/unsubscribe-auth/AABIcAJ1DJ3OS6MKSMSUX24vIz6kAmdtks5vZ5A0gaJpZM4TC8KQ .
IngCr3at1on
commented
5 years ago 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.
elithrar
commented
5 years ago 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.
IngCr3at1on
commented
5 years ago @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 :joy:
elithrar
commented
5 years ago @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)
IngCr3at1on
commented
5 years ago @elithrar ah good point, I'd be happy to assist with triaging, gives me a reason to remember to open github.
nhooyr
commented
5 years ago 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.
FZambia
commented
5 years ago @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
commented
5 years ago @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 https://github.com/gorilla/websocket/pull/543#issuecomment-536234499
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.
elithrar
commented
5 years ago 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.
Right now, I’ll continue to maintain this whilst we look for a longer-term, dedicated maintainer.
On Sat, Sep 28, 2019 at 5:07 PM Anmol Sethi notifications@github.com wrote:
@nhooyr https://github.com/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) https://github.com/gorilla/websocket/pull/543#issuecomment-536234499
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. 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 most 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.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gorilla/websocket/issues/370?email_source=notifications&email_token=AAAEQ4AZJYFPHLQ55WX625LQL7WSTA5CNFSM4EYLYKIKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD73EV4A#issuecomment-536234736, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAEQ4DEQ5PEKV5AFGB43XLQL7WSTANCNFSM4EYLYKIA .
nhooyr
commented
5 years ago 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.
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.
elithrar
commented
5 years ago 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.
nhooyr
commented
5 years ago 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 https://github.com/gorilla/websocket/issues/87 has been open since October 2015 but from what I can tell, it's just a trivial documentation fix.
elithrar
commented
5 years ago Please refrain from side-tracking this thread.
chappjc
commented
4 years ago Since this seems to be a touchy subject, I'd like to make a couple suggestions:
This pinned issue is helpful, but I just didn't notice it when submitting a PR.
System-Glitch
commented
3 years ago Any news? Have you found someone?
elithrar
commented
3 years ago No, we have not. The folks helping triage have not been interested in taking over in full (nor do they owe us that).
PRs still get merged and this remains a mature library, so the need for large scale changes is small.
On Mon, Feb 8, 2021 at 6:02 AM SystemGlitch notifications@github.com wrote:
Any news? Have you found someone?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/gorilla/websocket/issues/370#issuecomment-775171439, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAEQ4A53BIJOEBLYRR5ARDS57VHVANCNFSM4EYLYKIA .
echlebek
commented
2 years ago @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 :v:
tomaswarynyca
commented
2 years ago Any news? :slightly_frowning_face:
ghost
commented
2 years ago Willing to help maintain this
XFrankly
commented
2 years ago 任何新闻？🙁
its a maintenance-only repo, no new development targets, i understand.
mrrobotisreal
commented
2 years ago Hello, I am also willing to help maintain this.
grokify
commented
1 year ago @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":
https://github.com/gorilla/mux/issues/659
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.
elithrar
commented
1 year ago The Gorilla project has been archived, and is no longer under active maintainenance. You can read more here: https://github.com/gorilla#gorilla-toolkit
zrml
commented
1 year ago @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.
bilinxing
commented
1 year ago Has the Gorilla project found a new maintainer? 🎉This is exciting news, is there an announcement anywhere about the future direction of the project?
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.