From b3c8e3f380e82b64a43ee12f85b5dce08f1bcaa4 Mon Sep 17 00:00:00 2001 From: Guillaume Lambert Date: Tue, 1 Jun 2021 20:02:13 +0200 Subject: [PATCH] Fix more spellchecker warnings Signed-off-by: Guillaume Lambert Change-Id: Ie11a9fe46ac3fb267a994062dd99d95a190c02a4 (cherry picked from commit 8d1bac9b58b814359a3e21415220269468485718) --- docs/release-notes/projects/serviceutils.rst | 2 +- docs/release-notes/sample-release-notes.rst | 2 +- docs/release-notes/upgrade-process.rst | 33 +++++----- docs/release-process/autorelease.rst | 29 ++++---- docs/release-process/branch-cutting.rst | 26 ++++---- .../identifying-managed-projects.rst | 6 +- docs/release-process/managed-release.rst | 66 +++++++++++-------- docs/release-process/project-lifecycle.rst | 14 ++-- docs/spelling_wordlist.txt | 28 +++++++- .../distribution-version-user-guide.rst | 2 +- 10 files changed, 124 insertions(+), 84 deletions(-) diff --git a/docs/release-notes/projects/serviceutils.rst b/docs/release-notes/projects/serviceutils.rst index c55113a0e..fd4910826 100644 --- a/docs/release-notes/projects/serviceutils.rst +++ b/docs/release-notes/projects/serviceutils.rst @@ -47,4 +47,4 @@ Known Issues Here is the link to the known issues exist in this release: -`OpenDaylight JIRA Tickets - Known Issue `_ \ No newline at end of file +`OpenDaylight JIRA Tickets - Known Issue `_ diff --git a/docs/release-notes/sample-release-notes.rst b/docs/release-notes/sample-release-notes.rst index ccfee6c78..d5a4792de 100644 --- a/docs/release-notes/sample-release-notes.rst +++ b/docs/release-notes/sample-release-notes.rst @@ -45,7 +45,7 @@ This release provides the following new features: .. note:: this could be a karaf feature or new functionality made available - as a new implementation of an already exisiting karaf feature. + as a new implementation of an already existing karaf feature. Deprecated Features =================== diff --git a/docs/release-notes/upgrade-process.rst b/docs/release-notes/upgrade-process.rst index aa9385865..c08e86ef3 100644 --- a/docs/release-notes/upgrade-process.rst +++ b/docs/release-notes/upgrade-process.rst @@ -15,7 +15,7 @@ Preparation JDK 11 Version ^^^^^^^^^^^^^^ Silicon requires Java 11, both during compile-time and run-time. -Make sure to install JDK 11 corresponding to at least openjdk-11.0.8, +Make sure to install JDK 11 corresponding to at least ``openjdk-11.0.8``, and that the JAVA_HOME environment variable points to the JDK directory. InfraUtils is a MRI project @@ -34,7 +34,7 @@ versions (for example, `bump-odl-version " and -"\" sections (please adjust accordingly). +some of the artifacts from the Nexus repository you may need to modify your +``settings.xml`` to include the staging repository URL as this URL is not part +of OpenDaylight Nexus' public or snapshot groups. +If you've already cloned the recommended settings.xml for building ODL you will +need to add an additional profile and activate it by adding these sections to +the ``\`` and ``\`` sections +(please adjust accordingly). .. note:: * This is an example and you need to "Add" these example sections to your - settings.xml do not delete your existing sections. - * The URLs in the \ and \ sections will also - need to be updated with the staging repo you want to test. + ``settings.xml`` do not delete your existing sections. + * The URLs in the ``\`` and ``\`` sections + will also need to be updated with the staging repository you want to test. .. code-block:: xml diff --git a/docs/release-process/branch-cutting.rst b/docs/release-process/branch-cutting.rst index 517d04dd1..6fc251067 100644 --- a/docs/release-process/branch-cutting.rst +++ b/docs/release-process/branch-cutting.rst @@ -60,12 +60,14 @@ JJB (releng/builder) stream: silicon branch: stable/silicon -#. Review and submit the changes to releng/builder project. **(releng/builder committers)** +#. Review and submit the changes to releng/builder project. + **(releng/builder committers)** Autorelease ----------- -#. Block submit permissions for registered users and elevate RE's committer rights on gerrit. +#. Block submit permissions for registered users and elevate RE's committer + rights on Gerrit. **(Helpdesk)** .. figure:: images/gerrit-update-committer-rights.png @@ -74,7 +76,8 @@ Autorelease Enable **Exclusive** checkbox for the submit button to override any existing permissions. -#. Enable create reference permissions on gerrit for RE's to submit .gitreview patches. +#. Enable create reference permissions on Gerrit for RE's to submit + ``.gitreview`` patches. **(Helpdesk)** .. figure:: images/gerrit-update-create-reference.png @@ -85,10 +88,10 @@ Autorelease #. Start the branch cut job or use the manual steps below for branch cutting autorelease. **(Release Engineering Team)** #. Start the version bump job or use the manual steps below for version bump autorelease. **(Release Engineering Team)** -#. Merge all .gitreview patches submitted though the job or manually. **(Release Engineering Team)** -#. Remove create reference permissions set on gerrit for RE's. **(Helpdesk)** +#. Merge all ``.gitreview`` patches submitted though the job or manually. **(Release Engineering Team)** +#. Remove create reference permissions set on Gerrit for RE's. **(Helpdesk)** #. Merge all version bump patches in the order of dependencies. **(Release Engineering Team)** -#. Re-enable submit permissions for registered users and disable elevated RE committer rights on gerrit. **(Helpdesk)** +#. Re-enable submit permissions for registered users and disable elevated RE committer rights on Gerrit. **(Helpdesk)** #. Notify release list on branch cutting work completion. **(Release Engineering Team)** @@ -102,7 +105,7 @@ Branch cutting can be performed either through the job or manually. Manual steps to branch cut (Autorelease) ---------------------------------------- -#. Setup releng/autorelease repository. +#. Setup ``releng/autorelease`` repository. **(Release Engineering Team)** .. code-block:: bash @@ -114,7 +117,8 @@ Manual steps to branch cut (Autorelease) git pull --rebase git submodule foreach 'git pull --rebase' -#. Enable create reference permissions on gerrit for RE's to submit .gitreview patches. +#. Enable create reference permissions on Gerrit for RE's to submit + ``.gitreview`` patches. **(Helpdesk)** .. figure:: images/gerrit-update-create-reference.png @@ -123,7 +127,7 @@ Manual steps to branch cut (Autorelease) Enable Exclusive check-box override any existing permissions. -#. Create stable/${CURR_RELEASE} branches based on HEAD master. +#. Create ``stable/${CURR_RELEASE}`` branches based on HEAD master. **(Release Engineering Team)** .. code-block:: bash @@ -133,7 +137,7 @@ Manual steps to branch cut (Autorelease) git push gerrit stable/${CURR_RELEASE,,} git submodule foreach 'git push gerrit stable/${CURR_RELEASE,,}' -#. Contribute .gitreview updates to stable/${CURR_RELEASE,,}. +#. Contribute ``.gitreview`` updates to ``stable/${CURR_RELEASE,,}``. **(Release Engineering Team)** .. code-block:: bash @@ -177,7 +181,7 @@ Manual steps to version bump (Autorelease) git checkout pom.xml scripts/ -#. Push version bump master changes to gerrit. **(Release Engineering Team)** +#. Push version bump master changes to Gerrit. **(Release Engineering Team)** .. code-block:: bash diff --git a/docs/release-process/identifying-managed-projects.rst b/docs/release-process/identifying-managed-projects.rst index 292a7f68c..60747950c 100644 --- a/docs/release-process/identifying-managed-projects.rst +++ b/docs/release-process/identifying-managed-projects.rst @@ -30,9 +30,9 @@ independently on top of the Managed Distribution later. Finding the Managed Projects given a Managed Distribution ========================================================= -Given a Managed Distribution (tar.gz, .zip, RPM, Deb), the Managed Projects -that constitute it can be found in the `taglist.log` file in the root of the -archive. +Given a Managed Distribution (``.tar.gz``, ``.zip``, RPM, Deb), the Managed +Projects that constitute it can be found in the `taglist.log` file in the root +of the archive. `taglist.log` files are of the format: diff --git a/docs/release-process/managed-release.rst b/docs/release-process/managed-release.rst index 084cf49e5..fc9f63ef0 100644 --- a/docs/release-process/managed-release.rst +++ b/docs/release-process/managed-release.rst @@ -203,7 +203,7 @@ release notes for each release. CLM +++ -Managed Projects are required to handle CLM (Component Lifecycle Management) +Managed Projects are required to handle CLM (Component Life-cycle Management) violations in a timely manner. Managed Release Process @@ -395,9 +395,10 @@ The remaining artifacts will be automatically scraped: Midway Checkpoint ################# -One month before code freeze, a midway checkpoint will be collected. The release team -will review the information collected and report it to the TSC at the next TSC -meeting. All information for midway checkpoint will be automatically collected. +One month before code freeze, a midway checkpoint will be collected. +The release team will review the information collected and report it to the TSC +at the next TSC meeting. +All information for midway checkpoint will be automatically collected. * Open Jira bugs marked as blockers. * Open Jira issues tracking weather items. @@ -412,8 +413,8 @@ this information more frequently, to provide trends over time. Final Checkpoint ################ -At 2 weeks after code freeze a final checkpoint will be collected by the release team -and presented to the TSC at the next TSC meeting. +At 2 weeks after code freeze a final checkpoint will be collected by the release +team and presented to the TSC at the next TSC meeting. Projects will need to create the following artifacts: @@ -506,7 +507,7 @@ staff to temporarily wield committer rights and merge version bump patches. The TSC vote at any time to back out of a version bump if the new releases are found to be unsuitable. -MRI Projects are expected to provide bugfixes via minor or patch version +MRI Projects are expected to provide bug fixes via minor or patch version updates during the release, but should strive to not expect MSI Projects to consume another major version update during the release. @@ -593,10 +594,11 @@ Add to Common Distribution In order to be included in the formal (major or service) release distribution, Self-Managed Projects must be in the common distribution pom.xml file and the -distribution sanity test (see :ref:`add-proj-dist`) no later than one week before -the first Managed release candidate (RC) is created. Projects should only be added -to the final distribution pom.xml after they have succesfully published artifacts -using upstream SNAPSHOTs. See `Use of SNAPSHOT versions`_. +distribution sanity test (see :ref:`add-proj-dist`) no later than one week +before the first Managed release candidate (RC) is created. +Projects should only be added to the final distribution pom.xml after they have +successfully published artifacts using upstream SNAPSHOTs. +See `Use of SNAPSHOT versions`_. .. note:: It is very important Self-Managed projects do not miss the deadlines for upstream integration and final distribution check, otherwise there are @@ -608,20 +610,22 @@ Cut Stable Branch Self-Managed projects wanting to use the existing release job to release their artifacts (see `Release the project artifacts`_) must have an stable branch in -the major release (fluorine, neon, etc) they are targeting. It is highly recommended -to cut the stable branch before the first Managed release candidate (RC) is created. +the major release (fluorine, neon, etc) they are targeting. +It is highly recommended to cut the stable branch before the first Managed +release candidate (RC) is created. After creating the stable branch Self-Managed projects should: -* Bump master branch version to X.Y+1.0-SNAPSHOT, this way any new merge in master - will not interfere with the new created stable branch artifacts. +* Bump master branch version to X.Y+1.0-SNAPSHOT, this way any new merge in + master will not interfere with the new created stable branch artifacts. -* Update .gitreview for stable branch: change defaultbranch=master to stable branch. - This way folks running "git review" will get the right branch. +* Update ``.gitreview`` for stable branch: change ``defaultbranch=master`` to + stable branch. This way folks running "git review" will get the right branch. -* Update their jenkins jobs: current release should point to the new created stable - branch and next release should point to master branch. If you do not know how to - do this please open a ticket to opendaylight helpdesk. +* Update their jenkins jobs: current release should point to the new created + stable branch and next release should point to master branch. + If you do not know how to do this please open a ticket to OpenDaylight + helpdesk. Release the project artifacts +++++++++++++++++++++++++++++ @@ -652,9 +656,10 @@ Moving a Project from Managed to Self-Managed --------------------------------------------- Managed Projects that are not required for dependency reasons can submit a -**Project_Plan** issue to be Self-Managed to the TSC project in Jira. See details -in the `Initial Checkpoint`_ section above. Requests should be submitted before -the start of a release. Requests will be evaluated by the TSC. +**Project_Plan** issue to be Self-Managed to the TSC project in Jira. +See details in the `Initial Checkpoint`_ section above. +Requests should be submitted before the start of a release. +Requests will be evaluated by the TSC. The TSC may withdraw a project from the Managed Release at any time. @@ -663,17 +668,20 @@ Installing Features from Self-Managed Projects Self-Managed Projects will have their artifacts included in the final release if they are available on-time, but they will not be available to be installed -until the user does a repo:add. +until the user does a `̀ repo:add``. To install an Self-Managed Project feature, find the feature description in the system directory. For example, NetVirt's main feature: -system/org/opendaylight/netvirt/odl-netvirt-openstack/0.6.0-SNAPSHOT/ +.. code-block:: none -Then use the Karaf shell to repo:add the feature: + system/org/opendaylight/netvirt/odl-netvirt-openstack/0.6.0-SNAPSHOT/ -feature:repo-add mvn:org.opendaylight.netvirt/odl-netvirt-openstack/0.6.0 --SNAPSHOT/xml/features +Then use the Karaf shell to ``repo:add`` the feature: + +.. code-block:: none + + feature:repo-add mvn:org.opendaylight.netvirt/odl-netvirt-openstack/0.6.0-SNAPSHOT/xml/features Grievances ========== @@ -719,7 +727,7 @@ Vocabulary Reference * Self-Managed Project: A project not taking part in the Managed Release Process. * Simultaneous Release: Event wherein all Snapshot Integrated Project versions - are rewriten to release versions and release artifacts are produced. + are rewritten to release versions and release artifacts are produced. * Snapshot Integrated Project: Project that integrates with OpenDaylight projects using snapshot version numbers. These projects release together in the Simultaneous Release. diff --git a/docs/release-process/project-lifecycle.rst b/docs/release-process/project-lifecycle.rst index 9b85345ca..260fb8c49 100644 --- a/docs/release-process/project-lifecycle.rst +++ b/docs/release-process/project-lifecycle.rst @@ -1,6 +1,6 @@ -***************** -Project lifecycle -***************** +****************** +Project life-cycle +****************** This page documents the current rules to follow when adding and removing a particular project to Simultaneous Release (SR). @@ -15,8 +15,8 @@ progress to the following state. The project is not recognized by Technical Steering Committee (TSC) to be part of OpenDaylight (ODL). - **non-participating** - The project is recognized byt TSC to be an ODL project, but the project has - not confirmed participation in SR for given release cycle. + The project is recognized by the TSC to be an ODL project, but the + project has not confirmed participation in SR for given release cycle. - **non-building** The recognized project is willing to participate, but its current codebase is not passing its own merge job, or the project artifacts are otherwise @@ -29,7 +29,7 @@ progress to the following state. but autorelease build fails when building project's artifact. Temporary state, timing out into not-in-autorelease. - **repo-not-in-integration** - Project is succesfully built within autorelease, but integration/distribution:features-index + Project is successfully built within autorelease, but integration/distribution:features-index is not listing all its public feature repositories. - **feature-not-in-integration** Feature repositories are referenced, distribution-check job is passing, @@ -59,7 +59,7 @@ progress to the following state. .. todo:: - - Add links to documents concerning project lifecycle from TSC point of view. + - Add links to documents concerning project life-cycle from TSC point of view. - Add links to M# templates, test requirements and other relevant info. - Mention other jobs involved in verification (verify, validate-autorelease, ... releng-check-poms). - Add back-references to this document (from integration/distribution, job definition templates, ...). diff --git a/docs/spelling_wordlist.txt b/docs/spelling_wordlist.txt index 4baa547e0..c2de4f184 100644 --- a/docs/spelling_wordlist.txt +++ b/docs/spelling_wordlist.txt @@ -1,34 +1,60 @@ ACL +Akka +Aluminium Autorelease +augmentable autorelease +aaa abelur +akka analytics +BigInteger +codebase config +Disruptor +datastores deliverables dev eg Gerrit Git GPG +hardcoded helpdesk +ietf +infrautils Jenkins Jira jamoluhrsen Karaf karaf lftools +Magnesium +mdsal +muxponders netvirt +netconf OpenDaylight OpenFlow -odl +OpenStack +odlparent ovs ovsdb pre reachability +reconfigurable +reimplemented releng +renderer rovarga +submodule +switchponders +TCP TSC +todo tsc uncheck +vTEP virtualenv +yangtools xml diff --git a/docs/user-guide/distribution-version-user-guide.rst b/docs/user-guide/distribution-version-user-guide.rst index 49044aeeb..ea2f943f3 100644 --- a/docs/user-guide/distribution-version-user-guide.rst +++ b/docs/user-guide/distribution-version-user-guide.rst @@ -17,7 +17,7 @@ and which workarounds to apply, such user would need to know the exact version of at least one OpenDaylight component. There are indirect ways to deduce such version, but the direct way is enabled -by odl-distribution-version feature. Administrator can specify version strings, +by ``odl-distribution-version`` feature. Administrator can specify version strings, which would be available to users via NETCONF, or via RESTCONF if OpenDaylight is configured to initiate NETCONF connection to its config subsystem northbound interface. -- 2.36.6