Address PR comments (2)

Author: vkarak

docs/config_reference.rst

@@ -11,7 +11,7 @@ The full schema describing it can be found in |schemas/config.json|_ file.
 The final configuration for ReFrame is validated against this schema.
 
 The syntax we use to describe the different configuration objects follows the convention: ``OBJECT[.OBJECT]*.PROPERTY``.
-Even if a configuration object contains a list of other object, this is not reflected in the above syntax, as all objects in a certain list are homogeneous.
+Even if a configuration object contains a list of other objects, this is not reflected in the above syntax, as all objects in a certain list are homogeneous.
 For example, by ``systems.partitions.name`` we designate the ``name`` property of any partition object inside the ``partitions`` property of any system object inside the top level ``systems`` object.
 If we were to use indices, that would be rewritten as ``systems[i].partitions[j].name`` where ``i`` indexes the systems and ``j`` indexes the partitions of the i-th system.
 For cases, where the objects in a list are not homogeneous, e.g., the logging handlers, we surround the object type with ``..``.
@@ -25,7 +25,7 @@ Top-level Configuration
 -----------------------
 
 The top-level configuration object is essentially the full configuration of ReFrame.
-It consists of the following properties, which also call conventionally *configuration sections*:
+It consists of the following properties, which we also call conventionally *configuration sections*:
 
 .. py:data:: systems
 
@@ -671,7 +671,7 @@ ReFrame allows you to define custom scheduler resources for each partition that
       ]
 
 
-   A regression test that wants to make use of that resource, it can set its :attr:`~reframe.core.pipeline.RegressionTest.extra_resources` as follows:
+   A regression test that needs to make use of that resource, it can set its :attr:`~reframe.core.pipeline.RegressionTest.extra_resources` as follows:
 
    .. code:: python
 
@@ -916,7 +916,7 @@ You may define different logger objects per system but *not* per partition.
    :default: ``["*"]``
 
    A list of systems or system/partitions combinations that this logging configuration is valid for.
-   For a detailed description of this property, you may refer `here <#environments.target_systems>`__.
+   For a detailed description of this property, have a look at the :attr:`~environments.target_systems` definition for environments.
 
 
 
@@ -1393,7 +1393,7 @@ The options of an execution mode will be passed to ReFrame as if they were speci
    :default: ``["*"]``
 
    A list of systems *only* that this execution mode is valid for.
-   For a detailed description of this property, you may refer `here <#environments.target_systems>`__.
+   For a detailed description of this property, have a look at the :attr:`~environments.target_systems` definition for environments.
 
 
 General Configuration
@@ -1640,7 +1640,7 @@ General Configuration
    :default: ``["*"]``
 
    A list of systems or system/partitions combinations that these general options are valid for.
-   For a detailed description of this property, you may refer `here <#environments.target_systems>`__.
+   For a detailed description of this property, have a look at the :attr:`~environments.target_systems` definition for environments.
 
 
 .. py:attribute:: general.timestamp_dirs

docs/tutorial_advanced.rst

@@ -725,7 +725,7 @@ First, we need to enable the container platform support in ReFrame's configurati
    :end-before: # rfmdocend: containers
    :emphasize-lines: 9-18
 
-For each partition, users can define a list of container platforms supported using the :attr:`~config.systems.partitions.container_platforms` configuration parameter.
+For each partition, users can define a list of all supported container platforms using the :attr:`~config.systems.partitions.container_platforms` configuration parameter.
 In this case, we define the `Sarus <https://github.com/eth-cscs/sarus>`__ platform for which we set the :attr:`~config.systems.partitions.container_platforms.modules` parameter in order to instruct ReFrame to load the ``sarus`` module, whenever it needs to run with this container platform.
 Similarly, we add an entry for the `Singularity <https://sylabs.io>`__ platform.
 Optionally, users are allowed to set the ``default`` attribute to :obj:`True` in order to mark a specific container platform as the default of that partition (see below on how this information is being used).

docs/whats_new_40.rst

@@ -6,7 +6,7 @@ It also introduces a couple of new deprecations.
 
 ReFrame 4.0 maintains backward compatibility as much as possible.
 Existing 3.x configurations and 3.x tests are expected to run out-of-the-box, despite any warnings issued.
-Framework's behavior with respect to performance logging has also changed, but configuration options are offered so that users can switch to the old behavior.
+The framework's behavior with respect to performance logging has also changed, but configuration options are offered so that users can switch to the old behavior.
 
 This page summarizes the key changes in ReFrame 4.0 and what users should pay attention to.
 
@@ -27,8 +27,8 @@ This can also be very useful if you maintain a ReFrame installation used by othe
 To assist with system-wide installation the ``RFM_CONFIG_PATH`` environment variable is introduced that allows you to specify a path where ReFrame will look for configuration files to load.
 
 Now that systems and environments definitions can be distributed over multiple configuration files, it can become easy to accidentally redefine a system or environment without a notice.
-For this reason, ReFrame warns you if a system or an environment are redefined in the same scope.
-Since in the past all configuration files where extended copies of the builtin, you will get warnings that the ``generic`` system and the ``builtin`` environment are redefined, as ReFrame finds them in the builtin configuration, which is always loaded.
+For this reason, ReFrame warns you if a system or an environment is redefined in the same scope.
+Since in the past all configuration files where extended copies of the builtin configuration, you will get warnings that the ``generic`` system and the ``builtin`` environment are redefined, as ReFrame finds them in the builtin configuration, which is always loaded.
 You can safely ignore these warnings and use the definitions in your configuration file.
 If you want to eliminate them, though, you should remove the conflicting definitions from your configuration file.