How to Submit Patches to the Open Source Community

There are likely millions of open source projects to choose from, but the process of submitting patches is fairly similar across the projects. We'll look at two in this article:

• openSUSE
• Android

OpenSUSE

License : LGPL-2.1
OpenSUSE is a linux based operating system. It’s main focuses are:

1. Providing developers with reusable open source components and tools
2. Being a feature-rich server
3. Having a well designed user interface

Let’s examine how to submit a patch for a bug you or someone else has found.

How to work with openSUSE’s existing Code Base

They accept code patches by following these steps:

1. Pull the current code from OpenSUSE
2. Work on the branch locally
3. Build it locally
4. Commit the changes
5. Make sure it builds again
6. Check to see if the differences between your branch and the original were what you intended and talk to other developers working on the code for advice
7. Debug your code using three files left over by your osc build: .build.log, .build.command, .build.packages
8. Submit changes to be merged

Please note: As you look at the code examples below, please ignore the word "Javascript". All of the commands in this article are UNIX command line commands :)

Getting OSC

Most of these steps involve using a command osc. OSC is openSUSE’s Version Control System (like git).

To install the command, use



It will ask for a username and password, create those and then you’re all set to start using osc. So you can use commands like

Add, commit, branch, checkout just like you would with Git!

For the exact osc commands and command flow:

Build Service Collaboration

How are Patches Submitted

Bugzilla: Mozilla’s bug tracker where the OpenSUSE community reports bugs. Each bug follows a lifecycle:

• Bug is reported and given an id
• The bug is given a status: (This step happens throughout the lifecycle)
  • Open Bugs:
    • Unconfirmed
    • New
    • Assigned
    • Reopened
  • Closed Bugs:
    • Verified
    • Resolved
• A Patch is submitted for the bug
• The Patch code has been reviewed and tested by authorized developers

Two Example Bugs and Patches

The two bugs evaluated had the following similarities in the way they accepted the code patches. Both:

• Had a 3 week resolution time
• 2-3 Reviewers and Developers, and or Committers involved

However, their differences lie in the amount of commenting and discussion involved.

• Commenters on the Double.MaxValue Bug simply stated the issue, submitted the code for the patch, and the patch was accepted. On the Konqueror Bug, they were much more active. Commenters:
• Stated output given a particular test input value
• Suggested a valgrind be done (a debugging and profiling tool)
• Determined that the bug doesn’t have to do with openSUSE but K Desktop Environment itself, bug was then pushed there
• On the KDE’s bug reporting system - bugs.kde.org - a resolving comment says, “null pointer check fixes gmail crash”

Android

License : Apache Software License, Version 2.0

How to work with Android’s existing Code Base

Instead of using OSC, Android uses:

1. Git, another popular version control system.
2. Repo, a tool that sits between you and Git, automating commands more specifically tailored to the needs of Android Open Source.

Process

1. Use Git:
   • When possible, make your components replaceable and usable in applications other than Android
2. Use Repo:
   • A repository management tool that we built on top of Git
   • It uploads automatically to Git
   • Some Git and Repo commands you can use:
     • >> repo start to start a new branch
     • >> repo status . to verify your branch was created by getting the status
     • >> repo sync
       • If it’s the first time: does a git clone (sync files with all existing projects inside Android)
       • If sync has been done before: Does
         • git remote update
         • Does git rebase origin/[BRANCH]
     • >> repo diff Does a git diff (Shows difference in code between the commit and working tree)
     • >> git add
     • >> git commit
     • >> repo upload Do this instead of Git push, Repo will update Git for you
3. Use Gerrit:
   • Is an Online code reviewing system
   • Works with Git
   • Allows inline commenting
   • Allows user to submit code once they're authorized
   • Code that passes the review will be auto merged
4. Android Studio:
Android IDE

Roles in the Android Community

Contributor

Those who contribute to the Android Open source code, whether a Google employee or an developer outside of Google. Both follow the same submission process.

Developer

Engineers who:

• develop the Android application and
• use the platform (like customers do, and unlike contributors)

Verifier

Those who:

• test change requests
• Are appointed by Project Leads once they’ve submitted enough high quality code

Approver

Those who:

• Accept code into the project
• Are appointed by Project Leads

Project Leads

Android is made up of a bunch of sub-project. Each sub-project has a Project Lead who:

• Leads the project roadmap, versioning & release cycles, and ensuring QA is done in time
• Is the public face for the sub-project

An Example Bug and Patch

Let’s examine the following bug: Bluetooth: configure VTS to run HAL gtest.

In comparison to the OpenSUSE bugs, this bug:

• Had 6 commenters, reviewers and developers (1 / 6 was a bot - a reviewer)
• The whole review took only 1 week
• There were a lot of suggestions given for improvement and results of testing. As for the general flow of the conversation, users were:
  1. Asking if the project has the needed tools included for the auto-tests.
  2. Asking for mostly 1 line code changes
  3. Labelling each set of changes as a new patch set
  4. Reading results of the tests that the treehugger bot ran
  5. Leaving friendly pings for reviewers to come in and continue the process
  6. Reviewing the code 2 more times
  The code was resolved once the treehugger bot merged the code into the existing code base.

Overall, the Process of Submitting a patch to the open source community follows a similar work flow, and uses similar commands across the different systems. However, each community has their own yummy flavours of the tools they use.

References

1. Patches Submitted - Android
2. All Resolved OpenSUSE bugs
3. Bug - Inserting Double.MaxValue
4. Bug - Konqueror crashes
5. Bug - Bluetooth: configure VTS
6. Developing at Android