Submitting Patches

Expressing your desire to work on a ticket

By default, tickets are assigned to a default component owner. If you wish to work on an assigned ticket, simply comment on the ticket to inform the person. For the most part, this is to reduce the frustration of duplicating work.

Automatic whitespace cleanup

Sometimes you'll see a commit message of "Automatic whitespace cleanup. No functional change.", for example hrev36509. It is preferred for new code to not introduced unneeded whitespace. Luckily, there is an option in Pe to perform this for you automatically. Here is how to enable it from within Pe.

• In the menu bar, select Window --> Preferences
• Select "Files" from the left pane
• enable [x] Discard trailing space
• click [Apply]

Now, when you save & close a file, any stray spaces at the end of any lines will be automatically removed.

Preparing to create patch file

• Before making any commits to the Haiku repository (local even), be sure to ​configure the git environment on your local system! Failure to configure git properly before a commit will result in incorrect naming in your commit and public humiliation on the mailing list.
• Create patches from within the HAIKU_TOP directory. This is the directory that contains configure and typically is the haiku/ or buildtools/ branch.
  • git status will display which files are modified, added, or deleted. Use git diff to inspect your changes.
• You'll then have to commit the patch locally by adding the changed or added files (git add my-file my/new/file), and then do a git commit. You will need to enter a complete commit message that will later appear as is in Haiku's repository if your patch is going to be accepted.
• Now, you need to create the actual patch file that you can, for example, attach to a ticket:
  • git format-patch <commitsha or branch name> - this will create a file named 0001-your-commit-message.patch. (Note: Depending on your workflow, git format-patch HEAD~1 may also suffice)

Submitting the patch

• Plain text is preferred (not compressed files), as it allows easy viewing within the web browser.
• The ​Coding Guidelines are expected to be followed when submitting patches.
  • Note: When patching existing files that do not follow our Coding Guidelines, it is preferable to apply the stylization to the entire file. If that is not possible, then conform to the pervading style being used.
• ​checkstyle can be used to help identify violations
• CodingGuidelines/VIM integrate with vim to check style.
• When submitting the patch to a ticket, check the 'patch' check box in the 'Attachment Flags'

Be aware, that these style checker tools may generate false positives (eg, evaluating comments as coding violations) or may miss other violations.

Following up

Lastly and most importantly: once a developer reviews your submitted code, expect them to point out any and all flaws. This is standard procedure and is constructive criticism. Remember, we want to help you improve your coding abilities.

You may want to either subscribe to or read the ​haiku-commits mailing list archives. It is quite common for the discussion of recently committed code to occur on this list.