Clear some Vale warnings related to product terminology

Author: eread

Diff for: doc/_index.md

@@ -88,8 +88,4 @@ to work best with the available resources. Check out the [documentation](setting
 
 ## Troubleshooting
 
-For troubleshooting details, see [Troubleshooting Omnibus GitLab installation issues](troubleshooting.md).
-
-## Omnibus GitLab developer documentation
-
-See the [development documentation](development/_index.md)
+For troubleshooting details, see [Troubleshooting Linux package installation](troubleshooting.md).

Diff for: doc/build/_index.md

@@ -15,11 +15,15 @@ for more details.
 
 ## `omnibus-gitlab` packages
 
+<!-- vale gitlab_base.SubstitutionWarning = NO -->
+
 `omnibus-gitlab` uses [Omnibus](https://github.com/chef/omnibus) for
 building packages for the supported operating systems. Omnibus detects
 the OS where it is being used and build packages for that OS. You should use a
 Docker container corresponding to the OS as the environment for building packages.
 
+<!-- vale gitlab_base.SubstitutionWarning = YES -->
+
 How to build a custom package locally is described in the
 [dedicated document](build_package.md).
 

Diff for: doc/build/build_package.md

@@ -27,7 +27,7 @@ project's [Container Registry](https://gitlab.com/gitlab-org/gitlab-omnibus-buil
    docker pull registry.gitlab.com/gitlab-org/gitlab-omnibus-builder/debian_10:${BUILDER_IMAGE_REVISION}
    ```
 
-1. Clone the Omnibus GitLab source and change to the cloned directory:
+1. Clone the `omnibus-gitlab` source and change to the cloned directory:
 
    ```shell
    git clone https://gitlab.com/gitlab-org/omnibus-gitlab.git ~/omnibus-gitlab
@@ -167,6 +167,8 @@ the package cache directory (`/var/cache/omnibus/pkg`):
 bin/omnibus clean --purge gitlab
 ```
 
+<!-- vale gitlab_base.SubstitutionWarning = NO -->
+
 ## Get help on Omnibus
 
 For help with the Omnibus command-line interface, run the
@@ -175,3 +177,5 @@ For help with the Omnibus command-line interface, run the
 ```shell
 bin/omnibus help
 ```
+
+<!-- vale gitlab_base.SubstitutionWarning = YES -->

Diff for: doc/build/team_member_docs.md

@@ -102,11 +102,15 @@ of manually running new pipelines.
 
 ## Use a specific mirror or fork of a GitLab component
 
+<!-- vale gitlab_base.SubstitutionWarning = NO -->
+
 The repository sources for most software that Omnibus builds are in
 the `.custom_sources.yml` file in the `omnibus-gitlab` repository. You can override
 the main GitLab components using environment variables. Check the table
 below for details:
 
+<!-- vale gitlab_base.SubstitutionWarning = YES -->
+
 | Environment variable                          | Description |
 | --------------------------------------------- | ----------- |
 | `ALTERNATIVE_PRIVATE_TOKEN`                     | An access token used if needing to pull from private repositories. |

Diff for: doc/jihu_edition.md

@@ -53,7 +53,7 @@ Additionally, you can navigate to the GitLab administration panel of your server
 
 ## Update GitLab Enterprise Edition to JiHu Edition
 
-To update an existing GitLab Enterprise Edition (EE) server installed using the Omnibus GitLab
+To update an existing GitLab Enterprise Edition (EE) server installed using the Linux
 packages to GitLab JiHu Edition (JH), you install the JiHu Edition (JH)
 package on top of EE.
 

Diff for: doc/maintenance/_index.md

@@ -73,7 +73,7 @@ See [settings/logs.md.](../settings/logs.md)
 
 ## Starting and stopping
 
-After Omnibus GitLab is installed and configured, your server has a runit
+After the Linux package is installed and configured, your server has a runit
 service directory (`runsvdir`) process running that gets started at boot via
 `/etc/inittab` or the `/etc/init/gitlab-runsvdir.conf` Upstart resource. You
 should not have to deal with the `runsvdir` process directly; you can use the
@@ -161,7 +161,7 @@ sudo gitlab-psql -d gitlabhq_production
 
 This will only work after you have run `gitlab-ctl reconfigure` at
 least once. The `gitlab-psql` command cannot be used to connect to a
-remote PostgreSQL server, nor to connect to a local non-Omnibus PostgreSQL
+remote PostgreSQL server, nor to connect to a local non-Linux package PostgreSQL
 server.
 
 ### Starting a PostgreSQL superuser `psql` session in Geo tracking database

Diff for: doc/release/_index.md

@@ -5,10 +5,10 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 title: Omnibus GitLab release process
 ---
 
-Our main goal is to make it clear which version of GitLab is in an omnibus
+Our main goal is to make it clear which version of GitLab is in a Linux
 package.
 
-## How is the official Omnibus GitLab package built
+## How is the official Linux package built
 
 The official package build is fully automated by GitLab Inc.
 
@@ -26,16 +26,16 @@ built on CentOS6 servers, Debian 8 packages on Debian 8 servers and so on).
 The number of build servers varies but there is always at least one build
 server per platform.
 
-The Omnibus GitLab project fully utilizes GitLab CI. This means that each push
-to the Omnibus GitLab repository will trigger a build in GitLab CI which will
+The `omnibus-gitlab` project fully utilizes GitLab CI. This means that each push
+to the `omnibus-gitlab` repository will trigger a build in GitLab CI which will
 then create a package.
 
-Since we deploy GitLab.com using Omnibus GitLab packages, we need a separate
+Since we deploy GitLab.com using Linux packages, we need a separate
 remote to build the packages in case of a problem with GitLab.com or due to
 a security release of a package.
 
 This remote is located on `https://dev.gitlab.org`. The only difference between the
-Omnibus GitLab project on `https://dev.gitlab.org` and other public remotes is that the
+`omnibus-gitlab` project on `https://dev.gitlab.org` and other public remotes is that the
 project has active GitLab CI and has specific runners assigned to the project
 which run on the build servers. This is also the case for all GitLab components,
 eg. GitLab Shell is exactly the same on `https://dev.gitlab.org` as it is on GitLab.com.
@@ -49,22 +49,22 @@ Amazon S3 bucket which stores the test packages.
 
 GitLab Inc is using the [release-tools project](https://gitlab.com/gitlab-org/release-tools/tree/master) to automate the release tasks
 for every release. When the release manager starts the release process, a couple
-of important things for Omnibus GitLab will be done:
+of important things will be done:
 
 1. All remotes of the project will be synced.
 1. The versions of components will be read from GitLab CE/EE repository
-  (eg. `VERSION`, `GITLAB_SHELL_VERSION`) and written to the Omnibus GitLab repository.
-1. A specific Git tag will be created and synced to Omnibus GitLab repositories.
+  (eg. `VERSION`, `GITLAB_SHELL_VERSION`) and written to the `omnibus-gitlab` repository.
+1. A specific Git tag will be created and synced to `omnibus-gitlab` repositories.
 
-When the Omnibus GitLab repository on `https://dev.gitlab.org` gets updated, GitLab CI
+When the `omnibus-gitlab` repository on `https://dev.gitlab.org` gets updated, GitLab CI
 build gets triggered.
 
-The specific steps can be seen in the `.gitlab-ci.yml` file in the Omnibus GitLab
+The specific steps can be seen in the `.gitlab-ci.yml` file in the `omnibus-gitlab`
 repository. The builds are executed on all platforms at the same time.
 
-During the build, Omnibus GitLab will pull external libraries from their source
+During the build, `omnibus-gitlab` pulls external libraries from their source
 locations and GitLab components like GitLab, GitLab Shell, GitLab Workhorse, and
-so on will be pulled from `https://dev.gitlab.org`.
+so on are pulled from `https://dev.gitlab.org`.
 
 Once the build completes and the .deb or .rpm packages are built, depending on
 the build type package will be pushed to <https://packages.gitlab.com> or to a temporary
@@ -75,7 +75,7 @@ the build type package will be pushed to <https://packages.gitlab.com> or to a t
 ### On your development machine
 
 1. Pick a tag of GitLab to package (e.g. `v6.6.0`).
-1. Create a release branch in your Omnibus GitLab repo (e.g. `6-6-stable`).
+1. Create a release branch in your `omnibus-gitlab` repo (e.g. `6-6-stable`).
 1. If the release branch already exists, for instance because you are doing a
    patch release, make sure to pull the latest changes to your local machine:
 
@@ -105,8 +105,8 @@ the build type package will be pushed to <https://packages.gitlab.com> or to a t
    git commit
    ```
 
-1. Create an annotated tag in Omnibus GitLab corresponding to the GitLab tag.
-   The omnibus tag looks like: `MAJOR.MINOR.PATCH+OTHER.OMNIBUS_RELEASE`, where
+1. Create an annotated tag in `omnibus-gitlab` corresponding to the GitLab tag.
+   The `omnibus-gitlab` tag looks like: `MAJOR.MINOR.PATCH+OTHER.OMNIBUS_RELEASE`, where
    `MAJOR.MINOR.PATCH` is the GitLab version, `OTHER` can be something like `ce`,
    `ee` or `rc1` (or `rc1.ee`), and `OMNIBUS_RELEASE` is a number (starting at 0):
 
@@ -116,13 +116,13 @@ the build type package will be pushed to <https://packages.gitlab.com> or to a t
 
    {{< alert type="warning" >}}
 
-   Do NOT use a hyphen `-` anywhere in the Omnibus GitLab tag.
+   Do NOT use a hyphen `-` anywhere in the `omnibus-gitlab` tag.
 
    {{< /alert >}}
 
-   Examples of converting an upstream tag to an omnibus tag sequence:
+   Examples of converting an upstream tag to an `omnibus-gitlab` tag sequence:
 
-   | upstream tag     | omnibus tag sequence                        |
+   | upstream tag     | `omnibus-gitlab` tag sequence               |
    | ------------     | --------------------                        |
    | `v7.10.4`        | `7.10.4+ce.0`, `7.10.4+ce.1`, `...`         |
    | `v7.10.4-ee`     | `7.10.4+ee.0`, `7.10.4+ee.1`, `...`         |

Diff for: doc/roles/_index.md

@@ -2,7 +2,7 @@
 stage: Systems
 group: Distribution
 info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments
-title: Omnibus GitLab High Availability Roles
+title: High availability roles
 ---
 
 {{< details >}}
@@ -12,9 +12,9 @@ title: Omnibus GitLab High Availability Roles
 
 {{< /details >}}
 
-Omnibus GitLab includes various software components/services to support running GitLab in
+Linux packages include various software components/services to support running GitLab in
 a high availability configuration. By default, some of these supporting services
-are disabled, and Omnibus GitLab is configured to run as a single node installation.
+are disabled, and GitLab is configured to run as a single node installation.
 Each service can be enabled or disabled using configuration settings in `/etc/gitlab/gitlab.rb`,
 but the introduction of `roles` allows you to easily enable a group of services,
 and provides better default configuration based on the high availability roles you
@@ -48,7 +48,7 @@ roles ['geo_primary_role']
 
 The majority of the following roles will only work on a
 [GitLab Enterprise Edition](https://about.gitlab.com/install/ce-or-ee/), meaning
-a `gitlab-ee` Omnibus package. It will be mentioned next to each role.
+a `gitlab-ee` Linux package. It will be mentioned next to each role.
 
 ### GitLab App Role
 

Diff for: doc/settings/configuration.md

@@ -179,8 +179,8 @@ git_data_dirs({
 ```
 
 you'll need to redefine the configuration under `gitaly['configuration']` instead.
-Note that the `/repositories` suffix must be appended to the path, as it was previously
-appended by Omnibus internally.
+Note that the `/repositories` suffix must be appended to the path because it was previously
+appended internally.
 
 ```ruby
 gitaly['configuration'] = {
@@ -193,11 +193,15 @@ gitaly['configuration'] = {
 }
 ```
 
+<!-- vale gitlab_base.SubstitutionWarning = NO -->
+
 It's important to note that the parent directory of the `path` must also be managed by
-Omnibus. Following the example above, Omnibus will need to modify the permissions of
+Omnibus. Following the example above, Omnibus must modify the permissions of
 `/mnt/nas/git-data` on reconfiguration and may store data in that directory during
 runtime. You should select an appropriate `path` that allows for this behavior.
 
+<!-- vale gitlab_base.SubstitutionWarning = YES -->
+
 ## Store Git data in an alternative directory
 
 By default, Linux package installations store the Git repository data under

Diff for: doc/settings/database.md

@@ -584,7 +584,7 @@ To opt out of automatic PostgreSQL upgrades during GitLab package upgrades, run:
 sudo touch /etc/gitlab/disable-postgresql-upgrade
 ```
 
-If you use the Omnibus Docker image, you can disable automatic upgrades by
+If you use the Docker image, you can disable automatic upgrades by
 setting the `GITLAB_SKIP_PG_UPGRADE` environment variable to `true`.
 
 ### Revert packaged PostgreSQL server to the previous version