lab2

COMP8440: Lab2 - choice of 3

The aim of this lab is similar to the previous 'tuxpaint' lab, but you will have a choice of 3 projects to investigate. The idea is to expose you to a wider range of common FOSS project ideas.

In this lab you will also need to create a patch against your chosen project, and submit that patch to the comp8440@fossd.anu.edu.au mailing list. Then you should look for another students patch submission for the same project apply their patch, and send back a reply to them commenting on their patch.

The 3 projects are:

The level of difficulty in building these projects varies quite a lot. As a rough guide, the above list is approximately in order of difficulty, with SGT Puzzles being the easiest and gedit the hardest. In order to maximize exposure of each students to as many projects as possible, when a student runs into difficulties we will often display their screen on the projector so we can discuss the problem as a class, and try to come to a solution together.

The level of difficulty is also heavily dependent on what method you use to fetch the source code. If you are very inexperienced with building FOSS packages, then the easiest approach will be to use the package manager to download the sources. If you are more experienced, then you should try to build the project using the latest development version (downloaded using a source code management system).

Note: Please read the build tips page carefully before you start!

Helping other students

Cooperation between developers is one of the cornerstones of FOSS development. So please help out your fellow students if they are stuck and you know what the problem is. If you think the problem is of wider interest, then ask one of the tutors to display the students screen on the projector.

Faster download

Some of the above project are very large, and downloading the source code using a SCMS may take too long for this lab. For that reason we have put a snapshot of some of the project trees in /comp8440/sources. See the build tips page for more information.

Things to think about

Here are some things to work out about the project you are building

How active is development? How many people have contributed changes in the last year?
What method does the project use to customise itself to your system?
How is the documentation for the project written?
How does the project handle releases? Does it use branches?
How does the project fit in with other projects? What does it depend on?
How do the developers for the project communicate?
How do you submit changes to the project?

Patch submission

Once you have successfully built the project, you should generate a patch against it, and submit that patch to the comp8440 mailing list.

To generate a patch, first make a code change of some sort. It is not necessary for this to be a serious or substantial code change - any small change will do for the purposes of this lab.

Once you have made the change, you will need to generate the patch. You can either use the 'diff' tool, or you can use the builtin patch generation in a source code management tool if you used one to download the package.

Here are the commands for creating and working with your patch.

Display the difference in code using diff command:

diff -up program.c.old program.c

Creating a patch using diff command:

diff -up program.c.old program.c > somepatch.patch

Producing difference statistics using the diffstat command:

diffstat somepatch.patch

Your patch submission should meet the following criterion:

You must have tested that your change works
It should be in diff -up format
The patch should be inline in the email, not sent as an attachment
It should contain the diffstat output at the front
It should contain an explanation of your changes
It should have a clear subject, prefixed with "[PATCH]"
It should say "Signed-off-by: YOUR EMAIL"

If you want to see some examples of patches, you might like to look at the Linux kernel mailing list, for messages starting with "[PATCH]"

Patch acceptance

After submitting a patch, wait for someone else in the lab to submit a different patch for the same project. You should then examine their patch, and try to apply it to your copy of the project. You will need to use the 'patch' tool to do that.

A typical patch command would be:

patch -p1 < somepatch.patch

After examining and testing their patch, you should either accept it or reject it by sending a reply to the person submitting the patch. You should make sure your reply is CCd to the mailing list. In your reply you should explain your acceptance or rejection of the patch. If you reject their patch, then you should watch for a further email from them fixing whatever problems you identified in their patch. If the patch is now acceptable, you can reply saying that you accept their patch.

Lab continuation

Don't worry if you don't complete the work for this lab in the time allotted. You can continue with this lab during the next lab session if need be.

SCM Tips

You may find some of the tips on the SCM Tips page useful for this lab.

MAKE SURE YOU BACKUP

Make sure you do a backup at the end of the lab, or you may lose all your work.