Changes between Version 4 and Version 5 of CodingGuidelines/SubmittingPatches


Ignore:
Timestamp:
May 5, 2010, 9:53:23 PM (15 years ago)
Author:
mmadia
Comment:

added automatic whitespace, more formatting.

Legend:

Unmodified
Added
Removed
Modified
  • CodingGuidelines/SubmittingPatches

    v4 v5  
    11== Submitting Patches ==
    22
    3  * 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.
     3=== Expressing your desire to work on a ticket ===
     4By 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.
     5
     6=== Automatic whitespace cleanup ===
     7Sometimes you'll see a commit message of "Automatic whitespace cleanup. No functional change.", for example r36509. 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.
     8 * In the menu bar, select Window --> Preferences
     9 * Select "Files" from the left pane
     10 * enable [x] Discard trailing space
     11 * click [Apply]
     12Now, when you save & close a file, any stray spaces at the end of any lines will be automatically removed.
     13
     14=== Preparing to create patch file ===
    415 * Create patches from within the ''HAIKU_TOP'' directory. This is the directory that contains ''configure'' and typically is ''haiku/'' or ''buildtools/''
     16        * {{{ svn stat }}} will display which files are modified, added, or deleted
    517        * {{{ svn diff path/to/modified/files additional/paths/are/allowed/ > ~/DescriptiveName.patch }}}
    618        * ''Note:'' If patching newly created files, {{{ svn add <path-to-new-file> }}} needs to be done before {{{ svn diff }}}
    7  * Plain text is preferred, as it allows easy viewing within the browser.
     19
     20=== Submitting the patch ===
     21 * Plain text is preferred (not compressed files), as it allows easy viewing within the web browser.
    822 * The [http://www.haiku-os.org/development/coding-guidelines Coding Guidelines] are expected to be followed when submitting patches.
    923        * '''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.
    10  * [http://dev.haiku-os.org/browser/haiku/trunk/src/tools/checkstyle checkstyle] can be used to help identify violations.
     24 * [http://dev.haiku-os.org/browser/haiku/trunk/src/tools/checkstyle checkstyle] can be used to help identify violations
    1125 * [wiki:HaikuCodingGuidelinesVIM] integrate with vim to check style.
    12  * ''Lastly and most importantly'': once a developer reviews your submitted code, expect them to point out any and all flaws. This is standard procedure.
     26Be aware, that these style checker tools may generate false positives (eg, evaluating comments as coding violations) or may miss other violations.
     27
     28=== Following up ===
     29''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.
     30
     31You may want to either subscribe to or read the [http://www.freelists.org/list/haiku-commits haiku-commits] mailing list archives. It is quite common for the discussion of recently committed code to occur on this list.
     32