This is an automated email from the ASF dual-hosted git repository.
kou pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/arrow.git
The following commit(s) were added to refs/heads/main by this push:
new e2a5b4e902 MINOR: [Docs] Fix typos in rst files (#46335)
e2a5b4e902 is described below
commit e2a5b4e90243c8b677218fa2f7d8cb483fb3a840
Author: omahs <[email protected]>
AuthorDate: Fri May 9 07:09:07 2025 +0200
MINOR: [Docs] Fix typos in rst files (#46335)
### Rationale for this change
Improving docs by removing typos
### What changes are included in this PR?
Fix typos in rst files
### Are these changes tested?
Documentation-only changes
### Are there any user-facing changes?
Documentation-only changes
Authored-by: omahs <[email protected]>
Signed-off-by: Sutou Kouhei <[email protected]>
---
docs/source/cpp/env_vars.rst | 2 +-
docs/source/developers/benchmarks.rst | 6 +++---
docs/source/developers/bug_reports.rst | 2 +-
docs/source/developers/continuous_integration/overview.rst | 6 +++---
docs/source/developers/python.rst | 2 +-
docs/source/developers/release.rst | 6 +++---
docs/source/format/DissociatedIPC.rst | 2 +-
7 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/docs/source/cpp/env_vars.rst b/docs/source/cpp/env_vars.rst
index 6a8a022548..20df98c5ec 100644
--- a/docs/source/cpp/env_vars.rst
+++ b/docs/source/cpp/env_vars.rst
@@ -145,7 +145,7 @@ that changing their value later will have an effect.
By default, Arrow C++ detects the capabilities of the current CPU at runtime
and chooses the best execution paths based on that information. This
- behavior can be overriden by setting this environment variable to a
+ behavior can be overridden by setting this environment variable to a
well-defined value. Supported values are:
- ``NONE`` disables any runtime-selected SIMD optimization;
diff --git a/docs/source/developers/benchmarks.rst
b/docs/source/developers/benchmarks.rst
index aec3d1d65b..ce1b993e26 100644
--- a/docs/source/developers/benchmarks.rst
+++ b/docs/source/developers/benchmarks.rst
@@ -159,9 +159,9 @@ Writing a benchmark
By contrast to realtime which is the wall clock time, e.g. the difference
between end_time - start_time. In a single thread model, the cputime is
preferable since it is less affected by context switching. In a multi thread
- scenario, the cputime will give incorrect result since the since it'll
- be inflated by the number of threads and can be far off realtime. Thus, if
- the benchmark is multi threaded, it might be better to use
+ scenario, the cputime will give incorrect result since it'll be inflated by
+ the number of threads and can be far off realtime. Thus, if the benchmark is
+ multi threaded, it might be better to use
``SetRealtime()``, see this `example
<https://github.com/apache/arrow/blob/a9582ea6ab2db055656809a2c579165fe6a811ba/cpp/src/arrow/io/memory-benchmark.cc#L223-L227>`_.
Scripting
diff --git a/docs/source/developers/bug_reports.rst
b/docs/source/developers/bug_reports.rst
index 4dbb39136c..07445de2bb 100644
--- a/docs/source/developers/bug_reports.rst
+++ b/docs/source/developers/bug_reports.rst
@@ -200,7 +200,7 @@ reached a terminal status, it is closed with one of two
outcomes:
If you are merging a PR it is good practice to add a comment
to the linked issue about which PR is resolving it. This way
- GitHub crates a notification for anybody that collaborated on
+ GitHub creates a notification for anybody that collaborated on
the issue.
* **closed as not planned** - indicates the issue is closed and should
diff --git a/docs/source/developers/continuous_integration/overview.rst
b/docs/source/developers/continuous_integration/overview.rst
index 9d39c90cfd..59dde1e68e 100644
--- a/docs/source/developers/continuous_integration/overview.rst
+++ b/docs/source/developers/continuous_integration/overview.rst
@@ -24,11 +24,11 @@ Continuous Integration for Arrow is fairly complex as it
needs to run across dif
Some files central to Arrow CI are:
-- ``docker-compose.yml`` - here we define docker services which can be
configured using either enviroment variables, or the default values for these
variables.
+- ``docker-compose.yml`` - here we define docker services which can be
configured using either environment variables, or the default values for these
variables.
- ``.env`` - here we define default values to configure the services in
``docker-compose.yml``
- ``appveyor.yml`` - here we define workflows that run on Appveyor
-We use :ref:`Docker<docker-builds>` in order to have portable and reproducible
Linux builds, as well as running Windows builds in Windows containers. We use
:ref:`Archery<Archery>` and :ref:`Crossbow<Crossbow>` to help co-ordinate the
various CI tasks.
+We use :ref:`Docker<docker-builds>` in order to have portable and reproducible
Linux builds, as well as running Windows builds in Windows containers. We use
:ref:`Archery<Archery>` and :ref:`Crossbow<Crossbow>` to help coordinate the
various CI tasks.
One thing to note is that some of the services defined in
``docker-compose.yml`` are interdependent. When running services locally, you
must either manually build its dependencies first, or build it via the use of
``archery docker run ...`` which automatically finds and builds dependencies.
@@ -69,6 +69,6 @@ Crossbow is a subcomponent of Archery and can be used to
manually trigger builds
- the file ``dev/tasks/tasks.yml`` containing the configuration for various
tasks which can be run via Crossbow
- subdirectories containing different task templates (specified using `jinja2
syntax <https://jinja.palletsprojects.com/>`_), divided roughly by language or
package management system.
-Most of these tasks are run as part of the nightly builds, though they can
also be triggered manually by add a comment to a PR which begins with
``@github-actions crossbow submit`` followed by the name of the task to be run.
+Most of these tasks are run as part of the nightly builds, though they can
also be triggered manually by adding a comment to a PR which begins with
``@github-actions crossbow submit`` followed by the name of the task to be run.
For convenience purpose, the tasks in ``dev/tasks/tasks.yml`` are defined in
groups, which makes it simpler for multiple tasks to be submitted to Crossbow
at once. The task definitions here contain information about which service
defined in ``docker-compose.yml`` to run, the CI service to run the task on,
and which template file to use as the basis for that task.
diff --git a/docs/source/developers/python.rst
b/docs/source/developers/python.rst
index 8540bad691..c8f55a8e40 100644
--- a/docs/source/developers/python.rst
+++ b/docs/source/developers/python.rst
@@ -646,7 +646,7 @@ PyArrow are:
- Number of processes used to compile PyArrow’s C++/Cython components
- ``''``
-The components being disabled or enabled when building PyArrrow is by default
+The components being disabled or enabled when building PyArrow is by default
based on how Arrow C++ is build (i.e. it follows the ``ARROW_$COMPONENT``
flags).
However, the ``PYARROW_WITH_$COMPONENT`` environment variables can still be
used
to override this when building PyArrow (e.g. to disable components, or to
enforce
diff --git a/docs/source/developers/release.rst
b/docs/source/developers/release.rst
index 605a1adbe1..6230aae7eb 100644
--- a/docs/source/developers/release.rst
+++ b/docs/source/developers/release.rst
@@ -107,11 +107,11 @@ for specific builds and others.
Any developer can ask for a patch release to be generated sending an email to
the
`Arrow development mailing-list <https://arrow.apache.org/community/>`__ with
the reason
of why a new release is necessary.
-If there is consensus and there is a Release Manager willing to take the
effort to create
+If there is consensus and there is a Release Manager willing to make the
effort to create
the release a patch release can be created.
Committers can tag issues that should be included on the next patch release
using the
-``backport-candidate`` label. Is the responsability of the author or the
committer to add the
+``backport-candidate`` label. Is the responsibility of the author or the
committer to add the
label to the issue to help the Release Manager identify the issues that should
be backported.
If a specific issue is identified as the reason to create a patch release the
Release Manager
@@ -185,7 +185,7 @@ Some release managers prefer to perform testing before
creating the first
release candidate to avoid the need to create multiple release candidates
within
a given release.
-To test before creating a release candiate:
+To test before creating a release candidate:
* Create a pull request from the up-to-date maint-X.Y.Z branch onto main
* Title the pull request "WIP: Dummy PR to check maint-X.Y.Z status"
diff --git a/docs/source/format/DissociatedIPC.rst
b/docs/source/format/DissociatedIPC.rst
index 0b0861399c..725e013c55 100644
--- a/docs/source/format/DissociatedIPC.rst
+++ b/docs/source/format/DissociatedIPC.rst
@@ -359,7 +359,7 @@ showing how a client might handle the metadata and data
streams:
be used alongside the sequence number to match the message regardless of
the higher bytes (e.g. we only
care about matching the lower 4 bytes to the sequence number)
- * Once recieved, the Most Significant Byte's value determines how the
client processes the body data:
+ * Once received, the Most Significant Byte's value determines how the
client processes the body data:
* If the most significant byte is 0: Then the body of the message is the
raw IPC packed body buffers
allowing it to easily be processed with the corresponding metadata
header bytes.
