Otland forked edubart's repo because it was dead for a good while, but then activity started again. Which honestly is awesome! And since we are in the same git network, it is fairly easy to merge (and resolve git conflicts) with each other. I imagine edubart's repo will be most strict, but I'm fine with that. That only means the quality of commits there are better and easier to merge into our forks.
I thought about it, but the code is different from the official, it will generate conflicts.
I did a merge from edubart to otland, it is currently a draft PR. I linked to appveyor builds in the comments:
Keeping otland/otclient up to date by merging in changes done to edubart/otclient This is mostly just a test that I expect to fail, just curious about what Travis CI has to say.
github.com
If this gets through, it will be much easier to merge up changes in the future. (I wasn't good enough in git to do it before, which is why there are a good 100 commit difference between the repos).
Would be awesome if (somebody who actually use otclient) could test it and confirm that the merge is working properly. If this PR shows no issues, then we have successfully synced otland with edubart. After that, I might try to help out with merging and conflicts in PR's on the occasions I have time.
Although to be fair, the PR feedback you got is likely to be similar in the otland repo.
Each optimization should be in a separate branch, for a separate pull request.
Allowing us to test, review, improove and implement each optimisation properly.
Code indentation/code style changes should be merged as well, but should follow a guideline, and should be a completely isolated PR. (That changes no code, only fixes the style).
This is all to make it easier to review and test PR's. (Which is our biggest demand/issue atm). The open source OT development scene is flourishing right now, but we struggle to get enough PR reviewers and testers to keep up with the inflow.
I posted earlier in this thread about how to work with git, which can be used to help with this workflow. Git is hard, but awesome once your mind "clicks" on it.
Nice to see git done right - a proper fork!
But since your commits go straight into master, you should consider having another branch that represents upstream edubart/otclient master. Which shows where you are (in terms of being in sync with edubart) and has no changes.
So when you sync with another repo in the otclient network:
mehah/upstream -> merge edubart/master (fast forward)
mehah/master -> merge mehah/upstream (resolve potential git conflicts etc and keep your optimizations up to date with edubart)
You can also do cool stuff like
git checkout mehah/upstream (point your fork at "base")
git checkout -b single_optimization_update (take this base and make a new branch)
git cherry-pick <commit# single optimization update from mehah/master> (add selected updates to this branch)
git push mehah single_optimization_update (push this branch to github)
And send PR's by visiting edubart/otclient
Also some github tips, you can go into settings and enable issue tracker and wiki. So people can report bugs directly to your repo, write custom wiki guides etc.
Still, what a luxury problem to have. We have such amazing and active developers that we can't keep up with them.
I encourage everyone who is capable to join our efforts in reviewing and/or testing pull requests!