From 7ee8a3a2cbc7d2492f262a445603d6bfa4cd6b11 Mon Sep 17 00:00:00 2001 From: Erik Faye-Lund Date: Fri, 25 Sep 2020 15:20:20 +0200 Subject: [PATCH] docs: gitlab -> GitLab Reviewed-by: Eric Engestrom Part-of: --- docs/ci/LAVA.rst | 4 ++-- docs/ci/bare-metal.rst | 6 +++--- docs/ci/docker.rst | 4 ++-- docs/ci/index.rst | 8 ++++---- docs/releasing.rst | 10 +++++----- docs/repository.rst | 6 +++--- docs/submittingpatches.rst | 12 ++++++------ 7 files changed, 25 insertions(+), 25 deletions(-) diff --git a/docs/ci/LAVA.rst b/docs/ci/LAVA.rst index 6ccce795a1b..efc0143b1d6 100644 --- 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). diff --git a/docs/ci/bare-metal.rst b/docs/ci/bare-metal.rst index 800469eae2b..78c6f424973 100644 --- 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 diff --git a/docs/ci/docker.rst b/docs/ci/docker.rst index bb01d80794b..29bc17186b7 100644 --- 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 `_ 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 diff --git a/docs/ci/index.rst b/docs/ci/index.rst index 22e697b3d8b..ee3f4564d39 100644 --- 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 `__ (``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 `__ 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:: diff --git a/docs/releasing.rst b/docs/releasing.rst index 655a6e86950..39db085f759 100644 --- 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 `__ and +`GitLab `__ 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 diff --git a/docs/repository.rst b/docs/repository.rst index 8172793009a..1de4fbe1ba4 100644 --- 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 `. Specifically, - - Use `gitlab `__ to create your + - Use `GitLab `__ 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 diff --git a/docs/submittingpatches.rst b/docs/submittingpatches.rst index 712adfc5c9b..a2303bfd22b 100644 --- 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 `__ -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 ` -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