Gorilla Websocket

[niaow]

• Where is the project currently hosted? https://github.com/gorilla/websocket

• Is the project written only in Go, or does it contain other languages (beyond scripts)? pure go

• Has the project had any recent activity? Last activity June 5. Project still receives bug fixes via pull request.

• Does the project have a maintainer, or a maintainer looking for someone to take
  over the project? Yes. See issue ⚠️ New maintainers needed gorilla/websocket#370

• Do you have any example projects that make use of this package? Most go projects with websockets use this package.

• Are there any outstanding critical bugs that result in the library being
  totally unusable or insecure? Unusure. Fails test suite: Autobahn tests 12.4.5 ~ 6, 12.4.8 ~ 11, 12.4.13 ~ 12.4.18 fail. gorilla/websocket#368

• Is there anything else you'd like to mention about the project?

[niaow]

On the slack chat it was brought up that maintaining a repo located in another organization would require some workaround for GitHub permissions.

[elithrar]

The Gorilla organization can create a "team" that includes gofrs members, and grant that team access to the websockets project.

[niaow]

There was also a discussion of possibly mirroring the fork back to the original repo.

[elithrar]

I think that becomes pretty complicated, and the "gorilla/websocket" name is fairly widespread. Solving group permissions is easier than forking, mirroring and dealing with end-user confusion. Vanity import paths don't fix this either, and often break.

…

On Tue, Jul 31, 2018 at 10:10 AM Jaden Weiss ***@***.***> wrote: There was also a discussion of possibly mirroring the fork back to the original repo. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABIcGtyRniSQig59wnj_C-BPiFmG6SYks5uMI-RgaJpZM4VolGH> .

[theckman]

@elithrar I assume some of us would need to become administrators of the gorilla organization if we wanted to integrate with any third party applications? These are the types of things I'm not entirely sure of how well they'd work when it comes to taking over a project.

[theckman]

If we want to take over, let's not miss this recently closed PR:

• write buffer pooling gorilla/websocket#192

[theckman]

We're now committed to becoming active in this project. For the time being that'll likely be triaging of issues and reviewing of PRs. As trust is gained with the current maintainers within gorilla it seems likely the responsibility size will grow.

We're committed to keeping the repo at gorilla/websocket. That said, in the interest of us being able to collaborate more-easily together, I'm going to fork the project to our organization to be used to issue PRs to gorilla/websocket.

[ptman]

https://github.com/gofrs/websocket - that is now done. Maybe time to close ticket?