In the open source world, different project comes with different workflow, using different medium. For instance, Linux Kernel development, use mailing list to gather patches for many developer around the world. The maintainer pick patches from developer with careful supervision. Then, they maintain release of the stable version, while Linus Torvalds himself maintain the mainline stream. Other project, Git – a revision control system. It use same model as Linux Kernel, patches and conversations go to mailing list. With additional part, for the Continuous Integration system, it is recommended to use Github and Travis CI. Although they will reject all pull request from there. Another example, Wget2 use Github mainly to perform collaboration (But currently, they start to migrate to Gitlab). Issues are discussed here. Pull request also getting merged here. Although, it also have mailing list to discuss issues and problems. Here I share my experience how I contribute to open source, so my code could be merged in the project upstream. For an example, I will write several steps of my way doing Wget2 project for my GSoC 2017 application. Below are some points I follow:
Obtain Source Code
Through Github interface, I fork (copy) the project, then I download it locally to my computer.
git clone https://github.com/dstw/wget2 git remote add upstream git://git.savannah.gnu.org/wget/wget2.git git pull --all
I create my own branch for each “task” I am working on and make my commits within it. When done, I sync with upstream, rebase/merge and make pull/merge request.
I should prevent to make changes to my branch “master”, because this should always reflect the original upstream repo. This makes it easy for me to update my “master” branch with changes from the “original/upstream” master branch.
Sync my Github repo with upstream:
git checkout master git pull --all git merge --ff-only upstream/master git push #pushing the new commits from upstream/master to your github master branch)
Sync my ‘new-feature’ branch before generating patches:
git checkout new-feature git rebase master git push -f
The last command will push updated tree to my github new-feature branch. Assume ‘new-feature’ is a private branch where I can do all the dirty things that I shouldn’t on public/shared branches. Then, as soon as my patch has been accepted, I will remove the branch ‘new-feature’ locally and from Github.
Build the Executables
As prerequisite, install all mandatory software as listed in README.
Find the Problems
I usually look at Wget2 Github pages to find issues and problems which appropriate to newcomer like me.
Make Changes to the Code
In this part, my knowledge in coding skill are truly challenged. Wget2 use C as its programming language. I just add some test based on clues from the project maintainer.
Create Pull/Merge Request
After I feel my code ready to merge, I push my commit to upstream and make a pull request from Github interface.
Wait for Review
After create a merge request, I wait for feedback, criticism, suggestions, etc. from other developer. I try to respond to it. Follow up with improved versions of my change. Even for a trivial patch I shouldn’t be surprised if it takes two or more iterations before my patch is accepted/merged. This is the best part of participating in the community; it is becomes my chance to get personalized instruction from very experienced peers.
Propose New Change
After getting a review, do some improvement. After all, make a new commit. Here, there is option to overwrite my existing commits or create new merge commits to keep history.
git push origin new-feature
If there is a conflict, Git will ask me to resolve the problem this. Then, try to push and merge commits. This won’t remove any existing commits. And if I don’t want to keep any commits history, I usually force to push:
git push -f origin new-feature
This is considered harmful. Before I do this, I will make sure that I know what I do. Also, forcing commits is should only do if it believed to final commits or at least near final, I should not do any more change to it.
Finally, after some iteration, if project maintainer agree with my changes, then they will merge it into their repository. If not, still I could learn a lot from the process.