Solving Issues

Most of the programming exercises we will solve will originate as Issues in one of the course's repositories. Each issue will [usually] describe a small new feature that should be added to our code base. These Issues are different from your normal homework assignments---each issue only needs to be solved by one student (or small team of students). You can pick and choose which issues you want to try to solve, just be sure someone else doesn't write the code first!

Finding an Issue

For now, all Issues will be in the Adv-net-samples repository Issue Tracker. They are tagged based on the topic area (e.g., multi-threading vs networking) and the expected difficulty (easy, medium, or hard). Issues are also grouped by Milestones---these represent our progress through the course's various topic areas. Also, some issues are marked as having Dependencies; this means that there is some other issue that probably should be solved first.

Take a look through the issue list and see what interests you!

Claiming an Issue

Once you find an issue that you want to solve, verify that it is not yet Assigned to anyone (on the main list it will show a user's icon under Asignee) and that no one else has posted a comment to claim the issue. If it has not been claimed, then post an issue saying that you want to work on it. If you are part of a team, tag the members of your team by using the @ sign and their usernames. If you are the first to claim the issue, you can start working on it. Sometime later I will officially assign you under the issue.

When you claim an issue, you should do your best to try to fully solve it within the next 24-48 hours! For larger issues it may take more time than that, but you should try to add comments to the Issue as you work so that we know you are actively trying to solve the problem.

If issues are assigned to someone, but they don't seem to be making progress, I may re-assign the task to someone else.

Writing your Code

You should write the code that solves the issue into your fork of the repository. You can commit and push that repository to your account however you like without affecting our main repo.

Your code must follow the GW CloudLab Style Guide (which is a close match to Gabe Parmer's Composite OS Style Guide). Be sure to read the guide and follow its formatting and naming conventions.

As you are coding, feel free to post comments to the Issue describing any problems or asking for suggestions. The best way is to commit and push code to your repo, and then put a link to the part of the code you are having trouble with in a comment. The instructor or other students will try to help you out!

Making a Pull Request

Once you are happy with the code you have written to solve the Issue, you should push it to your repository and then use the github web interface to make a Pull Request. You do this from your fork of the repository, and it will make a request to send your modified files into the main version of the repo. In the comment for your pull request, you should explain what you have done and mention the issue you are solving--reference the number by using the # (pound) sign and the number of the issue.

You also should add a comment to the original issue at this point to explain that you have solved it and make any notes that you think might be helpful to others (e.g., how to build and run the code if you have added new files).

Read about how to make a good Pull Request here.

Getting Approval

If your code looks good, then Tim will approve your pull request and merge your changes with the main repository! Congrats, you just made the world a (very slightly) better place through coding!

Updating Your Repository

Keep in mind that the main repository will be constantly being updated by other students. As a result, your fork of the repo will lag behind over time. To be sure that you have the latest code, you will need to use the web interface to pull from the main repository, or run git pull upstream master (assuming you setup the upstream remote properly as listed in the slides from Week 1). You should always do this before starting to code, as well as after you see the main repository updated!