Clarify that ENetConnection's create_host and service must be called on client and server

[marcospb19]

Context: despite 3 years working coding servers and clients, it took me around 10 hours to connect two ENet peers, and I read docs + ENet website + searched in issues and forums (oof!).

So, in this PR I try to clarify some of things I wish were there.

(In a separate PR I plan on adding an example.)

[Mickeon]

Docs are pretty dang good now, assuming they are accurate.

Also remember to squash your commits, see the Pull Request Workflow.

[ze2j]

I may be wrong as I am not an english native speaker, but I think stablish should be changed to establish in the notes.

[Mickeon]

@ze2j is right. Just putting these as additional suggestions so that they can be picked more easily.

[marcospb19]

@Mickeon

Also remember to squash your commits, see the Pull Request Workflow.

Sure I can do it, but GitHub already enables maintainers to squash and merge, and in the process, even rewrite the commit messages if they want to.

I see some back and forth in this repo like "change commit message" or "rebase every commit", while I see the reasons behind it, is there any reason why maintainers don't prefer to click on "Squash and Merge" button? Wouldn't it save time for both the maintainers and contributors?

I also ask this because I believe that fixup commits can be useful for reviewers!

---

Anyway! I won't block the PR on this question :) , applying changes and squashing, I appreciate the review.

[marcospb19]

Another small argument: Git beginners can have a hard time with interactive rebasing, IMHO this adds an unnecessary barrier to contributing, considering there is a button that solves it (one or two more clicks).

[marcospb19]

Done, applied all changes, ty @ze2j too!!!

[AThousandShips]

GitHub already enables maintainers to squash and merge

It does (though it's not enabled on this repo), but sadly it doesn't allow squashing and creating a dedicated merge commit, which we require for any PR to make the git history cleaner and more manageable, it also helps reverting changes, and helps keeping the history clean in the rare cases where we don't enforce single commits, having merge commits also helps with cherry picking I believe

And rebasing and squashing is a core part of the workflow in any repo and any project and is a good and important skill to know, so at least I feel that it's less of a barrier and more a part of the general process of learning how to work with the tools and workflows necessary for contributing, just as much as learning how to make commits themselves or create branches! And maintainers are ready to help if new contributors are having a hard time and ask for help to figure it out, along with the detailed documentation

[mhilbrunner]

Thanks for adding these clarifications, looks good to me!

[marcospb19]

@mhilbrunner

GitHub already enables maintainers to squash and merge

It does (though it's not enabled on this repo), but sadly it doesn't allow squashing and creating a dedicated merge commit, which we require for any PR to make the git history cleaner and more manageable, it also helps reverting changes, and helps keeping the history clean in the rare cases where we don't enforce single commits, having merge commits also helps with cherry picking I believe

And rebasing and squashing is a core part of the workflow in any repo and any project and is a good and important skill to know, so at least I feel that it's less of a barrier and more a part of the general process of learning how to work with the tools and workflows necessary for contributing, just as much as learning how to make commits themselves or create branches! And maintainers are ready to help if new contributors are having a hard time and ask for help to figure it out, along with the detailed documentation

Oh, I didn't know merge commits helped with cherry-picking and reverting changes! That's great to know.

Thanks for clarifying :)

---

CI failed after I applied this suggestion, it seems unrelated tho.

[akien-mga]

Thanks!

[Jimmio92]

You don't call create_host on clients -- that's what you call to start serving a session. If the client is the server, they can't be a client to someone else, so maybe this isn't worded right?

You do need to create an ENetConnection on all sides, client and server, but you don't call create_host on clients, you call create_client.

If for some reason you needed to create a host on clients to get connections to work, that's a bug imo.

[Faless]

You do need to create an ENetConnection on all sides, client and server, but you don't call create_host on clients, you call create_client.

@Jimmio92 You are confusing ENetConnection with ENetMultiplayerPeer.
The first one, does indeed need either create_host or create_host_bound, and doesn't have a create_client method since it's almost a one-to-one mapping to official ENet API.

[Jimmio92]

Ahh, I now see I absolutely did confuse the two. Sorry about that!