Changes between Version 12 and Version 13 of Developer/Contributing


Ignore:
Timestamp:
Mar 4, 2012, 4:40:33 AM (8 years ago)
Author:
Gedare
Comment:

/* Patches */

Legend:

Unmodified
Added
Removed
Modified
  • Developer/Contributing

    v12 v13  
    4040= Patches =
    4141
    42   *  If you are accessing the CVS repository at www.rtems.com, use "cvs update; cvs diff -c3p"; else, use "diff -c3p OLD NEW" or "diff -up OLD NEW". If your version of diff does not support these options, then get the latest version of GNU diff. Patches against current development (mainline CVS) are preferred to patches against releases, unless your patch is intended as a candidate for the release branch.
    4342
    44 Don't mix together changes made for different reasons. Send them individually. Ideally, each change you send should be impossible to subdivide into parts that we might want to consider separately, because each of its parts gets its motivation from the other parts. In particular, changes to code formatting to conform to coding standards are best not mixed with substantive changes, because that makes it difficult to see what the real changes are. (In the case of a very large reorganization of code, it may make sense to separate changes even further to make it clearer what has changed; for example, by first sending structural changes that make subsequent changes easier but do not change RTEMS's behavior, then new code, then the changes that actually make use of the new code and change RTEMS's behavior.)
     43A 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.
    4544
    46 We prefer patches posted as plain text or as 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, as long as the ChangeLog is still posted as plain text. 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.
     45Patches 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.
    4746
    48 When you have all these pieces, bundle them up in a mail message and send it to rtems-users@rtems.com". All patches and related discussion should be sent to the rtems-users mailing list. For further information on the RTEMS CVS repository, see the Anonymous read-only CVS access and Read-write CVS access pages.
     47Send 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.
    4948
    50 If you do not receive a response to a patch that you have submitted within a month or so, it may be a good idea to chase it by sending a follow-up email to rtems-users@rtems.com" or a member or the RTEMS Steering Committee. Patches can occasionally fall through the cracks. Please be sure to include the URL of the entry in the mailing list archive of the original submission.
     49Patches 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.
    5150
    52 Everything listed here still applies if you can check in the patch without further approval under the RTEMS write access policies, except that ChangeLog entries may be included as part of the patch since no-one else will need to apply it to the tree later and diffs representing totally new files may be omitted (especially if large) since they can be accessed directly from the repository.
     51We 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.
     52= Submitting =
     53
     54
     55When you have all these pieces send them to the [wiki:TBR/Website/RTEMSMailingLists developers mailing list] or post a [wiki:Bugzilla bug report]. All patches and related discussion should be sent to the rtems-devel mailing list. For further information on the RTEMS Git repository, see [wiki:Git Git].
     56
     57If you do not receive a response to a patch within a month or so, send a follow-up email. Patches occasionally fall through the cracks. Please be sure to include the URL of the entry in the mailing list archive of the original submission.
     58
     59Everything listed here still applies if you can check in the patch without further approval under the RTEMS write access policies.