Merge branch 'fix/consistent_gitlab_naming' into 'master'

Apply consistent case for 'GitLab' in docs and gitian build script help text

Closes Bitcoin-ABC#66

See merge request bitcoin-cash-node/bitcoin-cash-node!133

CONTRIBUTING.md

@@ -22,8 +22,8 @@ project progress and activities, even in detailed form such as individual
 change requests.
 
 Users are free to submit issues or comment on existing ones - all that is
-needed is a Gitlab account which can be freely registered (use the 'Register'
-button on the Gitlab page).
+needed is a GitLab account which can be freely registered (use the 'Register'
+button on the GitLab page).
 
 In addition to the project repository, we have various other channels where
 project contributors can be reached.
@@ -87,7 +87,7 @@ quickly, it should be reverted, and re-applied later when it no longer breaks th
 
 Here are some handy links for development practices aligned with Bitcoin Cash Node:
 
-- [BCHN Gitlab development working rules and guidelines](doc/bchn-gitlab-usage-rules-and-guidelines.md)
+- [BCHN GitLab development working rules and guidelines](doc/bchn-gitlab-usage-rules-and-guidelines.md)
 - [Developer Notes](doc/developer-notes.md)
 - [How to Do Code Reviews Like a Human - Part 1](https://mtlynch.io/human-code-reviews-1/) 
 - [How to Do Code Reviews Like a Human - Part 2](https://mtlynch.io/human-code-reviews-2/)
@@ -119,7 +119,7 @@ Enter a file in which to save the key (/home/*username*/.ssh/id_rsa): [Press ent
 
 *NOTE: the path in the message shown above is specific to UNIX-like systems and may differ if you run on other platforms.*
 
-4. Upload your SSH public key to Gitlab
+4. Upload your SSH public key to GitLab
 
   - Go to: `https://gitlab.com, log in
 
@@ -129,9 +129,9 @@ Paste contents from: `$HOME/.ssh/id_rsa.pub`
 
 5. Create a personal fork of the Bitcoin Cash Node repository for your work
 
-  - Sign into Gitlab under your account, then visit the project at https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node
+  - Sign into GitLab under your account, then visit the project at https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node
 
-  - Click the 'Fork' button on the top right, and choose to fork the project to your personal Gitlab space.
+  - Click the 'Fork' button on the top right, and choose to fork the project to your personal GitLab space.
 
 6. Clone your personal work repository to your local machine:
 
@@ -167,7 +167,7 @@ You can then proceed to test the changes proposed by that merge request.
 
 9. Code formatting tools
 
-During submission of patches, our Gitlab process may refused code that
+During submission of patches, our GitLab process may refused code that
 is not styled according to our coding guidelines.
 
 To enforce Bitcoin Cash Node codeformatting standards, you may need to
@@ -211,17 +211,17 @@ A typical workflow would be:
 
     git commit -a -m 'my-commit'
 
-- Push the topic branch to your Gitlab repository
+- Push the topic branch to your GitLab repository
 
     git push -u origin my-topic-branch
 
-- Then create a Merge Request (the Gitlab equivalent of a Pull Request)
+- Then create a Merge Request (the GitLab equivalent of a Pull Request)
   from that branch in your personal repository. To do this, you need to
-  sign in to Gitlab, go to the branch and click the button which lets you
+  sign in to GitLab, go to the branch and click the button which lets you
   create a Merge Request (you need to fill out at least title and description
   fields).
 
-- Work with us on Gitlab to receive review comments, going back to the
+- Work with us on GitLab to receive review comments, going back to the
   'Make your changes' step above if needed to make further changes on your
   branch, and push them upstream as above. They will automatically appear
   in your Merge Request.

contrib/gitian-build.py

@@ -198,7 +198,7 @@ def main():
     parser.add_argument('-c', '--commit', action='store_true', dest='commit',
                         help='Indicate that the version argument is for a commit or branch')
     parser.add_argument('-R', '--merge-request', action='store_true', dest='merge_request',
-                        help='Indicate that the version argument is the number of a gitlab merge request')
+                        help='Indicate that the version argument is the number of a GitLab merge request')
     parser.add_argument('-u', '--url', dest='url', default='https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node.git',
                         help='Specify the URL of the repository. Default is %(default)s')
     parser.add_argument('-v', '--verify', action='store_true',

doc/bchn-gitlab-usage-rules-and-guidelines.md

@@ -1,11 +1,11 @@
-# BCHN Gitlab development working rules & guidelines
+# BCHN GitLab development working rules & guidelines
 
 This document describes the working rules, workflow, terminology and guidelines that developers and testers should be familiar with while working on the Bitcoin Cash Node repository and issue tracker at
 
 https://gitlab.com/bitcoin-cash-node/bitcoin-cash-node/
 
 
-## BCHN Gitlab workflow
+## BCHN GitLab workflow
 
 Below are common workflows users will encounter:
 
@@ -19,7 +19,7 @@ Below are common workflows users will encounter:
 
 * Create a Merge Request (MR)
 
-You will need to create a Gitlab account if you don't have one (it's free to do so).
+You will need to create a GitLab account if you don't have one (it's free to do so).
 
 
 ## General rules for contributors
@@ -28,7 +28,7 @@ The following are rules and should always be followed.
 
 **Rule 0**: If it seems wrong to follow a rule in some instance, query back with the maintainer about whether the process needs adjustment.
 
-**General Rule 1**: Any exceptions to following the rules shall always be documented by a comment on Gitlab. If you see a rule violation, ask the person (ping them on GL) to ask them to comment and explain why they did what they did.
+**General Rule 1**: Any exceptions to following the rules shall always be documented by a comment on GitLab. If you see a rule violation, ask the person (ping them on GL) to ask them to comment and explain why they did what they did.
 
 **General Rule 2**: For developers, when approving a merge request ("Approve" button), a comment must be left on what basis the approval is made. It can be in the terse form (ref. "Code review lingo") or in a more descriptive comment.
 
@@ -58,7 +58,7 @@ The following are guidelines and should be followed if possible.
 
 **Guideline 1**: Assign issues to yourself when starting to work on them, if they are unassigned. You don't need anyone's permission, but if it's an issue with past history, it is polite to query first if there is a chance your action might get in the way of someone.
 
-**Guideline 2**: If an issue is assigned to someone else but you can do some task that you think is helpful, you can do so without assigning it to yourself, or co-assigning it to yourself to indicate that you are also working on something related to that issue. You can also query (via Gitlab or otherwise) with the current Assignee whether they want to hand it over to you, in case they are currently inconvenienced or blocked from progressing it.
+**Guideline 2**: If an issue is assigned to someone else but you can do some task that you think is helpful, you can do so without assigning it to yourself, or co-assigning it to yourself to indicate that you are also working on something related to that issue. You can also query (via GitLab or otherwise) with the current Assignee whether they want to hand it over to you, in case they are currently inconvenienced or blocked from progressing it.
 
 **Guideline 3**: Use appropriate project checklists when reviewing anything. If you don't find a checklist, bug the maintainers to provide you one.
 
@@ -82,24 +82,24 @@ Commonly used lingo when reviewing a MR
 
 **Labels**
 
-Gitlab has a facility for decorating issues and Merge Requests with labels. Please see below for a list of known labels.
+GitLab has a facility for decorating issues and Merge Requests with labels. Please see below for a list of known labels.
 
 All labels should a clearly explained meaning and purpose. It is suggested that if a label is not documented, that an issue is opened to notify the maintainers of update the documentation.
 
 labels on issues may change during lifetime of an issue / MR.
 
-Anyone can set labels (add new, change, remove) at any time, the Gitlab system records all these label changes so it remains traceable who did what, when.
+Anyone can set labels (add new, change, remove) at any time, the GitLab system records all these label changes so it remains traceable who did what, when.
 
 **Tags**
 
 Committers can add prefix tags to their commit messages and MR titles to provide brief visual summary of their committed or proposed changes.
 
-These tags have no special meaning to Gitlab (at least not yet) and are simply for human consumption at this stage.They are not well standardized, but below you will find a section documenting some better known commit tags.
+These tags have no special meaning to GitLab (at least not yet) and are simply for human consumption at this stage.They are not well standardized, but below you will find a section documenting some better known commit tags.
 
 
 **WIP**
 
-When a merge requested is prefixed by "WIP:", Gitlab blocks merging of the MR.
+When a merge requested is prefixed by "WIP:", GitLab blocks merging of the MR.
 
 People who submit or work on a merge request should set the "WIP" prefix as long as they know the MR will still receive extensive revision and is not yet in a state ready for merge review.
 
@@ -109,7 +109,7 @@ The issue/MR will attract intention soon, but you can also invite others for rev
 Occasionally, developers may ask for review of WIP items in the understanding that such review is preliminary and intended to gather input for revision which is believed to be needed still.
 
 
-### List of labels currently used on BCHN Gitlab
+### List of labels currently used on BCHN GitLab
 
 NOTE: MR = "Merge Request"
 

doc/gitian-building.md

@@ -89,7 +89,7 @@ You only need to do this once:
 ./gitian-build.py --setup satoshi 0.21.0
 ```
 
-Where `satoshi` is your Gitlab name and `0.21.0` is the most recent tag (without `v`). 
+Where `satoshi` is your GitLab name and `0.21.0` is the most recent tag (without `v`).
 
 Build binaries
 --------------
@@ -109,7 +109,7 @@ You need to copy these uncommited changes to your host machine, where you can si
 
 ```bash
 export NAME=satoshi
-gpg --output $VERSION-linux/$NAME/bitcoin-cash-node-linux-0.21.0-build.assert.sig --detach-sign 0.21.0-linux/$NAME/bitcoin-cash-node-linux-0.21.0-build.assert 
-gpg --output $VERSION-osx-unsigned/$NAME/bitcoin-cash-node-osx-0.21.0-build.assert.sig --detach-sign 0.21.0-osx-unsigned/$NAME/bitcoin-cash-node-osx-0.21.0-build.assert 
-gpg --output $VERSION-win-unsigned/$NAME/bitcoin-cash-node-win-0.21.0-build.assert.sig --detach-sign 0.21.0-win-unsigned/$NAME/bitcoin-cash-node-win-0.21.0-build.assert 
+gpg --output $VERSION-linux/$NAME/bitcoin-cash-node-linux-0.21.0-build.assert.sig --detach-sign 0.21.0-linux/$NAME/bitcoin-cash-node-linux-0.21.0-build.assert
+gpg --output $VERSION-osx-unsigned/$NAME/bitcoin-cash-node-osx-0.21.0-build.assert.sig --detach-sign 0.21.0-osx-unsigned/$NAME/bitcoin-cash-node-osx-0.21.0-build.assert
+gpg --output $VERSION-win-unsigned/$NAME/bitcoin-cash-node-win-0.21.0-build.assert.sig --detach-sign 0.21.0-win-unsigned/$NAME/bitcoin-cash-node-win-0.21.0-build.assert
 ```

doc/release-process.md

@@ -27,7 +27,7 @@ Bitcoin Cash Node Release Process
 
 4. Add git tag for release
     a. Create the tag: `git tag vM.m.r` (M = major version, m = minor version, r = revision)
-    b. Push the tag to Gitlab:
+    b. Push the tag to GitLab:
         ```
         git push <gitlab remote> master
         git push <gitlab remote> vM.m.r