Holy cow, I wrote a book!
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
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
in a first-level branch.
This means that if you work in A1 and you
want a change to
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
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)