Linearized 2.6.33.7-rt30 patch set available (with free coffee!)

[Paul Gortmaker <paul.gortmaker@windriver.com>]

Some of you may be asking just what that means.

The RT changes are like the milk added to a cup of coffee.  You add a
small amount and it changes the flavour of the normal coffee (kernel.)

Now imagine the nice waitress keeps adding more coffee to your cup,
(merges) and you keep adding in a small splash of milk as well (new
RT commits).  As time goes on, you kind of know what is in your coffee,
but you'd have a hard time recreating an identical one from scratch,
and you sure as heck can't take the milk *out* of your old coffee and
move it to a new fresh cup of coffee.

For most people, this is fine - they just want to drink the coffee,
(i.e. RT users) and have no interest in the finer details of exactly
how it was made.  But there are some people who do care, and for us,
what this provides is the identical (line for line) v2.6.33.7.2-rt30
source code, but with a clearer recipe of how it was created.

Speaking more technically, the RT content in the tip git repo was
originally based on 2.6.31, and then the newer kernel.org content
was merged in.  Merge commits are not easy to review/digest, and if
a functional change/addition was embedded in a merge commit, then
you'll have a hard time seeing it at all, unless you explicitly go
looking for it.

So the goal was to have a linear, merge-free set of commits that are
historically faithful to the original changes, but that stack on top
of the current 2.6.33.7 baseline to give you the *exact* same source.

Changes that were "hidden" in merge commits were either re-parented
to an existing changeset, or extracted to be visible stand alone
changesets in their own right -- depending on which made more sense.

The result will be familiar with long time RT users, in that you get
a series file, and a list of patches it applies, and you can use your
tool of choice to apply them (git-am, quilt, git-quiltimport, etc.)

Patches are in a git repo themselves, and you can find them here:

  http://git.kernel.org/?p=linux/kernel/git/paulg/rt-patches.git

If you scan backwards in the repo, you can get a sense of scale of
what it took to (a) extract the original commits, then (b) make those
apply, and then (c) resolve all the deltas between the new tree and
the tip merge based tree. [I think (c) took more then (a)+(b) did!]

Paul.