lab2.php

   1 <?php
   2 include "8440head.php";
   3 ?>
   4
   5
   6
   7 <center>
   8 <h1>
   9 <font color="#931515" size="+3">COMP8440: Lab2 - choice of 5</font>
  10 </h1>
  11 </center>
  12
  13 The aim of this lab is similar to the previous 'a2ps' lab, but you
  14 will have a choice of 5 projects to investigate. The idea is to expose
  15 you to a wider range of common FOSS project ideas.
  16
  17 <p>In this lab you will also need to create a patch against your
  18 chosen project, and submit that patch to the <a
  19 href="mailto:comp8440@fossd.anu.edu.au">comp8440@fossd.anu.edu.au</a>
  20 mailing list. Then you should look for another students patch
  21 submission for the same project apply their patch, and send back a
  22 reply to them commenting on their patch.
  23
  24 <p>The 5 projects are:
  25
  26 <ul>
  27 <li>FreeCIV
  28 <li>Battle for Wesnoth
  29 <li>gedit
  30 <li>gimp
  31 <li>LibreOffice
  32 </ul>
  33
  34 The level of difficulty in building these projects varies quite a
  35 lot. As a rough guide, the above list is approximately in order of
  36 difficulty, with FreeCIV being the easiest and LibreOffice the
  37 hardest. In order to maximize exposure of each students to as many
  38 projects as possible, when a student runs into difficulties we will
  39 often display their screen on the projector so we can discuss the
  40 problem as a class, and try to come to a solution together.<p>
  41
  42 The level of difficulty is also heavily dependent on what method you
  43 use to fetch the source code. If you are very inexperienced with
  44 building FOSS packages, then the easiest approach will be to use the
  45 package manager to download the sources. If you are more experienced,
  46 then you should try to build the project using the latest development
  47 version (downloaded using a source code management system).<p>
  48
  49 Note: Please read the <a href="building.php">build tips</a> page
  50 carefully before you start!
  51
  52 <h3>Helping other students</h3>
  53
  54 Cooperation between developers is one of the cornerstones of FOSS
  55 development. So please help out your fellow students if they are stuck
  56 and you know what the problem is. If you think the problem is of wider
  57 interest, then ask one of the tutors to display the students screen on
  58 the projector.
  59
  60 <h3>Faster download</h3>
  61
  62 Some of the above project are very large, and downloading the source
  63 code using a SCMS may take too long for this lab. For that reason we
  64 have put a snapshot of some of the project trees in
  65 /comp8440/sources. See the <a href="building.php">build tips</a> page
  66 for more information.
  67
  68 <h3>Things to think about</h3>
  69
  70 Here are some things to work out about the project you are building
  71
  72 <ul>
  73 <li>How active is development? How many people have contributed
  74 changes in the last year?
  75 <li>What method does the project use to customise itself to your
  76 system?
  77 <li>How is the documentation for the project written?
  78 <li>How does the project handle releases? Does it use branches?
  79 <li>How does the project fit in with other projects? What does it
  80 depend on?
  81 <li>How do the developers for the project communicate?
  82 <li>How do you submit changes to the project?
  83 </ul>
  84
  85 <h3>Patch submission</h3>
  86
  87 Once you have successfully built the project, you should generate a
  88 patch against it, and submit that patch to the comp8440 mailing list.
  89
  90 <p>To generate a patch, first make a code change of some sort. It is
  91 not necessary for this to be a serious or substantial code change -
  92 any small change will do for the purposes of this lab.
  93
  94 <p>Once you have made the change, you will need to generate the
  95 patch. You can either use the 'diff' tool, or you can use the builtin
  96 patch generation in a source code management tool if you used one to
  97 download the package.
  98
  99 <p>Here are the commands for creating and working with your patch.
 100
 101 <p>Display the difference in code using diff command:
 102 <pre><b>
 103   diff -up program.c.old program.c
 104 </b></pre>
 105
 106 <p>Creating a patch using diff command:
 107 <pre><b>
 108   diff -up program.c.old program.c > somepatch.patch
 109 </b></pre>
 110
 111 <p>Producing difference statistics using the diffstat command:
 112 <pre><b>
 113   diffstat somepatch.patch
 114 </b></pre>
 115
 116
 117 <p>Your patch submission should meet the following criterion:
 118
 119 <ul>
 120 <li>You must have tested that your change works
 121 <li>It should be in diff -up format
 122 <li>The patch should be inline in the email, not sent as an attachment
 123 <li>It should contain the diffstat output at the front
 124 <li>It should contain an explanation of your changes
 125 <li>It should have a clear subject, prefixed with "[PATCH]"
 126 <li>It should say "Signed-off-by: YOUR EMAIL"
 127 </ul>
 128
 129 If you want to see some examples of patches, you might like to look at
 130 the <a href="http://marc.info/?l=linux-kernel">Linux kernel mailing
 131 list</a>, for messages starting with "[PATCH]"
 132
 133 <h3>Patch acceptance</h3>
 134
 135 After submitting a patch, wait for someone else in the lab to submit a
 136 different patch for the same project. You should then examine their
 137 patch, and try to apply it to your copy of the project. You will need
 138 to use the 'patch' tool to do that.
 139
 140 <p>A typical patch command would be:
 141 <pre><b>
 142   patch -p1 < somepatch.patch
 143 </b></pre>
 144
 145 <p>After examining and testing their patch, you should either accept
 146 it or reject it by sending a reply to the person submitting the
 147 patch. You should make sure your reply is CCd to the mailing list. In
 148 your reply you should explain your acceptance or rejection of the
 149 patch. If you reject their patch, then you should watch for a further
 150 email from them fixing whatever problems you identified in their
 151 patch. If the patch is now acceptable, you can reply saying that you
 152 accept their patch.
 153
 154 <h3>Lab continuation</h3>
 155
 156 Don't worry if you don't complete the work for this lab in the time
 157 alotted. You can continue with this lab during the next lab session if
 158 need be.
 159
 160 <h3>SCM Tips</h3>
 161
 162 You may find some of the tips on the <a href="scm-tips.php">SCM
 163 Tips</a> page useful for this lab.
 164
 165 <h1>MAKE SURE YOU BACKUP</h1>
 166
 167 Make sure you do a backup at the end of the lab, or you may lose all
 168 your work.
 169
 170 <p><div align="center">
 171   <?php
 172     print " Last modified: ";
 173     $last_modified = getlastmod();
 174     print(date("j/m/Y, H:i", $last_modified));
 175   ?>
 176 </div><p>
 177
 178 <?php
 179 include "8440tail.php";
 180 ?>
 181
 182
 183