IPv6 support

[JanWerder]

There are currently 3 pull request concerning IPv6:

• ipv6 support #73
• Yet another Ipv6 patch #51
• IPv6 support #21

@lsalzman , can we get any info on what's the current status is? Will any of these ever get merged? What are your plans about IPv6 support?

[lsalzman]

Well, thus far, people are just dropping big pull requests on me for this without even consulting me first about it, or even, more democratically, asking what the community needs in the end via the mailing list.Github really is not the right place to resolve this.

[wpbirney]

What's the current status on ipv6 in enet?

[nxrighthere]

You are welcome https://github.com/zpl-c/enet

[ClosetGeek-Git]

What is the status on this issue? IPv4 will some day become obsolete. I've been watching ENet for around a decade now and I've seen that you choose the route of code maturity over keeping up with trends as they've popped up but IPv6 is more than just a craze. Unless you've finally put the last nail in ENet's coffin I would think this your next step.

[mman]

I maintain a fork based on one of the pull requests (sorry do not remember which one it was but I did review the code line by line). Available here: https://github.com/mman/enet.

It is used in production for more than four years and I pull in commits from @lsalzman periodically to stay in sync with upstream.

I believe it is still fully compatible with the on-the-wire format of upstream enet.

The only change is in the API where:

• you work with IPv6 address everywhere
• you can pass in regular IPv4 addresses mapped in IPv6 format
• you can specify scope id for correct support of link local addresses.

I also try to never reorganize the source code or change the build process in any way.

Thanks @lsalzman for all your hard work, I really admire the work you have done, I did read the mailing list from your post 1 until today. I understand all your concerns, but I believe time is right to address the IPv6 officially 👍

[Ismoh]

@lsalzman wouldnt it be a good idea to assign a collaborator, who's maintaining github topics, as it seems you are too busy for it?

[lsalzman]

@lsalzman wouldnt it be a good idea to assign a collaborator, who's maintaining github topics, as it seems you are too busy for it?

My problem is I largely dislike github as a means of important collaboration. It encourages too much of a go-it-alone style of bombarding projects with massive PRs without a lot of actual communication during the development process. If people would actually just hang out in the IRC channel and converse with me there before just dumping PRs on me, more would probably get done.

[Ismoh]

Thanks for your reply!

As I am one not using IRC, it might be an idea to add some actions to keep your GitHub repo clean.
This are my thoughts:

1. Add a huge hint on README.md that you only will have a look on PRs, when the PR creator had a talk with you on your IRC (IRC url added)
2. Talk about stuff and when it's clear there will be a PR:
3. generate a token or buzzword or id on your server mapped to the githubs username, who will create a PR
4. PR creator has to add this generated token/buzzword or id in PRs first comment.
5. Add token/buzzword or id on your server with gh api as a secret which expires
6. Check usersname and token/buzzword or id with secret (so that no one can find the token/buzzword or id on GitHub action workflows logs)
7. When there is any PR which does match to your mapping
8. add a comment to communicate with you on IRC (+url) and close the PR

Yes, looks like time and effort, but only once and then all the deprecated and annoying PRs are gone and in future only "good" PRs will be created.

Thanks for your time and reading this!
Thanks for your awesome network library <3

[Leseratte10]

I don't think these extreme steps would be necessary. However maybe it'd be useful to create a CONTRIBUTING.md file in the root of the repo explaining how you'd like to handle PRs to this project. And, ideally, two template files for issue reports and PRs, then everyone opening a PR will see a note with a message about how you'd like to handle PRs.

If I find a useful project on GitHub in general, unrelated to enet, and I want to add a bugfix that fixes missing IPv6 support, the most likely step I'd take (had I not seen the three open issues and PRs regarding IPv6) would be to make a PR with the approach I think is the most sensible, and then react to any comments by a maintainer if there's suggestions on how to do better. I'm not saying that a using an IRC or a mailing list instead of a discussion on Github is wrong, but it should at least be clearly outlined. That would reduce the amount of time wasted by would-be contributors writing code and making PRs that won't get merged, and it would (hopefully) reduce the amount of time you need to waste telling people to use the mailing list.

Looking at the repo, the only note that PRs should be discussed somewhere else first is hidden in docs/mainpage.dox, which is not where I'd look for something like that.

That said - there's been four different IPv6 pull requests (#21 #51 #73 #109), from 2013,2015,2017,2019. IPv6 support is clearly something people would like to have. On the last PR (#109) you said this PR was well done and you'll take a look when you have time - that's now almost four years ago. Is there any kind of update or estimate when IPv6 support might be added to enet?

Sure, I could just use one of the existing forks with IPv6, but I'd rather use the "original" upstream versions if possible..

[lsalzman]

What it comes down to is PRs encouraging mercenary/sniping behavior. I am not looking for people to go it alone and drop code bombs on me.

I need people to communicate with me up front well in advance of making big code changes so that we can coordinate as to my wishes and expectations.

Thus far, this has not happened and people continue to try substantial PRs without asking me first. Unfortunately, this is a giant problem with GitHub as a whole.

[Leseratte10]

I understand your point - but wouldn't it be better to communicate that to people for example by mentioning it in a CONTRIBUTING.md instead of hoping people will magically start using the mailing list or IRC?

Also, is this related to PRs in general or also to the most recent IPv6 PR? Since your last comment on that PR was that it looks well done and you'll look into it; I'd assume that the author either talked to you or made an otherwise acceptable PR that can be brought up into a state where it could be merged?

Or is there something you would like to have changed as for IPv6 support? There's now four IPv6 PRs, and for three of them you basically said "That's not how I would want it".

Assuming I would want to have IPv6 support in enet and I don't just want to start a fifth PR, what would the best course of action be? If you said PR #109 looks well enough and you just didn't have time to review it - fair enough, maybe it'll happen in the future, no need for me (or other developers) to do stuff.

Or is there stuff in this PR that you also don't like / would like to see implemented differently? If I, as a developer, find a PR for a feature I'd like (in this case IPv6), where the maintainer commented "This is looking good, I'll review it when I have time", that doesn't really signal to me that I should hop onto IRC to ask about IPv6 support...

The issue with IRC and mailing lists is that it's very hard for other people to read these. For example, unless I was following IRC at that time, there's no way for me to read any past conversions that happened on IRC about how you'd like IPv6 support to be implemented. The mailing list archive also has no search functionality so I'd need to read through 17 years of emails to figure out if there have been previous discussions about IPv6. Each discussion you make with potential contributors about IPv6 support on IRC you're going to have to repeat for every new contributor - or am I missing something?

If there were comments on the existing PRs like "I don't like X because ABC, I would do Z because DEF", then the code could be improved, either by the creator or by someone else with a new PR.

Please don't get me wrong, I'm not trying to tell you how to run your project (and I'd assume most others aren't, either). After all, it's your project. I'm just trying to understand your wishes, and figure out how to proceed in a useful way to get IPv6 support into enet eventually.

[bjorn]

@Leseratte10 While I'm sure it's convenient for you to comment here, I think Lee has made it quite clear that he'd prefer to discuss things through the mailing list (or on IRC). The mailing list does have a public archive btw, which can be searched. I think no amount of politeness is going to make up for ignoring this.

Regarding whether those resources are easy to find. Maybe not in the places most GitHub projects put them (because those conventions are put in place by GitHub), but the website clearly lists IRC and mailing list as the only options of communication.

[JanWerder]

I think this issues shows more than enough alternatives and I don't think this will ever get solved here, so I'm closing this issue.