[OH-Dev] Training missions: is a realistic plot okay?

[Asheesh Laroia]

I'm thinking of adding more training missions that are realistic 
tutorials, rather than whimsical plots.

For context -- I'm sitting here at Wikimania, helping a Mozillian with 
some Debian/Ubuntu packaging work, and teaching him how to use "quilt". It 
turns out that there's a super-bitesize bug in a package called 'arduino', 
and that it can be used as part of tutorials on:

* testing packages to make sure that bugs are still present

* rebuilding Debian packages from source

* using 'quilt' to create patches to fix bugs in Debian packages

(This is the bug link: 
https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/998952 )

There are quite a few places in this process that it's easy to get lost! 
That suggests to me that the the 'training mission' format of having the 
website verify your work periodically is still quite appropriate.

So here's the question: What if I add one or two (or three?) training 
missions around .deb packaging that have realistic plots, involving actual 
user-facing bugs in older versions of packages, rather than the whimsical 
sort of thing we added like the 'cookbook' setup for the "diff/patch" 
mission?

It seems sensible to me, and I know the training missions were originally 
my idea, so arguably I can just be bold and add these new missions, but I 
thought I'd check to see what others think first.

(It also seems quite nice to have a reasonably-large collection of 
these, and then we can let people try out the process of contributing to 
a project through a simulation.)

I'm also attaching my very skechy 1;5Cnotes from what I watched him do, 
just so they're somewhere reasonable.

Yours truly,

-- Asheesh.
-------------- next part --------------
Learning objective: Gain experience using "quilt" so that you know how to modify Debian packages that use quilt

https://bugs.launchpad.net/ubuntu/+source/arduino/+bug/998952

Activity: Take a package with a bug, and understand the bug.
          Use "quilt new" and "quilt edit" and friends to fix the bug.
            Assessment: Upload the resulting patch file to make sure it's great.
          
          First, upload the resulting .Download a particular .deb package

Pre-requisites:
          Configure .quiltrc
          apt-get build-dep packagename


To learn apt + quilt interactively, by running through examples:

* Make sure you have a 'deb-src' line
** apt-cache showsrc
** software-properties-gtk
** or edit sources.list

* Start by apt-get source arduino

* When running quilt, always be within the packagname-version.x.y.z directory

* Make sure your changes are not already present!

* First, 'quilt refresh' -- prints the "top" patch name

* then 'quilt add' your patch name

* then make your changes! with 'quilt edit' filename

* Check debian/patches -- your patch is missing

* when 'quilt add' (or friends) prints the patch name, it hasn't saved yet

* then 'quilt refresh' will save your changes. But do it wrong

** Check debian/patches -- your patch is there, but wrong

* 'quilt edit' filename to make a slightly different change

* now 'quilt refresh' and see that your patch is correct this time

* dpkg-buildpackage

* Check that it actually works

** dpkg -i arduino*deb

** File->Open etc.

* Check that if you remove the patch, you can reproduce the failure

** cd ardino*

** quilt remove myapatchname

** can you reproduce the problem? Great.

* WhAT? It's already fixed in Debian!!??

** requestsync -d unstable arduino



** to start over:

dpkg-source -x *.dsc