Fix some spellchecker warnings

Signed-off-by: Guillaume Lambert <guillaume.lambert@orange.com>
Change-Id: Icadc2a6aaaed2c8cc6312ec3d4ee331abfb0a0a3
(cherry picked from commit d1b7686813219d0dc10ff2847d8d83dccdbf9e0d)

diff --git a/docs/release-process/project-release.rst b/docs/release-process/project-release.rst
index 6a6d2e5133ab47f82e24d7eef80b576f01a4b599..3ef92e0af5c2b0efd2084c01b3bfb7e8123683ff 100644 (file)
--- a/docs/release-process/project-release.rst
+++ b/docs/release-process/project-release.rst
@@ -3,7 +3,7 @@ Project Standalone Release
 **************************
 
 This page explains how a project can release independently outside of the
-OpenDaylight simultanious release.
+OpenDaylight simultaneous release.
 
 Preparing your project for release
 ==================================
@@ -17,22 +17,23 @@ methods against the {project-name}-maven-stage-{stream} job:
 This job performs the following duties:
 
 1. Removes -SNAPSHOT from all pom files
-2. Produces a taglist.log, project.patch, and project.bundle files
-3. Runs a `mvn clean deploy` to a local staging repo
-4. Pushes the staging repo to a Nexus staging repo
+2. Produces a ``taglist.log``, project.patch, and project.bundle files
+3. Runs a `mvn clean deploy` to a local staging repository
+4. Pushes the staging repository to a Nexus staging repository
    https://nexus.opendaylight.org/content/repositories/<REPO_ID>
-   (REPO_ID is saved to staging-repo.txt on the log server)
-5. Archives taglist.log, project.patch, and project.bundle files to log server
+   (REPO_ID is saved to ``staging-repo.txt`` on the log server)
+5. Archives ``taglist.log``, project.patch, and project.bundle files to log
+   server
 
-The files taglist.log and project.bundle can be used later at release time to
-reproduce a byte exact commit of what was built by the Jenkins job. This can
-be used to tag the release at release time.
+The files `̀`taglist.log`` and `̀ project.bundle`̀` can be used later at release
+time to reproduce a byte exact commit of what was built by the Jenkins job.
+This can be used to tag the release at release time.
 
 Releasing your project
 ======================
 
-Once testing against the staging repo has been completed and project has
-determined that the staged repo is ready for release. A release can the be
+Once testing against the staging repository has been completed and project has
+determined that the staged repository is ready for release. A release can the be
 performed using the self-serve release process:
 https://docs.releng.linuxfoundation.org/projects/global-jjb/en/latest/jjb/lf-release-jobs.html
 

diff --git a/docs/release-process/release-schedule.rst b/docs/release-process/release-schedule.rst
index c6e195344ebcb1583759df3a9ba57a638c5d4818..7e7ed54c2b796f56a80aa09224649c36ffb304bb 100644 (file)
--- a/docs/release-process/release-schedule.rst
+++ b/docs/release-process/release-schedule.rst
@@ -81,7 +81,7 @@ to release once managed projects are ready.
      - Middle Checkpoint + 4 weeks
      - Start Date +20 weeks
      - Code freeze for all Managed Projects - cut and lock release branch. Only
-       allow blocker bugfixes in release branch.
+       allow blocker bug fixes in release branch.
    * - Final Checkpoint
      - 2021-03-08
      - 2020-08-17

diff --git a/docs/release-process/simultaneous-release.rst b/docs/release-process/simultaneous-release.rst
index ed55e9a219ef3afaad6ace3707f2f46d63c51bdb..76a30e4a731914b3daebda5f226f5844914d380b 100644 (file)
--- a/docs/release-process/simultaneous-release.rst
+++ b/docs/release-process/simultaneous-release.rst
@@ -22,12 +22,12 @@ into the release.
    .. important::
 
       **DO NOT** enable Code-Review+2 and Verified+1 to the
-      Release Engienering Team during code freeze.
+      Release Engineering Team during code freeze.
 
    .. note::
 
       Enable **Exclusive** checkbox for the submit button to override any
-      existing persmissions. Code-Review and Verify permissions are only needed
+      existing permissions. Code-Review and Verify permissions are only needed
       during version bumping.
 
 
@@ -36,7 +36,7 @@ into the release.
 Release Preparations
 ====================
 
-After release candidate is built gpg sign artifacts using the
+After release candidate is built GPG sign artifacts using the
 :doc:`lftools sign <lftools:commands/sign>` command.
 
 .. code-block:: bash
@@ -55,7 +55,7 @@ Verify the distribution-karaf file with the signature.
 
    Projects such as OpFlex participate in the Simultaneous Release but are not
    part of the autorelease build. Ping those projects and prep their staging
-   repos as well.
+   repository as well.
 
 
 Releasing OpenDaylight
@@ -67,10 +67,10 @@ binary and source code on release day.
 Bulleted actions can be performed in parallel while numbered actions should be
 done in sequence.
 
-- Release the Nexus Staging repos
+- Release the Nexus Staging repository
   **(Helpdesk)**
 
-  #. Select both the artifacts and signature repos
+  #. Select both the artifacts and signature repository
      (:ref:`created previously <simrel-preparations>`) and ``click Release``.
 
   #. Enter ``Release OpenDaylight $RELEASE`` for the description and
@@ -101,7 +101,7 @@ done in sequence.
      .. note::
 
         Enable **Exclusive** checkbox for the submit button to override any
-        existing persmissions. Code-Review and Verify permissions are only needed
+        existing permissions. Code-Review and Verify permissions are only needed
         during version bumping. **DO NOT** enable it during code freeze.
 
   #. Merge all patches generated by the job
@@ -188,7 +188,7 @@ done in sequence.
      (eg. |release|-SR1). Skip this step.
 
   For major releases the notes come from the projects themselves in the docs
-  repo via the `docs/releaset-notes/projects` directory.
+  repository via the `docs/releaset-notes/projects` directory.
 
   For service releases (SRs) we need to generate service release notes. This
   can be performed by running the autorelease-generate-release-notes-$STREAM
@@ -208,5 +208,5 @@ done in sequence.
       ./scripts/release-notes-generator.sh ${RELEASE}
 
   A ``release-notes.rst`` will be generated in the working directory. Submit
-  this file as ``release-notes-sr1.rst`` (update the sr as necessary) to the
+  this file as ``release-notes-sr1.rst`` (update the ``sr`` as necessary) to the
   docs project.

diff --git a/docs/spelling_wordlist.txt b/docs/spelling_wordlist.txt
index e2d191c30d566989556f6fcb9d8ae822bd960d4b..4baa547e001b263846326a499f5d0cadfb4eb7aa 100644 (file)
--- a/docs/spelling_wordlist.txt
+++ b/docs/spelling_wordlist.txt
@@ -1,10 +1,34 @@
 ACL
+Autorelease
+autorelease
+abelur
+analytics
+config
+deliverables
+dev
+eg
 Gerrit
 Git
+GPG
+helpdesk
 Jenkins
+Jira
+jamoluhrsen
 Karaf
-releng
+karaf
+lftools
+netvirt
 OpenDaylight
 OpenFlow
+odl
 ovs
 ovsdb
+pre
+reachability
+releng
+rovarga
+TSC
+tsc
+uncheck
+virtualenv
+xml

diff --git a/docs/templates/template-install-guide.rst b/docs/templates/template-install-guide.rst
index 22d2ed6fdafdfbf12a1b1218bfb816ede606edda..160c07dcb95d8ee39b589bf569a7567f024ca15c 100644 (file)
--- a/docs/templates/template-install-guide.rst
+++ b/docs/templates/template-install-guide.rst
@@ -20,7 +20,7 @@ Highlighting  the feature in a different color within the overall
 architecture must help. Include information to describe if the project
 is within ODL installation package or to be installed separately.
 
-Pre Requisites for Installing <Feature>
+Pre-Requisites for Installing <Feature>
 =======================================
 
 * Hardware Requirements
@@ -29,7 +29,7 @@ Pre Requisites for Installing <Feature>
 Preparing for Installation
 ==========================
 
-Include any pre configuration, database, or other software downloads
+Include any pre-configuration, database, or other software downloads
 required to install <feature>.
 
 Installing <Feature>

diff --git a/docs/user-guide/distribution-version-user-guide.rst b/docs/user-guide/distribution-version-user-guide.rst
index 6d63d58822486bfdef3f5ea9c00f8fc687a93f40..49044aeeb1b6857f0bbc22b0231170dbbd89f2e9 100644 (file)
--- a/docs/user-guide/distribution-version-user-guide.rst
+++ b/docs/user-guide/distribution-version-user-guide.rst
@@ -43,7 +43,7 @@ and ``odl-odlparent-version``.
 RESTCONF usage
 ~~~~~~~~~~~~~~
 
-Opendaylight config subsystem NETCONF northbound is not made available just by installing
+OpenDaylight config subsystem NETCONF northbound is not made available just by installing
 ``odl-distribution-version``, but most other feature installations would enable it.
 RESTCONF interfaces are enabled by installing ``odl-restconf`` feature,
 but that do not allow access to config subsystem by itself.

diff --git a/docs/user-guide/neutron-service-user-guide.rst b/docs/user-guide/neutron-service-user-guide.rst
index ad61d73e9a5add5f832d6fec9a6f7cee004673c9..056ccaad7893a2ddedfe549c9ee3e21d51c9cc52 100644 (file)
--- a/docs/user-guide/neutron-service-user-guide.rst
+++ b/docs/user-guide/neutron-service-user-guide.rst
@@ -29,7 +29,7 @@ based policy, VTN, and lisp mapper. For provider configuration, please
 refer to each individual provider’s documentation. Since the Neutron
 service only provides the northbound API for the OpenStack Neutron ML2
 mechanism driver. Without those provider features, the Neutron service
-itself isn’t useful.
+itself is not useful.
 
 Neutron Service feature Architecture
 ------------------------------------
@@ -71,7 +71,7 @@ installing ``odl-neutron-service`` while the controller running
    stabilizes.
 
 ``odl-neutron-service`` provides only a unified interface for OpenStack
-Neutron. It doesn’t provide actual functionality for network
+Neutron. It does not provide actual functionality for network
 virtualization. Refer to each OpenDaylight project documentation for
 actual configuration with OpenStack Neutron.