Who is allowed to fix bugs?

Anyone who has accepted the CLA for the Gerrit Code Review project! If you feel like contributing and need a place to start you will always find bugs that need fixing, big and small, on the issue tracker. For more information on how the project uses the tracker, see the Issue Tracking documentation.

Consider bugs in “accepted” state first since these have already been through triage.

How do I go about it?

You should probably start by setting up a development environment. After which you can follow the workflow below.

Bug-fix workflow

1. Add yourself as owner to the corresponding issue and mark it as “Started”

This will announce to everyone else that you are working on the bug, which most likely will make other affected users very happy which is always positive.

If there is no issue for the bug you want to fix you’ll need to create one first. See the Issue Tracking documentation for more information.

2. Find the earliest supported branch that has the bug

Besides master you’ll need to check the supported stable-branches.

One way to accomplish this is to write a test-case that reveals the bug and cherry-pick that onto each supported branch to see if the issue reproduces on that branch.

3. Fix the bug on this branch

Hard to give any generalizable advice since all bugs are not created equal, but if you get stuck you can always post a question on discord or the mailing list.

You should always aim to add a test-case that fails without your bug-fix.

Fixed on master?

Although this workflow should be followed when fixing bugs it sometimes happens that some of the steps are skipped. It may pay off to check if the bug is fixed on master.

NOTE: Not all changes are applicable or a good fit for older stable-branches. You should take great care when cherry-picking or otherwise back-porting fixes from newer stable branches or master.

To link the bug-fixing commit to the issue you should add a “Bug:” commit-message footer. Example: For the issue https://issues.gerritcodereview.com/issues/40013498, the “Bug:” footer would look like:

Document our current bug-fix workflow

Bug: Issue 40013498
Change-Id: I43574b6464b288643327529a3d0121bc9aad3b67

5. Push for review

You are now ready to push your fix for review.

6. Update release notes

Add an entry in the release-notes for the version were your fix will end up and upload for review.

7. [Optional] Merge your submitted fix back to master

Once submitted, if you applied your fix on a stable branch, that stable branch needs to be merged up to master through the more recent stable branches to apply the bug-fix on those as well.

This is eventually done as part of the release work so it isn’t necessary but it’s appreciated if you perform these merges yourself since, from fixing the bug, you have gathered a fresh understanding of the context and you are hence probably best suited to solve any conflicts.

Severe bugs and security fixes

Severe bugs and security issues are on occasion fixed in branches that are EOL since we try to offer some support to instances that haven’t been able to migrate to a supported version yet.