Changes between Version 14 and Version 15 of Developer/Contributing


Ignore:
Timestamp:
Mar 4, 2012, 10:39:04 PM (7 years ago)
Author:
Gedare
Comment:

/* Patches */

Legend:

Unmodified
Added
Removed
Modified
  • Developer/Contributing

    v14 v15  
    3939
    4040
    41 A patch is a text file containing the difference between an old and new version of code. If you are using the Git repository see the [wiki:Git_Users#Creating_a_Patch_  Git patch instructions] for how to generate patches to submit. If you do not have the Git repository available then you should use the diff program to create a patch by comparing an unmodified RTEMS against the version containing your changes with ''diff -up rtems rtems-new'' and redirect the output to a file.
     41A patch is a text file containing the difference between an old and new version of code. Patches against current development (git head) are preferred to patches against releases unless your patch is intended as a bug fix candidate for a release branch. Send one patch for each logical change made. Each patch you submit should be impossible to subdivide into more patches because of dependencies between the changed parts. Patches that fix code formatting to conform to [wiki:Developer/Coding/Conventions our standards] are best not mixed with substantive changes and vice versa, because the code reformatting hides the functional changes.
    4242
    43 Patches against current development (git head) are preferred to patches against releases unless your patch is intended as a bug fix candidate for a release branch.
     43The recommended way to create a patch is to branch the [wiki:Git git repository] master and use one commit for each logical change. Then you can use ''git-format-patch'' to turn your commits into patches and easily submit them.
     44{{{
     45 git format-patch master
     46}}}
     47Creates a separate patch for each commit that has been made between the master branch and the current branch and writes them in the current directory. Use the -o flag to redirect the files to a different directory. These files, appended with .patch, are formatted so they can be emailed and rely on having git configured with your name and email address, for example
     48{{{
     49 git config --global user.name "Your Name"
     50 git config --global user.email name@domain.com
     51}}}
    4452
    45 Send one patch for each logical change made. Each patch you submit should be impossible to subdivide into more patches because of dependencies between the changed parts.
     53If you do not have the Git repository available then you can use the diff program to create a patch by comparing an unmodified RTEMS against the version containing your changes with ''diff -up rtems rtems-new'' and redirect the output to a file.
    4654
    47 Patches that fix code formatting to conform to [wiki:Developer/Coding/Conventions our standards] are best not mixed with substantive changes and vice versa, because the code reformatting hides the functional changes.
    48 
    49 We prefer patches posted as plain text. Also acceptable are MIME parts of type text/x-patch or text/plain, disposition inline, encoded as 7bit or 8bit. If the patch is too big or too mechanical, posting it gzipped or bzip2ed and uuencoded or encoded as a base64 MIME part is acceptable. Other than that, it is strongly discouraged to post patches as MIME parts of type application/whatever, disposition attachment and/or encoded as base64 or quoted-printable. Avoid MIME large-message splitting (message/partial) at all costs.
     55We prefer patches posted as plain text. If the patch is too big posting it gzipped is acceptable but it would be better as a branch that can be pulled/reviewed. Submit your patch to the [wiki:RTEMSMailingLists_  rtems-devel mailing list] and if the patch fixes a bug, file a PR on the [wiki:Bugzilla Bugzilla].
    5056= Submitting =
    5157