Searching for collaboration to fork gosnmp
TimRots opened this issue · 30 comments
Would anyone be available for collaboration on a fork, to keep this awesome project alive?
Maybe
My company depends heavily on this library, we just found out it is no longer being supported. I need to discuss with my team but we may be willing to take over the project.
I'd be willing to help out.
I'd be into helping out.
We depend on this library for the Prometheus snmp_exporter. I would very much like to see this project continue. CC @brian-brazil
Does anyone know who created https://github.com/gosnmp?
First thanks to @soniah for maintaining this for all these years, as @SuperQ says the Prometheus SNMP ecosystem depends heavily on this.
I'm personally not looking to take on additional things to maintain, but am happy to send in PRs if I come across an issue or chime in if needed as I have at least some familiarity with the GET/GETBULK codepaths.
I've created a new org, https://github.com/go-snmp. I've sent some invites to join the org.
Hello everybody.
I'm also interested to help, support, testing as I did before as the snmpcollector project owner.
Thank you to @soniah for all your work and also all gosnmp contributors.
I'm interested in keeping the project going.
Thank you @soniah for the years of gosnmp work!
Does anyone know who created https://github.com/gosnmp?
Sorry for my late reply. I created it some time ago. It's available for this sole purpose if you like :)
Hmm, we've already got everyone on boarded with go-snmp. If that's OK, I think we should just keep the momentum.
No problem at all. Happy to see this happening
@SuperQ Are we planning to keep "gosnmp" as the repository name? Maybe it's just my OCD kicking in, but having the github organization with a dash and the repository without a dash seems wrong: "go-snmp/gosnmp". "gosnmp/gosnmp" looks more professional.
It appears that TimRots has deleted the gosnmp organization leaving it available if we wanted to rename go-snmp to gosnmp. That would not require redoing membership/onboarding of the existing go-snmp org. (see https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/renaming-an-organization)
It seems worth changing now since the project will be stuck with the org name in URLs and golang imports in the future.
@reimda I was actually considering go-snmp/snmp and renaming the the Go package snmp.
The gosnmp repo name has some history and I think it would be valuable to keep it. People who have come across gosnmp in the past may see the different org name and repo name and not understand that it's the same project. Keeping the gosnmp repo name shows we're related to soniah/gosnmp which is a good thing.
If we used gosnmp/gosnmp it would show people that the organization has this existing project as its main goal.
Also, people who maintain their own forks tend to reuse the project name under their own account (username/gosnmp). It's valuable to have the complete project name as the repo name. If the repo is called snmp, user forks sound too generic (username/snmp).
I don't see any value in keeping the repo name. Github will setup redirects for soniah/gosnmp, so people will know that it's the same project. All of the major projects that use this library can update their use, making it more clear that it's the same.
Also, I feel like snmp would be a better repo and package name, as Go is implied.
During this move, this is the perfect time to do this rename an simplify the naming to just snmp. We can mention the origins in the README if we like. But this repo is the most popular SNMP implementation for Go.
I was also going to suggest we break the fork connection with the original alouca/gosnmp. Further cementing this as the authoritative SNMP implementation for Go.
@SuperQ Would it be possible to discuss these ideas in the form of a poll, later, instead of making it a one-man call here?
The sole purpose for starting this thread is/was to build a community around this project;
I was afraid that one company would jump on this project, and would call the shots from thereafter.
This is actually how it feels a bit right now when you just call out "I dont see any value in y because of personal argument z" , when 5 people are disagreeing with renaming: which could be a good idea later on.
@TimRots Absolutely, I'm not going to do anything without a group consensus. I've already re-created the github.com/gosnmp org in case that's the direction we want to go. I only made go-snmp because there was no way to tell who owned gosnmp because the membership list was private.
Note, I'm not a company, and I don't represent a company here. I'm just a contributor to the snmp_exporter, which is a downstream user of this library.
My opinion is my opinion, and I'm perfectly justified in stating it. This doesn't mean I'm trying to take over. I'm just presenting my arguments.
I've updated the member list for gosnmp, and we can go with either org when we come to a naming decision.
@SuperQ Thanks for clarifying and please take my words in the kindest way possible as I'm not trying to be unfriendly or disrespectful.
Would it be an idea to create a go(-)snmp Slack channel, for people to hang out, get to know each other a bit better and discuss on how to move forward?
How about Gophers Slack? I've created #snmp
How about Gophers Slack? I've created
#snmp
That's great! Hope to see more people from this thread join in soon.
Both https://github.com/gosnmp and https://github.com/go-snmp appear to have no repositories yet... is there any reason not to populate at least one of those with the current version of https://github.com/soniah/gosnmp ?
We're waiting on @soniah to transfer the existing repo, so we get automatic redirects from the existing URLs.
do we have a slack channel? I tried the link above but it's not active.