Contributing to Apache CloudStack as a Non-Committer
The Cloud Zone is brought to you in partnership with Iron.io. Discover how Microservices have transformed the way developers are building and deploying applications in the era of modern cloud infrastructure.
The content of this article was originally written by Joe Brockmeier and published on the Cloudstack blog.
If you’re a contributor to an Apache project, it means that you can commit directly to the project’s repository. For instance, with Apache CloudStack (incubating) contributors are allowed to directly push commits into the git repository.
Non-committers, however, have to submit patches for review. Don’t worry, it’s not an onerous process at all. The first time you submit a patch, it will take a minute or two to create an account on Review Board, but it’s a piece of cake from start to finish.
For the purpose of this post, we’ll assume that you already have a system with Git and have found a bug to fix or have a feature that you’d like to submit, and you’re willing to contribute that code or documentation under the Apache License 2.0.
Further, if you’re fixing a bug we’ll assume that you’ve either filed a bug report or are submitting a fix for a known bug. If you find a bug and would like to fix it, that’s awesome! Please be sure to file the bug too, though.
If you want to add a feature, you should bring it up for discussion on the cloudstack-dev mailing list before implementing it. This ensures that it meshes with the plans that other contributors have for Apache CloudStack, and that you’re not doing redundant work. Other developers may also have ideas for the feature or suggestions that will help you land the feature without having to re-do the work.
In short, communication is a vital part of making a contribution to an Apache project.
First, lets make sure that you’ve added your name and email to your ~/.gitconfig
git config --global user.name "Your Name" git config --global user.email firstname.lastname@example.org
You’ll grab the CloudStack source with git:
$ git clone https://git-wip-us.apache.org/repos/asf/incubator-cloudstack.git
f you already have the source, make sure you’re working with the most recent version. Do a git pull if you cloned the source more than a few hours ago. (Apache CloudStack development can move pretty fast!)
Now that you have an up-to-date copy of the source, create a branch to do your work in:
$ git checkout -b mybranch
This does two things: One, it creates the branch mybranch and two, it changes your working branch to mybranch. Running git branch will show you which branch you’re working on, with an asterisk next to the active branch, like so:
[user@localhost incubator-cloudstack]$ git branch master * mybranch
Make whatever changes you’re going to make, be sure to use git add to stage the changes, and then you’re going to commit the changes to your working branch:
git commit -m "Insert a meaningful summary of changes here."
Finally, you’re going to create a patch to upload to Review Board:
git format-patch master --stdout > ~/patch-name.patch
Using Review Board
Review Board is the approved method of sending patches to the Apache CloudStack project. That’s not to say that a patch sent directly to the mailing list will be ignored, but the strong preference is that patches be submitted through Review Board. Don’t worry, it’s a very easy tool to use.
If you haven’t already, create an account with Review Board. Registering only requires an email address, first name, and last name. After you’re registered, head to New Review Request and select the repository (cloudstack-git) and upload the patch (diff) created with git.
Click Create Review Request and then fill out the information required.
- Groups (choose cloudstack)
- People (only use if you need specific committers to review changes)
- Testing Done
The Summary will be the subject that’s sent to the cloudstack-dev mailing list. So if your summary is “fixed feature foo” the subject of the mail sent to the list will be “Review Request: fixed feature foo”. Try to be descriptive with the Summary. If you’re submitting a patch for a bug, please be sure to include the bug number in the summary. (Like “Bugfix CS-15942: Fixing problem with redundant routers.”)
The description should be a full description of what you’ve done. Please be specific, and include enough information that any reviewer will be able to look at your patch without asking for follow-up information.
If you’re submitting a patch that modifies code, adds features, etc. you should test before submitting. Please be sure to describe your tests here.
Once you’re sure everything is OK, go ahead and submit the patch. But that’s not the end of the process. The work isn’t done until the patch is committed!
Once you’ve submitted your patch, you should receive a response within a few days. If you receive no response within a week, please ping the cloudstack-dev mailing list. One of the features of Review Board is that it shows all of the requests and when they were posted, and the committers know that they should be responsible for reviewing patches in a timely fashion.
When your patch is reviewed, it may be accepted as-is or you may be asked to make changes. If you’re asked to make changes, please work with the committer to see the patch through to acceptance.
If the patch is accepted and committed, you have one last task (don’t worry, it’s minor and kind of satisfying).
Go back to Review Board, click My Dashboard and then Outgoing Reviews. Go to your submission, you should see a “Ship it!” message from the reviewer. Click the Close button and choose Submitted. The status has now changed from pending to submitted.
That’s it – you’ve helped make Apache CloudStack a better project. Thanks!
You might want to peruse the Get Involved page on Apache.org, and the On Contributing Patches doc as well. Note that some of that does not apply to Apache CloudStack, as we’re using git rather than Subversion. But do respect the original style of the CloudStack code, and ensure that you’re using spaces rather than tabs, and your patches have Unix line endings (LF) rather than Windows-type line endings (CRLF).
This article originally posted at Dissociated Press