User Tools

Site Tools


spo600:2024_fall_project

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
spo600:2024_fall_project [2024/12/08 03:22] chrisspo600:2024_fall_project [2024/12/08 03:35] (current) chris
Line 187: Line 187:
 ===== Project Stage 3: Tidy & Wrap ===== ===== Project Stage 3: Tidy & Wrap =====
  
-Bring your work to a solid conclusion:+Bring your work to a solid conclusion. Take into account feedback received for Stage 2 and provide any documentation that is missing, incomplete, or unclear, as well as easily-testable code clearly showing your work.
   * Tidy up any loose ends from your Stage 2 work. If you have an incomplete experiment or investigation that you can complete, include it in your Stage 3.   * Tidy up any loose ends from your Stage 2 work. If you have an incomplete experiment or investigation that you can complete, include it in your Stage 3.
   * Provide the source code for the latest version of your project in a form which permits another person to examine, build, and test the changes which you have made. This can be done in any of several different ways (in decreasing order of preference):   * Provide the source code for the latest version of your project in a form which permits another person to examine, build, and test the changes which you have made. This can be done in any of several different ways (in decreasing order of preference):
Line 193: Line 193:
     * Or, provide a set of patch files containing your changes. The easiest way to generate this is with the 'git format-patch' command. Clearly document which upstream sources (e.g., GNU git, GitHub mirror, or another upstream such as the Darwin fork) and which commit number on the upstream server the patches should be applied against.     * Or, provide a set of patch files containing your changes. The easiest way to generate this is with the 'git format-patch' command. Clearly document which upstream sources (e.g., GNU git, GitHub mirror, or another upstream such as the Darwin fork) and which commit number on the upstream server the patches should be applied against.
     * Alternatively, provide a tar or zip archive that can be clealy applied to the upsteam sources which provides your updates (like the demo files in ''/public''). Clearly document which upstream sources and which commit number the archive should be applied against.     * Alternatively, provide a tar or zip archive that can be clealy applied to the upsteam sources which provides your updates (like the demo files in ''/public''). Clearly document which upstream sources and which commit number the archive should be applied against.
 +    * Test the access to your code (make sure that someone who is not you can access the source).
   * Clearly show the state of your work: what you attempted to do, what works and what does not, and what the output (e.g., dump files) look like and how that output should be interpreted.   * Clearly show the state of your work: what you attempted to do, what works and what does not, and what the output (e.g., dump files) look like and how that output should be interpreted.
   * Test your code with the [[#Test Cases for Pruning/No-Pruning]] and document the results.   * Test your code with the [[#Test Cases for Pruning/No-Pruning]] and document the results.
spo600/2024_fall_project.1733628133.txt.gz · Last modified: 2024/12/08 03:22 by chris

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki