Microspeak: The train

Raymond Chen

Work on Windows occurs in several different branches of the source code, and changes in one branch propagate to other branches. The goal is to push changes toward the trunk on a regular cadence. I will illustrate with an extremely simplified example because the complexities aren’t really important. Consider this branch structure:

Suppose for the sake of simplicity that odd-numbered leaf branches push their changes to the first-level branches on Mondays and Wednesdays, and even-numbered leaf branches push their changes on Tuesdays and Thursdays. Furthermore, once a week (A on Monday, B on Tuesday, etc, with Friday as a buffer day) each first-level branch pushes its changes to the trunk. It does this before accepting changes from the child branch that same day, so that every change spends at least one day baking in a first-level branch.

This means that if you work in A1 and you want a change to land in the trunk by next Monday, you need to commit it to A1 by Wednesday. Otherwise, you will miss the train.

The metaphor here is that code changes are cargo (known in the lingo as payload) which are transported by an imaginary train to the next station (branch). If you miss the train, then your change sits on the platform and waits for the next train.

The imaginary train schedule looks like this:

(Note that nobody actually refers to this as the train schedule. We call it the RI schedule, where RI is pronounced as two letters and not like the word rye.)

Suppose that there’s a problem in B1 on Monday, and the branch managers decide to delay pushing their changes to B until they understand the problem and have a fix for it. If they cannot get this done before 4pm Tuesday, then the scheduled RI from B to the trunk will take place without any payload from B1. B1 is said to have missed the RI train. Unless they take special steps, their changes won’t appear in the trunk until the following Tuesday at the earliest.

There are few things that B1 could do when they find themselves in this situation.

They could ask that the RI from B to the trunk be delayed until after they figure out the problem and push the fix from B1 into B. This is like asking for a train to be held at the station so that passengers on an inbound train can make their connection.

Maybe there’s a bad bug that’s in the trunk, and B1 has a fix for it. They could push just the one bug fix from B1 into B, and let that fix get pushed to the trunk on Tuesday. I guess this is like kicking everybody off the train back onto the platform except for the one fix you want to take.

B1 could negotiate a deal with C. “Hi, we have a fix that needs to go the trunk, but our branch is in kind of bad shape. Could you take it to the trunk for us?” The fix is pushed from B1 to C on Tuesday, and then it catches the train from C to the trunk on Wednesday. This is sort of like going to a different station.

They could ask for permission to make a direct change to the trunk, bypassing all the trains that normally take changes to the trunk. I’m running out of metaphors here. Maybe this is “taking the plane”? No wait, we actually have lingo for this too. It’s called fast-track, sometimes written as fasttrack without the hyphen.

The train terminology can get more specific, with trains named after the release they are destined for. For example, the C1 branch manager might say, “The last beta train has left C1. If you still have a beta bug and you can get your fix signed off before Wednesday, contact the C branch team; we may be able to get you onto the last beta train out of C. Otherwise, you need to work with the beta release team. See the XYZ Web site for further information.”

Here’s some sample text from the trunk management team which incorporates a lot of the lingo. Practice it and you too can sound like a hip insider.

Today, we took the scheduled RI from A and two fast-track fixes, one from the B team (for bug 3141) and one from the C team (for bug 2718)

Raymond Chen

Follow