Recently we migrated our source to git, and in the process became fans of github. We had been using Trac as our bug tracking software of choice, and it integrated smoothly with Subversion. Unfortunately, the git support was a bit lacking. There were a couple of plugins out there, but they didn’t really suit our needs. Fortunately, we found a better solution.

Enter Lighthouse. The guys at ActiveReload have designed a simple hosted issue and project management application that is easy on the eyes and plays great with github. We decided that a switch was in order. Since there’s currently no bulk import built into Lighthouse, we needed to migrate over a year’s worth of data. Luckily they offer an API and even a Ruby wrapper, which several folks have used to roll their own importers.

We first attempted to use Shay Arnett’s cool trachouse importer, but ran into some issues with our Trac authentication scheme and plugin setup. Trachouse fetches data from a Trac install by spidering your Trac website using hpricot. Since we were hosting our own Trac install, we figured it might be easier to just parse Trac’s sqlite database.

We put together a quick script to parse the trac.db and import it into Lighthouse using the lighthouse-api Ruby wrapper, and we (not so) cleverly dubbed it “Traclight”. We thought others might find this handy, and so there’s now a repo for it over at github.

To use it, you will need to edit the traclight.rb script and add your own conversion information, so the script will know how to translate Trac users, milestones, and states to the Lighthouse equivalents. You should create any user accounts and milestones ahead of time.

Next, export your trac database. See the trac FAQ for more information.

Now you are ready to run the script:

traclight.rb PATH_TO_TRAC_DB_FILE

There are a couple of caveats:

• Due to Lighthouse API limitations, ticket comments will be merged into a formatted description of the ticket.
• The tickets will show up as being reported by the owner of the account you specify in the ticket, not the original reporter. The original Trac reporter will show up in the description for the ticket.
• It is not possible to set the original date the ticket was reported in Lighthouse. The original reporting date of the Trac ticket will appear in the Lighthouse ticket description.
• Attachments are _not_ imported, as support currently doesn’t exist in the API.
• Starting with an empty Lighthouse project is recommended, since traclight will import the tickets in sequential order. That means that your ticket numbers should match up (as long as you never deleted tickets from Trac).

We used this to import around 5000 tickets spread over 15 milestones into Lighthouse using Traclight. Perhaps it’ll be of use to your team.

There are a plethora of ways to transcode your videos into a podcast-compatible format. We wanted to give you a quick walkthrough of how we use FFmpeg and AtomicParsley to do it.

First things first — check out Apple’s technical specifications to understand more about the podcast feed format and iPod-compatible video specifications. This post is going to focus on creating 320×240 videos in M4V format (which is really MPEG-4 video format) with a single audio channel. Why not 640×480? There’s some additional work that you have to do to update the M4V metadata so that the video will sync properly to video iPods and we’re still experimenting with it. Why a single channel of audio? Technically we should be able to do things in stereo (two channels of audio), but we ran into issues in production with the audio cutting out midway through some of our videos, and using a single channel of audio seemed to resolve the problem. You may not run into this issue so we’ll point out where to tweak the transcoding recipe so that you can use one or two channels.

The rest of this post assumes that you have the following software installed:

• FFmpeg - Open source video transcoding tool
• AtomicParsley - Open source tool for manipulating metadata in MPEG-4 videos

If you have a Mac and use MacPorts, here’s the easy/lazy way to do it:

• sudo port install ffmpeg +lame +libogg +vorbis +faac +faad +xvid +libx264 +a52
• sudo port install AtomicParsley

If you prefer to download and compile the packages, there are a number of useful resources to help guide you based on the operating system you are using — so we’re going to skip diving into additional detail there.

Step 1 - Transcode the video

We basically follow the recipe in Robert Swain’s post:

ffmpeg -i [input file] -f mp4 -acodec libfaac -ab 128k -ac 1 -vcodec libx264 -b 768k -flags +loop -cmp +chroma -partitions +parti4x4+partp8x8+partb8x8 -flags2 +mixed_refs -me umh -subq 5 -trellis 1 -refs 5 -coder 0 -me_range 16 -g 250 -keyint_min 25 -sc_threshold 40 -i_qfactor 0.71 -maxrate 768k -bufsize 2M -rc_eq 'blurCplx^(1-qComp)' -qcomp 0.6 -qmin 10 -qmax 51 -qdiff 4 -level 13 -s 320x240 -y [output file].m4v

A couple notes here:

• If you use a Mac and are on Tiger vs. Leopard, you’ll need to use x264 versus libx264 for the -vcodec value
• Change -ac 1 to -ac 2 if you want to try with 2 audio channels

Step 2 - Embed an image in the video’s metadata

Want a specific image to appear when your podcast videos display in coverflow?

Here’s where AtomicParsley works its magic.

AtomicParsley [output file].m4v --artwork [image] --overWrite

Note that per the Apple specs, you should use a 600×600 jpg or png image.

That’s all there is to it. Double-click on your M4V file and it should play in iTunes. Sync to your iPod and enjoy your video!