summaryrefslogtreecommitdiffstats
path: root/docs/manual/patch-policy.txt
diff options
context:
space:
mode:
Diffstat (limited to 'docs/manual/patch-policy.txt')
-rw-r--r--docs/manual/patch-policy.txt46
1 files changed, 23 insertions, 23 deletions
diff --git a/docs/manual/patch-policy.txt b/docs/manual/patch-policy.txt
index 551ea1288..1fdb04ef7 100644
--- a/docs/manual/patch-policy.txt
+++ b/docs/manual/patch-policy.txt
@@ -10,16 +10,16 @@ necessary to patch the source of the software to get it built within
Buildroot.
Buildroot offers an infrastructure to automatically handle this during
-the builds. It support several ways of applying patch sets:
+the builds. It supports several ways of applying patch sets:
-Provinding patches
-~~~~~~~~~~~~~~~~~~
+Providing patches
+~~~~~~~~~~~~~~~~~
-Additionnal tarball
-^^^^^^^^^^^^^^^^^^^
+Additional tarball
+^^^^^^^^^^^^^^^^^^
-If there needs to apply a patch set available as a tarball and
-downloadable, then add the patch tarball to the +<packagename>_PATCH+
+If it is necessary to apply a patch set available as a downloadable
+tarball, then add the patch tarball to the +<packagename>_PATCH+
variable.
Note that the patch tarballs are downloaded from the same site as the
@@ -28,13 +28,13 @@ sources.
Within Buildroot
^^^^^^^^^^^^^^^^
-Most of the patches are provided within Buildroot, in the package
-directory, because they aim to fix cross-compilation, +libc+ support,
-or whatever the reason is.
+Most patches are provided within Buildroot, in the package
+directory; these typically aim to fix cross-compilation, +libc+ support,
+or other such issues.
These patch files should have the extension +*.patch+.
-A +series+ file, like +quilt+ uses it, may also be added in the
+A +series+ file, as used by +quilt+, may also be added in the
package directory. In that case, the +series+ file defines the patch
application order.
@@ -43,7 +43,7 @@ How patches are applied
. Run the +<packagename>_PRE_PATCH_HOOKS+ commands if defined;
-. Cleanup the build directory from any existing +*.rej+ files;
+. Cleanup the build directory, removing any existing +*.rej+ files;
. If +<packagename>_PATCH+ is defined, then patches from these
tarballs are applied;
@@ -65,17 +65,17 @@ If something goes wrong in the steps _3_ or _4_, then the build fails.
Format and licensing of the package patches
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-Patches are released under the same license the software that is
+Patches are released under the same license as the software that is
modified.
-A message explaining what does the patch and why should be add in the
-patch's header.
+A message explaining what the patch does, and why it is needed, should
+be added in the header commentary of the patch.
You should add a +signed-off-by+ statement in the header of the each
-patch to help keeping track of the changes.
+patch to help with keeping track of the changes.
-If the software is under versionning, it is recommended to use the SCM
-software to generate the patch set.
+If the software is under version control, it is recommended to use the
+SCM software to generate the patch set.
Otherwise, concatenate the header with the output of the
+diff -purN source.c.orig source.c+ command.
@@ -107,10 +107,10 @@ AC_PROG_MAKE_SET
Integrating patches found on the Web
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-When integrating a patch whom you are not the author, you have to add
-few things in the header of the patch itself.
+When integrating a patch of which you are not the author, you have to
+add a few things in the header of the patch itself.
-Depending on whether the patch has been pick-up from the project
+Depending on whether the patch has been obtained from the project
repository itself, or from somewhere on the web, add one of the
following tags:
@@ -124,5 +124,5 @@ or
Fetch from: <some url>
---------------
-It is also possible to add few words about the changes that may have
-been necessary if any.
+It is also sensible to add a few words about any changes to the patch
+that may have been necessary.