Code Contribution – x64dbg

To contrast with Firefox, the second open source project I’ll look at will be x64dbg. x64dbg is an x86 debugger geared towards reverse engineering. I chose this because it’s a much smaller project where a lot of the work is done by the main developer (and because it’s a program that I personally find useful). As you might expect, the code submission process is a lot more informal. They do have a “Sending a pull request” section on the wiki, but it’s a list of git commands to run for those unfamiliar with creating pull requests on github. With that said, there is this section https://github.com/x64dbg/x64dbg/wiki/Coding-Guidelines, a fairly in depth list of coding style guidelines for those contributing to the project. It’s always a good idea to have something like this around, as it not only ensures that things within the project stay consistent, but it can save time both people submitting pull requests and people approving them.

As the process here is more informal, I had a look through closed pull requests to get a better feel for the process. It’s about what you’d expect from this scale of project – someone makes a pull request on the github, and then the main developer reviews it. In many cases the main developer accepts pull requests outright, but in some cases there’s some back and forth between a patch goes in, or another one of the developers weighs in on the pull request. Finally, the amount of time it takes for pull requests to get accepted here varies from ‘the same day’ to ‘more than a week’, which is understandable given that everything goes through a single person (and single people can get busy, etc).

For an example of a successful pull request, I chose https://github.com/x64dbg/x64dbg/pull/2171. There’s some back and forth before the pull request got accepted (which took about a week). In the end, this is probably the simplest review process – the main developer looks over things, and approves them or suggests changes. Since the volume of pull requests isn’t very high, I don’t think there’s anything wrong with this. When you get three or four pull requests at maximum per month, there’s no need to have a formal procedure for handling them. One final note is that there is an automated tool involved in the commit process, which formats code to the developer’s specifications – a neat way to keep the project’s code looking nice and consistent.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create your website with WordPress.com
Get started
%d bloggers like this: