Opening up to Open Source - Part 214 May 2016
I highly recommend that you read part 1 of this series if you haven’t yet.
Writing Your First Real Patch
So let’s get started with how to write a simple patch for your organization. Although keep in mind I’ll be writing this patch for CiviCRM and the exact procedure that your organization recommends might differ slightly.
Finding a Worthy Issue
One way to go about finding a bug to fix is to prowl their bug trackers, search for issues tagged as
trivial and comment that you want that issue to be assigned to you. However, most issues tagged
trivial are only trivial for developers that have considerable experience working with that code-base.
Instead I’d recommend that you ask your mentor to assign you an issue and provide you with a brief summary of how to go about fixing it.
Okay, I’ll assume you’ve found a nice issue for yourself. I myself found a rather simple one for this tutorial:
As you can see (or maybe not, but you’ll learn to see) the issue requires us to make a change in a certain table. CiviCRM uses upgrade scripts for this purpose. I Googled “upgrade scripts civicrm” and got this result. Have a look through that page if you wish to, or you can blindly trust my word that it contains everything we need to solve our issue.
Working With Version Control
I’m assuming that you have some basic knowledge of working with version control. If not, this tutorial hosted by Git should have you up and running Git within half an hour or so of reading.
Let’s make a new branch where we’ll solve the issue. I’ll just name the branch CRM-18537 to represent the issue id.
Change the Required Code
This is the part where I’ll mostly fast forward and just show you the required changes.
We’ll just add this simple SQL query to delete the corresponding field.
And delete the corresponding values in these two files. (How did I know what to do?)
Committing Your Changes
Great! You’ve successfully made your first change to the code-base. How to go about converting this into a patch?
Let’s start by committing your changes and pushing them to your forked repository.
Enter your GitHub username and password and head on over to GitHub.
On your GitHub dashboard, you’ll find a notification telling you that you pushed some code to a new branch
CRM-18537. Click on the green create a pull request button, add a brief description, review your changes one last time (not really the last time) and finish up.
Congratulations! You have your first PR ready to be merged (or closed)!
How to make changes to your PRs, what is testing, rebasing and the wonderful utility called grep. Continued in part 3.