Open Source Comes to Campus/Curriculum/Saturday
Note well: This is just a draft; work in progress.
The command line, packages, and dependencies
Communicating as a user: finding the community and getting help
Ethics and history of open source; and economics and licensing that support it
Getting, modifying, and verifying open source software (getting code; local patching)
Pre-requisites: ?
Learning objectives: Know how to download a tarball and apply a patch. Understand what a patch file looks like. Understand the idea of "-p0" "-p1" fiddling. Understand how to verify a tarball against a SHA1 checksum, and why it matters. Understand how to use GPG to verify a SHA1SUMS file! Understand the basic idea of version control, and know how to create a patch file against code stored in two common VCSs.
Group discussion
- Question: Where do tarballs come from?
- Answer: Someone takes a snapshot of a directory. But how did things get in there?
- Quick overview of a patch file
- Verifying tarballs
- Why authenticity is desirable
- Example: Linux driver with a uid=0 vs. uid == 0 bug introduced
- md5sum + sha1sum
- verifying md5sum + sha1sum lists with gpg
- Quick introduction to the web of trust
- Why authenticity is desirable
- Why people use version control
- You can check if your patch is in the main tree or not
- It makes it super easy to create patches
- It is easy to jump between versions
- Quick mention of packaging systems
- Quick introduction to installing build dependencies
Individual work
- Have students go through the git training mission.
- Have students download a few tarballs and identify which ones do not verify.
Assessment elements
- The training missions includes their own assessments.
Possible problems
- ?
Project organization (bug trackers; git format-patch; github; people's roles in a project)
Pre-requisites: ?
Learning objectives: Understand the question of who makes tarballs. Be able to, given an arbitrary project, decide where to send a patch. Be able to contribute to discussions on bug trackers.
Group discussion
- 5 min: Briefly discuss different decision-making structures within a project
- "Benevolent dictator", as within Linux
- Decentralized do-ocracy, as within Debian
- 10 min: Discuss different roles (aka job descriptions) within a project, and what skills they need; preferably painting a picture by using a specific person in a specific project each time
- Documentation author
- Artwork contributor
- Code contributor
- Code reviewer
- Bug submitter
- Security reviewer
- Bug manager (AKA triager)
- Security contact
- Publicity person (e.g., blogger, or release-notes author or conference-goer)
- Release manager
- User supporter
- 5 min: Explain "forking", both hostile and non-hostile
- Quick introduction to "normal" (AKA decentralized) VCSs, vs. old-style centralized ones
- In git and friends, anyone can "commit"
- Anyone can push their work anywhere
- Centralized ones are like this but more restricted.
Individual work
- Have students take some simple-ish code project and modify it to work differently, perhaps with just adding their name to AUTHORS, and push their modded version to Github and submit a pull request.
- Examine one of a few amusing bugs (randomly assigned to different students) and explain the bug to the student next to you
- If you need help understanding the bug, talk to a teacher who will explain it.
- Examine one snapshotted bug in a project, and explain what further work is needed to push the patch along. (Example: Fx bug where on Windows 7, all the bug needed was someone to fix its coding style.)
Assessment elements
- Students make sure the other student's github pull request is right.
- Optional: Make there be a github training mission.
- Students explain to one-another what work is required on a bug.
Possible problems
- ?