1 files changed, 18 insertions, 57 deletions

diff --git a/documentation/dev-manual/dev-manual-model.xml b/documentation/dev-manual/dev-manual-model.xml
index bd6a85b987..05ff369f5d 100644
--- a/documentation/dev-manual/dev-manual-model.xml
+++ b/documentation/dev-manual/dev-manual-model.xml
@@ -86,67 +86,26 @@
             <title>Kernel Overview</title>
 
             <para>
-                The kernels are maintained using the Git revision control system
-                that structures them using the familiar "tree", "branch", and "leaf" scheme.
-                Branches represent diversions from general code to more specific code, while leaves
-                represent the end-points for a complete and unique kernel whose source files,
-                when gathered from the root of the tree to the leaf, accumulate to create the files
-                necessary for a specific piece of hardware and its features.
-                The following figure displays this concept:
-            <para>
-                <imagedata fileref="figures/kernel-overview-1.png"
-                    width="6in" depth="6in" align="center" scale="100" />
-            </para>
-
-            <para>
-                Within the figure, the "Kernel.org Branch Point" represents the point in the tree
-                where a supported base kernel is modified from the Linux kernel.
-                For example, this could be the branch point for the <filename>linux-yocto-3.19</filename>
-                kernel.
-                Thus, everything further to the right in the structure is based on the
-                <filename>linux-yocto-3.19</filename> kernel.
-                Branch points to the right in the figure represent where the
-                <filename>linux-yocto-3.19</filename> kernel is modified for specific hardware
-                or types of kernels, such as real-time kernels.
-                Each leaf thus represents the end-point for a kernel designed to run on a specific
-                targeted device.
-            </para>
-
-            <para>
-                The overall result is a Git-maintained repository from which all the supported
-                kernel types can be derived for all the supported devices.
-                A big advantage to this scheme is the sharing of common features by keeping them in
-                "larger" branches within the tree.
-                This practice eliminates redundant storage of similar features shared among kernels.
-            </para>
-
-            <note>
-                Keep in mind the figure does not take into account all the supported Yocto
-                Project kernel types, but rather shows a single generic kernel just for conceptual purposes.
-                Also keep in mind that this structure represents the Yocto Project source repositories
-                that are either pulled from during the build or established on the host development system
-                prior to the build by either cloning a particular kernel's Git repository or by
-                downloading and unpacking a tarball.
-            </note>
-
-            <para>
-                Upstream storage of all the available kernel source code is one thing, while
-                representing and using the code on your host development system is another.
-                Conceptually, you can think of the kernel source repositories as all the
-                source files necessary for all the supported kernels.
-                As a developer, you are just interested in the source files for the kernel on
-                which you are working.
+                Upstream storage of all the available kernel source code is
+                one thing, while representing and using the code on your host
+                development system is another.
+                Conceptually, you can think of the kernel source repositories
+                as all the source files necessary for all the supported
+                Yocto Linux kernels.
+                As a developer, you are just interested in the source files
+                for the kernel on which you are working.
                 And, furthermore, you need them available on your host system.
             </para>
 
             <para>
-                Kernel source code is available on your host system a couple of different
-                ways.
-                If you are working in the kernel all the time, you probably would want
-                to set up your own local Git repository of the kernel tree.
-                If you just need to make some patches to the kernel, you can access
-                temporary kernel source files that were extracted and used
-                during a build.
+                Kernel source code is available on your host system a couple
+                of different ways.
+                If you are working in the kernel all the time, you probably
+                would want to set up your own local Git repository of the
+                Yocto Linux kernel tree.
+                If you just need to make some patches to the kernel, you can
+                access temporary kernel source files that were extracted and
+                used during a build.
                 We will just talk about working with the temporary source code.
                 For more information on how to get kernel source code onto your
                 host system, see the
@@ -164,6 +123,8 @@
                 Thus, in a sense, the process constructs a local source tree specific to your
                 kernel to generate the new kernel image - a source generator if you will.
             </para>
+
+            <para>
                 The following figure shows the temporary file structure
                 created on your host system when the build occurs.
                 This