sphinx: import docs

The Yocto Project docs was migrated from Docbook to Sphinx in YP
 3.2. This 3.1 is an LTS release, and since 3.1 docs are 'close to'
 the docs in 3.2, we agreed to backport sphinx docs onto 3.1.

This first patch brings all changes done in 3.2 until:
7f64574f7 README: include detailed information about sphinx

There are other changes after this commit, but they will be
 selectively backported in individual patches.

This patch was generated with the following command:

git cherry-pick -n \
 $(git log --reverse --oneline \
 ac352ad7f95db7eeacb53c2778caa31800bd7c26..7f64574f7 \
| cut -f1 -d' ')

The following commits were applies in the dunfell docs, but not in
master, so they were first reverted (and squashed into this change). A
commit will reintroduce the content from these patches in the Sphinx
files in a followup patch.

069c27574 Documenation: Prepared for the 3.1.1 release
bd140f0f9 Documentation: Add 3.1.1 version updates missing from previous commit
17cc71a8f Documenation: Prepared for the 3.1.2 release
1a69e2c02 Documenation: Prepared for the 3.1.3 release
8910ac1c7 Documenation: Prepared for the 3.1.4 release

(From yocto-docs rev: c25fe058b88b893b0d146f3ed27320b47cdec236)

Signed-off-by: Nicolas Dechesne <nicolas.dechesne@linaro.org>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

1 files changed, 54 insertions, 0 deletions

diff --git a/documentation/ref-manual/migration-general.rst b/documentation/ref-manual/migration-general.rst
new file mode 100644
index 0000000000..182482ec43
--- /dev/null
+++ b/documentation/ref-manual/migration-general.rst
@@ -0,0 +1,54 @@
+General Migration Considerations
+================================
+
+Some considerations are not tied to a specific Yocto Project release.
+This section presents information you should consider when migrating to
+any new Yocto Project release.
+
+-  *Dealing with Customized Recipes*:
+
+   Issues could arise if you take
+   older recipes that contain customizations and simply copy them
+   forward expecting them to work after you migrate to new Yocto Project
+   metadata. For example, suppose you have a recipe in your layer that
+   is a customized version of a core recipe copied from the earlier
+   release, rather than through the use of an append file. When you
+   migrate to a newer version of Yocto Project, the metadata (e.g.
+   perhaps an include file used by the recipe) could have changed in a
+   way that would break the build. Say, for example, a function is
+   removed from an include file and the customized recipe tries to call
+   that function.
+
+   You could "forward-port" all your customizations in your recipe so
+   that everything works for the new release. However, this is not the
+   optimal solution as you would have to repeat this process with each
+   new release if changes occur that give rise to problems.
+
+   The better solution (where practical) is to use append files
+   (``*.bbappend``) to capture any customizations you want to make to a
+   recipe. Doing so, isolates your changes from the main recipe making
+   them much more manageable. However, sometimes it is not practical to
+   use an append file. A good example of this is when introducing a
+   newer or older version of a recipe in another layer.
+
+-  *Updating Append Files*:
+
+   Since append files generally only contain
+   your customizations, they often do not need to be adjusted for new
+   releases. However, if the ``.bbappend`` file is specific to a
+   particular version of the recipe (i.e. its name does not use the %
+   wildcard) and the version of the recipe to which it is appending has
+   changed, then you will at a minimum need to rename the append file to
+   match the name of the recipe file. A mismatch between an append file
+   and its corresponding recipe file (``.bb``) will trigger an error
+   during parsing.
+
+   Depending on the type of customization the append file applies, other
+   incompatibilities might occur when you upgrade. For example, if your
+   append file applies a patch and the recipe to which it is appending
+   is updated to a newer version, the patch might no longer apply. If
+   this is the case and assuming the patch is still needed, you must
+   modify the patch file so that it does apply.
+
+
+