    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89689
 
+   Fixes: d7b3707c612 "util/disk_cache: use stat() to check if entry is a directory"
+
@@ -115,11 +122,11 @@ them in the CC list.
 Please use common sense and do not blindly add everyone.
 

 -    $ scripts/get_reviewer.pl --help # to get the the help screen
+    $ scripts/get_reviewer.pl --help # to get the help screen
     $ scripts/get_reviewer.pl -f src/egl/drivers/dri2/platform_android.c
-    Rob Herring  (reviewer:ANDROID EGL SUPPORT,added_lines:188/700=27%,removed_lines:58/283=20%)
-    Tomasz Figa  (reviewer:ANDROID EGL SUPPORT,authored:12/41=29%,added_lines:308/700=44%,removed_lines:115/283=41%)
-    Emil Velikov  (authored:13/41=32%,removed_lines:76/283=27%)
+    Rob Herring <robh@kernel.org> (reviewer:ANDROID EGL SUPPORT,added_lines:188/700=27%,removed_lines:58/283=20%)
+    Tomasz Figa <tfiga@chromium.org> (reviewer:ANDROID EGL SUPPORT,authored:12/41=29%,added_lines:308/700=44%,removed_lines:115/283=41%)
+    Emil Velikov <emil.l.velikov@gmail.com> (authored:13/41=32%,removed_lines:76/283=27%)
 
 
 
@@ -134,7 +141,7 @@ do whatever testing is prudent.
 
 
 You should always run the Mesa test suite before submitting patches.
-The test suite can be run using the 'make check' command. All tests
+The test suite can be run using the 'meson test' command. All tests
 must pass before patches will be accepted, this may mean you have
 to update the tests themselves.
 
@@ -146,11 +153,34 @@ Whenever possible and applicable, test the patch with
 to check for regressions.
 
 
+
+As mentioned at the begining, patches should be bisectable.
+A good way to test this is to make use of the `git rebase` command,
+to run your tests on each commit. Assuming your branch is based off
+origin/master, you can run:
+
++$ git rebase --interactive --exec "meson test -C build/" origin/master
+
+
+replacing "meson test" with whatever other test you want to
+run.
+
+
 
-Mailing Patches
+Submitting Patches
 
 
-Patches should be sent to the mesa-dev mailing list for review:
+Patches may be submitted to the Mesa project by
+email or with a
+GitLab merge request. To prevent
+duplicate code review, only use one method to submit your changes.
+
+
+Mailing Patches
+
+
+Patches may be sent to the mesa-dev mailing list for review:
 
 mesa-dev@lists.freedesktop.org.
 When submitting a patch make sure to use
@@ -174,8 +204,80 @@ When submitting follow-up patches you should also login to
 state of your old patches to Superseded.
 
 
+
+Some companies' mail server automatically append a legal disclaimer,
+usually containing something along the lines of "The information in this
+email is confidential" and "distribution is strictly prohibited".

+These legal notices prevent us from being able to accept your patch,
+rendering the whole process pointless. Please make sure these are
+disabled before sending your patches. (Note that you may need to contact
+your email administrator for this.)
+
+
+GitLab Merge Requests
+
+
+  GitLab Merge
+  Requests (MR) can also be used to submit patches for Mesa.
+
+
+
+  If the MR may have interest for most of the Mesa community, you can
+  send an email to the mesa-dev email list including a link to the MR.
+  Don't send the patch to mesa-dev, just the MR link.
+
+
+  Add labels to your MR to help reviewers find it. For example:
+
+
+  Mesa changes affecting all drivers: mesa
+  
Hardware vendor specific code: amd, intel, nvidia, ...
+  
Driver specific code: anvil, freedreno, i965, iris, radeonsi,
+    radv, vc4, ...
+  
Other tag examples: gallium, util
+
+
+  Tick the following when creating the MR. It allows developers to
+  rebase your work on top of master.
+
+Allow commits from members who can merge to the target branch
+
+  If you revise your patches based on code review and push an update
+  to your branch, you should maintain a clean history
+  in your patches. There should not be "fixup" patches in the history.
+  The series should be buildable and functional after every commit
+  whenever you push the branch.
+
+
+  It is your responsibility to keep the MR alive and making progress,
+  as there are no guarantees that a Mesa dev will independently take
+  interest in it.
+
+
+  Some other notes:
+
+
+  Make changes and update your branch based on feedback
+  
Old, stale MR may be closed, but you can reopen it if you
+    still want to pursue the changes
+  
You should periodically check to see if your MR needs to be
+    rebased
+  
Make sure your MR is closed if your patches get pushed outside
+    of GitLab
+  
Please send MRs from a personal fork rather than from the main
+    Mesa repository, as it clutters it unnecessarily.
+
+
 Reviewing Patches
 
+
+  To participate in code review, you should monitor the
+  
+  mesa-dev email list and the GitLab
+  Mesa Merge
+  Requests page.
+
+
 
 When you've reviewed a patch on the mailing list, please be unambiguous
 about your review.  That is, state either
@@ -202,6 +304,29 @@ which tells the patch author that the patch can be committed, as long
 as 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,
+enclose the tag in backticks:
+
++  `Reviewed-by: Joe Hacker <jhacker@example.com>`
+
+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 about solving a problem is a great way to learn your way around
+the project.  The submitter is expected to evaluate whether they have
+an appropriate amount of review feedback from people who also
+understand the code before merging their patches.
+
 
 Nominating a commit for a stable branch
 
@@ -219,7 +344,14 @@ release.
 Note: resending patch identical to one on mesa-dev@ or one that differs only
 by the extra mesa-stable@ tag is not recommended.
 
+
+If you are not the author of the original patch, please Cc: them in your
+nomination request.
+
 
+
+The current patch status can be observed in the staging branch.
+
 
 The stable tag
 
@@ -233,17 +365,11 @@ Here are some examples of such a note:
 
 
   CC: <mesa-stable@lists.freedesktop.org>
-  CC: "9.2 10.0" <mesa-stable@lists.freedesktop.org>
-  CC: "10.0" <mesa-stable@lists.freedesktop.org>
 
 
 Simply adding the CC to the mesa-stable list address is adequate to nominate
-the commit for the most-recently-created stable branch. It is only necessary
-to specify a specific branch name, (such as "9.2 10.0" or "10.0" in the
-examples above), if you want to nominate the commit for an older stable
-branch. And, as in these examples, you can nominate the commit for the older
-branch in addition to the more recent branch, or nominate the commit
-exclusively for the older branch.
+the commit for all the active stable branches. If the commit is not applicable
+for said branch the stable-release manager will reply stating so.
 
 This "CC" syntax for patch nomination will cause patches to automatically be
 copied to the mesa-stable@ mailing list when you use "git send-email" to send
@@ -257,6 +383,10 @@ Note: by removing the tag [as the commit is pushed] the patch is
 Thus, drop the line only if you want to cancel the nomination.
 
 
+Alternatively, if one uses the "Fixes" tag as described in the "Patch formatting"
+section, it nominates a commit for all active stable branches that include the
+commit that is referred to.
+
 Criteria for accepting patches to the stable branch
 
 Mesa has a designated release manager for each stable branch, and the release
@@ -336,7 +466,7 @@ within the commit summary.
 
-    git rebase -i --exec="make -j4" HEAD~8
+    git rebase -i --exec="ninja -C build/" HEAD~8
 
