Changes between Version 33 and Version 34 of Developer/Contributing


Ignore:
Timestamp:
Nov 22, 2018, 4:17:22 PM (7 months ago)
Author:
Abhimanyu Raghuvanshi
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Developer/Contributing

    v33 v34  
    3737With documentation changes, you must make the doc manuals and correct any errors.
    3838
    39 In all cases you must test exactly the change that you intend to submit; it's not good enough to test an earlier variant. The tree where you perform this test should not have any other changes applied to it, because otherwise you cannot be sure that your patch will work correctly on its own. Include all your new test cases in your testsuite run.
     39In all cases you must test exactly the change that you intend to submit; it's not good enough to test an earlier variant. The tree where you perform this test should not have any other changes applied to it, because otherwise, you cannot be sure that your patch will work correctly on its own. Include all your new test cases in your testsuite run.
    4040= Patches =
    4141
    42 A 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 confirm 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.
     42A 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.
    4343
    4444See [wiki:Developer/Git/Users#CreatingaPatch  Creating a Patch] for details on how to use Git to create patches.
     
    8585   *  Doesn't explain that RTEMS is a library that an application is linked against to create a single binary - this can be confusing for users of other RTOSs that operate differently
    8686 *  [wiki:NewTicket Problem Reports]
    87   *  Problem Reports, or ''PRs'' are submitted by users to raise attention to a deficiency. Sometimes they're out-of-date and the problem has since been fixed - it can be very helpful to confirm this, perhaps by attempting to reproduce it. Sometimes PRs may have been mis-filed (for example, an RTEMS Source Builder-related problem might be filed under RTEMS, hindering the appropriate people from being alerted)
    88  *  Web site - suggest and/or prototype improvements to the [http://www.rtems.org RTEMS Web site]
     87  *  Problem Reports, or ''PRs'' are submitted by users to raise attention to a deficiency. Sometimes they're out-of-date and the problem has since been fixed - it can be very helpful to confirm this, perhaps by attempting to reproduce it. Sometimes PRs may have been misfiled (for example, an RTEMS Source Builder-related problem might be filed under RTEMS, hindering the appropriate people from being alerted)
     88 *  Website - suggest and/or prototype improvements to the [http://www.rtems.org RTEMS Web site]
    8989= Coding =
    9090