For fist time contributors to Open Source projects the initial set up of the development environment can be an intimidating prospect as every project works a little bit differently. Thankfully there are many guides out there to help with this process.
The first thing you should do is look up any documentation you can find on the internet from the project’s maintainers and start reading up on what is required to participate in the work. The Eclipse Foundation projects all work similarly to each other, so experience with one can easily be transferred to another. A great resource to get started is the new book Contributing to the Eclipse Project by Lars Vogel. It provides a broad introduction to working with the Git revision control system and common practices when contributing to Eclipse projects. Individual projects may differ slightly and specific details can be found on the project home pages hosted at eclipse.org.
Many Open Source communities use Git and the Gerrit code review system to allow easy access for new contributors while maintaining the integrity of the project’s code base. When you decide to contribute to a project maintained by the Eclipse Foundation, more than likely you will start off using Gerrit to submit code reviews. These code reviews allow new developers to participate without requiring commit access to the Git repository.
SWT in particular uses the Gerrit review systemfor new contributors.
The first step in contributing is to create an account at eclipse.org. This gives you the ability to file bug reports and to later submit Gerrit review requests.
The username and password used for Gerrit/Git access can be set up by visiting the Git user page that is associated with your newly created Eclipse account. These credentials are required when cloning a repository and later when submitting a Gerrit review. It is important to note that your Gerrit user is different than your eclipse.org user. Once logged in to the Gerrit page, you can then go to the settings tab and set up credentials to access the repository via either SSH, or HTTPS.
When you have an account set up, you can then begin work by cloning the git repository of interest. For SWT the instructions for doing this can be found here (note the different instructions for either cloning anonymously or with your Gerrit user. Using the latter method makes submitting future review requests much simpler).
When cloning the SWT project, you will need both the eclipse.platform.swt.git and eclipse.platform.swt.binaries.git repositories. In both of them, you will select the “master” branch to clone. Later when you import the projects into your eclipse workspace you only need the following projects: org.eclipse.swt, org.eclipse.swt.examples (for easy testing, you can try running the example programs located in this project), and finally you will need the platform specific binaries from the .binaries repository (for my 64bit linux machine I need the org.eclipse.swt.linux.x86_64 project).
After setting up your environment, you can begin exp
loring the code and finding bugs.
When the time comes to submit something it is good practice that the commit message reference a known bug on the project’s bugzilla page. If there is not already a related bug report, feel free to open a new one. Then when you submit the Gerrit review, the commit message should be formatted as:
“Bug ID – bug summary”
That way it is much easier for other developers to quickly understand what it is that you are working on.
If the code is unfinished work and you are looking for feedback, then the first line of the commit message should include “[WIP]” before the bug summary to indicate this.