Gerrit Rules

From Omni
Revision as of 22:51, 1 November 2013 by Jerdog (Talk | contribs)

Jump to: navigation, search

Submitting a patch

The contents of your patch

You should make sure you use different repo branches for your patch, to ensure you don’t have an unneeded dependency on another patch. Use repo start for every new changeset you make, and repo checkout to switch between your changes. For more on repo and git see Using repo and git

Your code should contain only the required changes to make your feature work. You should remove all unneeded comments (debug, commented code) and code (unneeded debug Log commands, etc).

Make sure your code style sticks to the Android Guidelines, and that you don’t have trailing spaces (spaces at the end of a line).


Commits that are work-in-progress may bypass the above paragraph, but must be clearly marked with a [WIP] tag at the very beginning of the commit message. This way, they won’t be auto-tested by our verification bot, and testers will know your patch isn’t ready for prime time yet.

Formatting your commit message

The first line of your commit message should be a swift summary of your change, that should make your patch recognizable easily on Gerrit’s patch list.


  • surfaceflinger: Add compatibility support for MTK
  • liblights: Fix keys not lighting up on i9300
  • telephony: Enhance the way CDMA is operated


  • MTK support
  • ……!!!!!!!
  • Add class1, class2, backwards compatibility, support layer and gralloc changes to make MTK chipsets (6589, 6582) working with Android 4.3

The following lines should contain a deeper explanation of what your commit changes (e.g. with answers to ‘why’ and ‘how’ your patch). Indicating changes between different Patch Sets might be a good idea. It is possible however to give details in the comments section instead.

Cherry-picks from other sources

In case you’re cherry-picking a patch from a trustable upstream (the Linux kernel, the AOSP), you should not change the commit message, so that we can recognize upstream patches more easily, and keep history clean. Comments should be done in the Gerrit ticket’s comment section, not in the commit message.

Multi-project changes

In some cases, one feature might affect multiple projects (repositories) at once, in a way that you need to upload multiple Gerrit review tickets. In such case, your changes should follow the following naming convention:

[1/2] xxx: yyyyyyyyyyyyyyyyy [2/2] xxx: yyyyyyyyyyyyyyyyy

As we have an automated system testing patches, you must follow that naming convention properly, and affect the same topic name to the patches going together: