manuals: reduce verbosity with "worry about" expression

(From yocto-docs rev: 6c65f5f350cdc79a435deb20c48d861d9f4c5c14)

Signed-off-by: Michael Opdenacker <michael.opdenacker@bootlin.com>
Reviewed-by: Quentin Schulz <foss@0leil.net>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

documentation/dev-manual/common-tasks.rst

@@ -1589,7 +1589,7 @@ your software is built:
 
 -  *Autotools:* If your source files have a ``configure.ac`` file, then
    your software is built using Autotools. If this is the case, you just
-   need to worry about modifying the configuration.
+   need to modify the configuration.
 
    When using Autotools, your recipe needs to inherit the
    :ref:`autotools <ref-classes-autotools>` class
@@ -1603,7 +1603,7 @@ your software is built:
 
 -  *CMake:* If your source files have a ``CMakeLists.txt`` file, then
    your software is built using CMake. If this is the case, you just
-   need to worry about modifying the configuration.
+   need to modify the configuration.
 
    When you use CMake, your recipe needs to inherit the
    :ref:`cmake <ref-classes-cmake>` class and your

documentation/kernel-dev/common.rst

@@ -589,8 +589,8 @@ recipe is processed.
 
    In general, however, the Yocto Project maintainers take care of
    moving the ``SRC_URI``-specified configuration options to the
-   kernel's ``meta`` branch. Not only is it easier for BSP developers to
-   not have to worry about putting those configurations in the branch,
+   kernel's ``meta`` branch. Not only is it easier for BSP developers
+   not to have to put those configurations in the branch,
    but having the maintainers do it allows them to apply 'global'
    knowledge about the kinds of common configuration options multiple
    BSPs in the tree are typically using. This allows for promotion of

documentation/ref-manual/classes.rst

@@ -1260,8 +1260,8 @@ The following list shows the tests you can list with the ``WARN_QA`` and
 
    .. note::
 
-      If you are not using runtime package management on your target
-      system, then you do not need to worry about this situation.
+      This is only relevant when you are using runtime package management
+      on your target system.
 
 -  ``xorg-driver-abi:`` Checks that all packages containing Xorg
    drivers have ABI dependencies. The ``xserver-xorg`` recipe provides

documentation/ref-manual/structure.rst

@@ -38,7 +38,7 @@ usually matches the current stable BitBake release from the BitBake
 project. BitBake, a :term:`Metadata` interpreter, reads the
 Yocto Project Metadata and runs the tasks defined by that data. Failures
 are usually caused by errors in your Metadata and not from BitBake
-itself; consequently, most users do not need to worry about BitBake.
+itself.
 
 When you run the ``bitbake`` command, the main BitBake executable (which
 resides in the ``bitbake/bin/`` directory) starts. Sourcing the

documentation/toaster-manual/reference.rst

@@ -32,9 +32,8 @@ through a
 `REST <https://en.wikipedia.org/wiki/Representational_state_transfer>`__
 API, store the information about the layers in the Toaster database, and
 then show the information to users. Users are then able to view that
-information and build layers from Toaster itself without worrying about
-cloning or editing the BitBake layers configuration file
-``bblayers.conf``.
+information and build layers from Toaster itself without having to
+clone or edit the BitBake layers configuration file ``bblayers.conf``.
 
 Tying a layer source into Toaster is convenient when you have many
 custom layers that need to be built on a regular basis by a community of