]> xenbits.xensource.com Git - people/larsk/xen-release-scripts.git/commitdiff
Fixed typos
authorLars Kurth <lars.kurth@citrix.com>
Wed, 19 Jul 2017 15:59:14 +0000 (16:59 +0100)
committerLars Kurth <lars.kurth@citrix.com>
Wed, 19 Jul 2017 15:59:14 +0000 (16:59 +0100)
README

diff --git a/README b/README
index e7152c886ac1875c32108a5608d2b7316497358a..ac48dff17712a521fb9c67318bb10201185a3359 100644 (file)
--- a/README
+++ b/README
@@ -12,8 +12,8 @@ To keep things clean, I use the following directory structure
     - xsa-lists            [output/input directory, see steps 1-5 in match-xsa]
     - xsa                  [git repo, optional]
 
-Prerequisitess
---------------
+Prerequisites
+-------------
 match-xsa and xen-release-logs, require perl and the following perl libraries
 
     libfile-slurp-perl  
@@ -46,8 +46,8 @@ This document is written for specific users
 * Security Team Members
 * Release Managers and Release Maintainers
 
-Logiles and --version, --major, --since, --until and --logroot
---------------------------------------------------------------
+Logfiles, --version, --major, --since, --until and --logroot
+------------------------------------------------------------
 
 The tools xen-release-logs, match-xsa and make-webpage use the following common options: 
 --version, --major, --since, --until and --logroot
@@ -88,10 +88,10 @@ The log directory is called logs-470-4.
 
 Developers and Users
 --------------------
-For developers and users only the match-xsa tool is useful. However, the tool requries some 
+For developers and users only the match-xsa tool is useful. However, the tool requires some 
 input files, which currently can only be generated by security team members. 
 
-Create the following directies
+Create the following directories
     - xen-release-logs     [output/input directory]
     - xen-release-scripts  [check out this repo]
     - xsa-lists            [save XSA list files in this directory]
@@ -117,10 +117,11 @@ apply (e.g. the XSA may apply to Linux or older Xen releases only): you will hav
 double check the XSA, which can be easily accessed from within the 
 
 *STEP 5:* run the tool in smart mode, which checks against real patches rather then commit
-message titles. Note that this check is mor efragile and can throw up false positives in the
+message titles. Note that this check is morfragile and can throw up false positives in the
 following situations:
-* The committer has made changes to the patch when commiting (this may be a real issue)
-* The *.patch file in the XSA has been created by a different diff vewrsion and file things 
+* A wrong patch has been applied
+* The committer has made changes to the patch when committing (this may be a real issue)
+* The *.patch file in the XSA has been created by a different diff version and file thunks 
 are ordered differently (this is a tool issue that needs to be fixed).
 
     ./match-xsa --version 4 --major 8 --since 1 --xsa ../xsa-lists/xsa-213-225
@@ -144,7 +145,7 @@ xenbits.xenproject.org/xsa, you are done. If there are you can do the following.
 In this mode, git diffs, patches and logs are saved in a debug directory in the log directory 
 and are accessible from the generated html (via a DEBUG link). You can look at these to 
 investigate issues. Let's say a xen patch has been matched by commit message, the following 
-files will be getenerated:
+files will be generated:
 
 * xen-git.txt : this is the original patch from git show
 * xen-patch.txt : this is the matching patch from xenbits.xenproject.org/xsa 
@@ -160,7 +161,7 @@ Security Team Members
 ---------------------
 
 In addition to the regular workflow as outlined in the previous section, security team members 
-have the capabilit to use match-xsa on xsa.git (only accessible for security team members).
+have the capability to use match-xsa on xsa.git (only accessible for security team members).
 
 To do this use