<p>
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.
</p>
<code>origin/master</code>, you can run:
</p>
<pre>
-$ git rebase --interactive --exec "make check" origin/master
+$ git rebase --interactive --exec "meson test -C build/" origin/master
</pre>
<p>
-replacing <code>"make check"</code> with whatever other test you want to
+replacing <code>"meson test"</code> with whatever other test you want to
run.
</p>
</p>
<p>
Add labels to your MR to help reviewers find it. For example:
- <ul>
- <li>Mesa changes affecting all drivers: mesa
- <li>Hardware vendor specific code: amd, intel, nvidia, ...
- <li>Driver specific code: anvil, freedreno, i965, iris, radeonsi,
- radv, vc4, ...
- <li>Other tag examples: gallium, util
- </ul>
</p>
+<ul>
+ <li>Mesa changes affecting all drivers: mesa
+ <li>Hardware vendor specific code: amd, intel, nvidia, ...
+ <li>Driver specific code: anvil, freedreno, i965, iris, radeonsi,
+ radv, vc4, ...
+ <li>Other tag examples: gallium, util
+</ul>
+<p>
+ Tick the following when creating the MR. It allows developers to
+ rebase your work on top of master.
+</p>
+<pre>Allow commits from members who can merge to the target branch</pre>
<p>
If you revise your patches based on code review and push an update
to your branch, you should maintain a <strong>clean</strong> history
</p>
<p>
Some other notes:
- <ul>
- <li>Make changes and update your branch based on feedback
- <li>Old, stale MR may be closed, but you can reopen it if you
- still want to pursue the changes
- <li>You should periodically check to see if your MR needs to be
- rebased
- <li>Make sure your MR is closed if your patches get pushed outside
- of GitLab
- </ul>
</p>
+<ul>
+ <li>Make changes and update your branch based on feedback
+ <li>Old, stale MR may be closed, but you can reopen it if you
+ still want to pursue the changes
+ <li>You should periodically check to see if your MR needs to be
+ rebased
+ <li>Make sure your MR is closed if your patches get pushed outside
+ of GitLab
+ <li>Please send MRs from a personal fork rather than from the main
+ Mesa repository, as it clutters it unnecessarily.
+</ul>
<h2 id="reviewing">Reviewing Patches</h2>
into commits in a MR before it is merged.
</p>
+<p>
+When providing a Reviewed-by, Acked-by, or Tested-by tag in a gitlab MR,
+enclose the tag in backticks:
+</p>
+<pre>
+ `Reviewed-by: Joe Hacker <jhacker@example.com>`</pre>
+<p>
+This is the markdown format for literal, and will prevent gitlab from hiding
+the < and > symbols.
+</p>
+
+<p>
+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.
+</p>
+
<h2 id="nominations">Nominating a commit for a stable branch</h2>
<p>
</pre>
<li>Test for build breakage between patches e.g last 8 commits.
<pre>
- git rebase -i --exec="make -j4" HEAD~8
+ git rebase -i --exec="ninja -C build/" HEAD~8
</pre>
<li>Sets the default mailing address for your repo.
<pre>