Merge branch 'master' into m-renaud-mrenaud-docs-getting-started

Author: Mikolaj

.arcconfig

@@ -0,0 +1,29 @@
+pull_request_rules:
+  # rebase+merge strategy
+  - actions:
+      queue:
+        name: default
+        # Merge into master with a merge commit
+        method: merge
+        # Update the pr branch with rebase, so the history is clean
+        update_method: rebase
+    name: Put pull requests in the rebase+merge queue
+    conditions:
+      - label=merge me
+      - '#approved-reviews-by>=2'
+  # merge+squash strategy
+  - actions:
+      queue:
+        name: default
+        method: squash
+        # both update methods get absorbed by the squash, so we use the most
+        # reliable
+        update_method: merge
+    name: Put pull requests in the squash+merge queue
+    conditions:
+      - label=squash+merge me
+      - '#approved-reviews-by>=2'
+
+queue_rules:
+  - name: default
+    conditions: []

.ghci

@@ -63,7 +63,7 @@ jobs:
           cabal v2-run cabal-install:unit-tests -- --pattern "! (/FileMonitor/ || /VCS/ || /Get/)"
       - name: cabal-tests
         # Using only one job, -j1, to fail less.
-        run: cabal v2-run cabal-testsuite:cabal-tests -- -j1 --with-cabal=dist-newstyle\build\x86_64-windows\ghc-8.6.5\cabal-install-3.6.0.0\x\cabal\build\cabal\cabal.exe
+        run: cabal v2-run cabal-testsuite:cabal-tests -- -j1 --with-cabal=dist-newstyle\build\x86_64-windows\ghc-8.6.5\cabal-install-3.7.0.0\x\cabal\build\cabal\cabal.exe
   test-windows-8_10_4:
     name: test ghc-8.10.4
     runs-on: windows-latest
@@ -111,4 +111,4 @@ jobs:
           cabal v2-run cabal-install:unit-tests -- --pattern "! (/FileMonitor/ || /VCS/ || /Get/)"
       - name: cabal-tests
         # Using only one job, -j1, to fail less.
-        run: cabal v2-run cabal-testsuite:cabal-tests -- -j1 --with-cabal=dist-newstyle\build\x86_64-windows\ghc-8.10.4\cabal-install-3.6.0.0\x\cabal\build\cabal\cabal.exe
+        run: cabal v2-run cabal-testsuite:cabal-tests -- -j1 --with-cabal=dist-newstyle\build\x86_64-windows\ghc-8.10.4\cabal-install-3.7.0.0\x\cabal\build\cabal\cabal.exe

.ghcid

@@ -26,6 +26,11 @@ cabal-tests.log
 /cabal-install/Setup
 /cabal-install/source-file-list
 
+.stylish-haskell.yaml
+.stylish-haskell.yml
+.ghci
+.ghcid
+
 # Output of release and bootstrap
 _build
 
@@ -69,3 +74,6 @@ register.sh
 
 # benchmarks
 bench.html
+
+# Emacs
+.projectile

.github/mergify.yml

@@ -29,11 +29,11 @@ cabal v2-build cabal-tests # etc...
 Running tests
 -------------
 
-**Using Github Actions and AppVeyor.**
+**Using Github Actions.**
 If you are not in a hurry, the most convenient way to run tests on Cabal
 is to make a branch on GitHub and then open a pull request; our
-continuous integration service on Github Actions and AppVeyor will build and
-test your code.  Title your PR with WIP so we know that it does not need
+continuous integration service on Github Actions builds and
+tests your code.  Title your PR with WIP so we know that it does not need
 code review.
 
 Some tips for using Github Actions effectively:
@@ -72,10 +72,6 @@ failures:
    tested.  If you have an Ubuntu system, you can download
    the binaries and run them directly.
 
-5. Is the test failing on AppVeyor?  Consider logging in via
-   Remote Desktop to the build VM:
-   https://www.appveyor.com/docs/how-to/rdp-to-build-worker/
-
 If none of these let you reproduce, there might be some race condition
 or continuous integration breakage; please file a bug.
 
@@ -194,8 +190,9 @@ We like [this style guide][guide].
 Changelog
 ---------
 
-When opening a pull request, you should write a changelog entry.
-This is done by adding a file in the `changelog.d` directory.
+When opening a pull request, you should write a changelog entry
+(or more in case of multiple independent changes).
+This is done by adding files in the `changelog.d` directory.
 
 The files follow a simple key-value format similar to the one for .cabal files.