2020-09-25 15:20:20 +02:00 · 2020-09-25 15:20:20 +02:00 · 7ee8a3a2cb
parent 0894b590a4
commit 7ee8a3a2cb
7 changed files with 25 additions and 25 deletions
--- a/docs/ci/LAVA.rst
+++ b/docs/ci/LAVA.rst
@ -45,7 +45,7 @@ and some public images, and figure out how to get your boards booting.

 Once you can boot your board using a custom job definition, it's time
 to connect Mesa CI to it.  Install gitlab-runner and register as a
-shared runner (you'll need a gitlab admin for help with this).  The
+shared runner (you'll need a GitLab admin for help with this).  The
 runner *must* have a tag (like "mesa-lava-db410c") to restrict the
 jobs it takes or it will grab random jobs from tasks across fd.o, and
 your runner isn't ready for that.
@ -78,7 +78,7 @@ access it.  You probably have a ``volumes = ["/cache"]`` already, so now it woul

 Note that this token is visible to anybody that can submit MRs to
 Mesa!  It is not an actual secret.  We could just bake it into the
-gitlab CI yml, but this way the current method of connecting to the
+GitLab CI yml, but this way the current method of connecting to the
 LAVA instance is separated from the Mesa branches (particularly
 relevant as we have many stable branches all using CI).

--- a/docs/ci/bare-metal.rst
+++ b/docs/ci/bare-metal.rst
@ -29,7 +29,7 @@ gitlab-runner system, since the initramfs is what contains the Mesa
 testing payload.

 The boards should have networking, so that we can extract the dEQP .xml
-results to artifacts on gitlab.
+results to artifacts on GitLab.

 Requirements (servo)
 --------------------
@ -71,7 +71,7 @@ call "servo"::
 Setup
 -----

-Each board will be registered in fd.o gitlab.  You'll want something
+Each board will be registered in fd.o GitLab.  You'll want something
 like this to register a fastboot board:

 .. code-block:: console
@ -91,7 +91,7 @@ like this to register a fastboot board:
 For a servo board, you'll need to also volume mount the board's NFS
 root dir at /nfs and TFTP kernel directory at /tftp.

-The registration token has to come from a fd.o gitlab admin going to
+The registration token has to come from a fd.o GitLab admin going to
 https://gitlab.freedesktop.org/admin/runners

 The name scheme for Google's lab is google-freedreno-boardname-n, and
--- a/docs/ci/docker.rst
+++ b/docs/ci/docker.rst
@ -2,7 +2,7 @@ Docker CI
 =========

 For llvmpipe and swrast CI, we run tests in a container containing
-VK-GL-CTS, on the shared gitlab runners provided by `freedesktop
+VK-GL-CTS, on the shared GitLab runners provided by `freedesktop
 <http://freedesktop.org>`_

 Software architecture
@ -19,7 +19,7 @@ come up with a working MR!).
 gitlab-runner is a client that polls gitlab.freedesktop.org for
 available jobs, with no inbound networking requirements.  Jobs can
 have tags, so we can have DUT-specific jobs that only run on runners
-with that tag marked in the gitlab UI.
+with that tag marked in the GitLab UI.

 Since dEQP takes a long time to run, we mark the job as "parallel" at
 some level, which spawns multiple jobs from one definition, and then
--- a/docs/ci/index.rst
+++ b/docs/ci/index.rst
@ -42,7 +42,7 @@ about it on ``#freedesktop`` on Freenode and tag `Daniel Stone
 `Eric Anholt <https://gitlab.freedesktop.org/anholt>`__ (``anholt`` on
 IRC).

-The three gitlab CI systems currently integrated are:
+The three GitLab CI systems currently integrated are:


 .. toctree::
@ -133,11 +133,11 @@ Mesa's CI is currently run primarily on packet.net's m1xlarge nodes
 (2.2Ghz Sandybridge), with each job getting 8 cores allocated.  You
 can speed up your personal CI builds (and marge-bot merges) by using a
 faster personal machine as a runner.  You can find the gitlab-runner
-package in debian, or use gitlab's own builds.
+package in debian, or use GitLab's own builds.

-To do so, follow `gitlab's instructions
+To do so, follow `GitLab's instructions
 <https://docs.gitlab.com/ce/ci/runners/#create-a-specific-runner>`__ to
-register your personal gitlab runner in your Mesa fork.  Then, tell
+register your personal GitLab runner in your Mesa fork.  Then, tell
 Mesa how many jobs it should serve (``concurrent=``) and how many
 cores those jobs should use (``FDO_CI_CONCURRENT=``) by editing these
 lines in ``/etc/gitlab-runner/config.toml``, for example::
--- a/docs/releasing.rst
+++ b/docs/releasing.rst
@ -71,11 +71,11 @@ Commits nominated for the active branch are picked as based on the
 section.

 Nominations happen via special tags in the commit messages, and via
-gitlab merge requests against the staging branches. There are special
+GitLab merge requests against the staging branches. There are special
 scripts used to read the tags.

 The maintainer should watch or be in contact with the Intel CI team, as
-well as watch the gitlab CI for regressions.
+well as watch the GitLab CI for regressions.

 Cherry picking should be done with the '-x' switch (to automatically add
 "cherry picked from ..." to the commit message):
@ -92,7 +92,7 @@ Following developers have requested permanent exception
 -  *Ilia Mirkin*
 -  *AMD team*

-The gitlab CI must pass.
+The GitLab CI must pass.

 For Windows related changes, the main contact point is Brian Paul. Jose
 Fonseca can also help as a fallback contact.
@ -191,7 +191,7 @@ To setup the branchpoint:
   git push origin X.Y-branchpoint X.Y

 Now go to
-`gitlab <https://gitlab.freedesktop.org/mesa/mesa/-/milestones>`__ and
+`GitLab <https://gitlab.freedesktop.org/mesa/mesa/-/milestones>`__ and
 add the new Mesa version X.Y.

 Check that there are no distribution breaking changes and revert them if
@ -326,7 +326,7 @@ Use the generated template during the releasing process.
 Again, pay attention to add a note to warn about a final release in a
 series, if that is the case.

-Update gitlab issues
+Update GitLab issues
 --------------------

 Parse through the bug reports as listed in the docs/relnotes/X.Y.Z.rst
--- a/docs/repository.rst
+++ b/docs/repository.rst
@ -47,7 +47,7 @@ To get the Mesa sources anonymously (read-only):
 Developer git Access
 --------------------

-If you wish to become a Mesa developer with gitlab merge privilege,
+If you wish to become a Mesa developer with GitLab merge privilege,
 please follow this procedure:

 #. Subscribe to the
@ -56,7 +56,7 @@ please follow this procedure:
 #. Start contributing to the project by :doc:`submitting
   patches <submittingpatches>`. Specifically,

-   -  Use `gitlab <https://gitlab.freedesktop.org/>`__ to create your
+   -  Use `GitLab <https://gitlab.freedesktop.org/>`__ to create your
      merge requests.
   -  Wait for someone to review the code and give you a ``Reviewed-by``
      statement.
@ -67,7 +67,7 @@ please follow this procedure:
   a dozen or so patches accepted, a maintainer may use their discretion
   to give you access to merge your own code.

-Pushing code to your gitlab account via HTTPS
+Pushing code to your GitLab account via HTTPS
 ---------------------------------------------

 Useful for people behind strict proxies
--- a/docs/submittingpatches.rst
+++ b/docs/submittingpatches.rst
@ -52,7 +52,7 @@ Patch formatting
      platform.

 -  A "Signed-off-by:" line is not required, but not discouraged either.
-  If a patch addresses an issue in gitlab, use the Closes: tag For
+-  If a patch addresses an issue in GitLab, use the Closes: tag For
   example:

   ::
@ -225,7 +225,7 @@ Reviewing Patches

 To participate in code review, you can monitor the GitLab Mesa `Merge
 Requests <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests>`__
-page, and/or register for notifications in your gitlab settings.
+page, and/or register for notifications in your GitLab settings.

 When you've reviewed a patch, please be unambiguous about your review.
 That is, state either
@ -254,14 +254,14 @@ the issues are resolved first.
 These Reviewed-by, Acked-by, and Tested-by tags should also be amended
 into commits in a MR before it is merged.

-When providing a Reviewed-by, Acked-by, or Tested-by tag in a gitlab MR,
+When providing a Reviewed-by, Acked-by, or Tested-by tag in a GitLab MR,
 enclose the tag in backticks:

 ::

   `Reviewed-by: Joe Hacker <jhacker@example.com>`

-This is the markdown format for literal, and will prevent gitlab from
+This is the markdown format for literal, and will prevent GitLab from
 hiding the < and > symbols.

 Review by non-experts is encouraged. Understanding how someone else goes
@ -280,7 +280,7 @@ branch and release. In order or preference:
  a specific commit.
 - By adding the ``Cc: mesa-stable`` tag in the commit message as described above.
 - By submitting a merge request against the ``staging/year.quarter``
-  branch on gitlab.
+  branch on GitLab.

 Please **DO NOT** send patches to mesa-stable@lists.freedesktop.org, it
 is not monitored actively and is a historical artifact.
@ -354,7 +354,7 @@ de-nominate the patch.

 For patches that either need to be nominated after they've landed in
 master, or that are known ahead of time to not not apply cleanly to a
-stable branch (such as due to a rename), using a gitlab MR is most
+stable branch (such as due to a rename), using a GitLab MR is most
 appropriate. The MR should be based on and target the
 staging/year.quarter branch, not on the year.quarter branch, per the
 stable branch policy. Assigning the MR to release maintainer for said