Open Source Comes to Campus/Curriculum/Saturday: Difference between revisions
Content added Content deleted
imported>Paulproteus |
imported>Paulproteus |
||
| (One intermediate revision by the same user not shown) | |||
| Line 15: | Line 15: | ||
== Getting, modifying, and verifying open source software (getting code; local patching) == |
== Getting, modifying, and verifying open source software (getting code; local patching) == |
||
* [[/Getting modifying and verifying]] |
|||
'''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 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) == |
== Project organization (bug trackers; git format-patch; github; people's roles in a project) == |
||
* [[/Project organization]] |
|||
'''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''' |
|||
* ? |
|||
Latest revision as of 22:29, 23 February 2012
Note well: This is just a draft; work in progress.