Lines Matching +full:test +full:- +full:docs +full:- +full:mr
7 ----------------
9 - Patches should not mix code changes with code formatting changes
11 - Code patches should follow Mesa :doc:`coding
13 - Whenever possible, patches should only affect individual Mesa/Gallium
15 - Patches should never introduce build breaks and should be bisectable
17 - Patches should be properly :ref:`formatted <formatting>`.
18 - Patches should be sufficiently :ref:`tested <testing>` before
20 - Patches should be :ref:`submitted <submit>` via a merge request for
26 ----------------
28 - Lines should be limited to 75 characters or less so that Git logs
29 displayed in 80-column terminals avoid line wrapping. Note that
31 - The first line should be a short, concise summary of the change
42 - Subsequent patch comments should describe the change in more detail,
47 i965: Remove end-of-thread SEND alignment code.
54 - A "Signed-off-by:" line is not required, but not discouraged either.
55 - If a patch addresses an issue in GitLab, use the Closes: tag For
60 Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/1
69 - If there have been several revisions to a patch during the review
82 b) fix renderable to always test for d/s renderable
88 - If someone tested your patch, document it with a line like this:
92 Tested-by: Joe Hacker <jhacker@foo.com>
94 - If the patch was reviewed (usually the case) or acked by someone,
99 Reviewed-by: Joe Hacker <jhacker@foo.com>
100 Acked-by: Joe Hacker <jhacker@foo.com>
102 - When updating a merge request add all the tags (``Acked-by:``, ``Reviewed-by:``,
103 ``Fixes:``, ``Cc: mesa-stable`` and/or other) to the commit messages.
110 ------------------
119 git config --global alias.fixes "show -s --pretty='format:Fixes: %h (\"%s\")'"
137 Cc: mesa-stable
138 Cc: 20.0 <mesa-stable>
139 CC: 20.0 19.3 <mesa-stable>
148 ---------------
153 You should always run the Mesa test suite before submitting patches. The
154 test suite can be run using the 'meson test' command. All tests must
158 Whenever possible and applicable, test the patch with
164 to test this is to make use of the \`git rebase\` command, to run your
168 .. code-block:: console
170 $ git rebase --interactive --exec "meson test -C build/" origin/main
172 replacing ``"meson test"`` with whatever other test you want to run.
177 ------------------
182 Add labels to your MR to help reviewers find it. For example:
184 - Mesa changes affecting all drivers: mesa
185 - Hardware vendor specific code: amd, intel, nvidia, ...
186 - Driver specific code: anvil, freedreno, i965, iris, radeonsi, radv,
188 - Other tag examples: gallium, util
190 Tick the following when creating the MR. It allows developers to rebase
203 It is your responsibility to keep the MR alive and making progress, as
209 - Make changes and update your branch based on feedback
210 - After an update, for the feedback you handled, close the feedback
213 - Old, stale MR may be closed, but you can reopen it if you still want
215 - You should periodically check to see if your MR needs to be rebased
216 - Make sure your MR is closed if your patches get pushed outside of
218 - Please send MRs from a personal fork rather than from the main Mesa
224 -----------------
227 Requests <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests>`__
235 Reviewed-by: Joe Hacker <jhacker@foo.com>
241 Acked-by: Joe Hacker <jhacker@foo.com>
249 With the above fixes, Reviewed-by: Joe Hacker <jhacker@foo.com>
254 These Reviewed-by, Acked-by, and Tested-by tags should also be amended
255 into commits in a MR before it is merged.
257 When providing a Reviewed-by, Acked-by, or Tested-by tag in a GitLab MR,
262 `Reviewed-by: Joe Hacker <jhacker@example.com>`
267 Review by non-experts is encouraged. Understanding how someone else goes
274 ---------------------------------------
279 - By adding the ``Fixes:`` tag in the commit message as described above, if you are fixing
281 - By adding the ``Cc: mesa-stable`` tag in the commit message as described above.
282 - By submitting a merge request against the ``staging/year.quarter``
285 Please **DO NOT** send patches to mesa-stable@lists.freedesktop.org, it
297 ---------------------------------------------------
303 accepted and which are not. The stable-release manager is also given
306 - Patch must conform with the :ref:`Basic guidelines <guidelines>`
307 - Patch must have landed in main first. In case where the original
310 - It must not introduce a regression - be that build or runtime wise.
313 If the regression is due to faulty piglit/dEQP/CTS/other test
314 the latter must be fixed first. A reference to the offending test(s)
317 - Patch cannot be larger than 100 lines.
318 - Patches that move code around with no functional change should be
320 - Patch must be a bug fix and not a new feature.
323 An exception to this rule, are hardware-enabling "features". For
325 newly-developed hardware product can be accepted if they can be
328 - Patch must be reviewed, For example, the commit message has
329 Reviewed-by, Signed-off-by, or Tested-by tags from someone but the
331 - Performance patches are considered only if they provide information
336 :ref:`cherry-picked <pickntest>`. Alternatively the release
338 been rejected or would request a backport. The stable-release manager
339 may at times need to force-push changes to the stable branches, for
340 example, to drop a previously-picked patch that was later identified as
341 causing a regression). These force-pushes may cause changes to be lost
348 ---------------------------------------
350 By default merge conflicts are resolved by the stable-release manager.
353 de-nominate the patch.
357 stable branch (such as due to a rename), using a GitLab MR is most
358 appropriate. The MR should be based on and target the
360 per the stable branch policy. Assigning the MR to release maintainer for
363 Make sure to use ``git cherry-pick -x`` when cherry-picking the commits
370 ---------------------
373 :file:`docs` folder, and built using `Sphinx`_.
378 suggest a spelling-change, either during review or as a follow-up
379 merge-request.
382 .. _Sphinx: https://www.sphinx-doc.org/
385 --------
387 - ``git rebase -i ...`` is your friend. Don't be afraid to use it.
388 - Apply a fixup to commit FOO.
390 .. code-block:: console
393 git commit --fixup=FOO
394 git rebase -i --autosquash ...
396 - Test for build breakage between patches e.g last 8 commits.
398 .. code-block:: console
400 git rebase -i --exec="ninja -C build/" HEAD~8