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:``, ``Backport-to:`` and/or other) to the commit messages.
110 ------------------
119 git config --global alias.fixes "show -s --pretty='format:Fixes: %h (\"%s\")'"
134 Alternatively, you may use the ``Backport-to:`` tag, as presented in the
137 Backport-to: 21.0
139 Multiple ``Backport-to:`` lines are allowed.
146 Cc: mesa-stable
147 Cc: 20.0 <mesa-stable>
148 CC: 20.0 19.3 <mesa-stable>
157 ---------------
162 You should always run the Mesa test suite before submitting patches. The
163 test suite can be run using the 'meson test' command. All tests must
167 Whenever possible and applicable, test the patch with
173 to test this is to make use of the \`git rebase\` command, to run your
177 .. code-block:: sh
179 $ git rebase --interactive --exec "meson test -C build/" origin/main
181 replacing ``"meson test"`` with whatever other test you want to run.
186 ------------------
191 Add labels to your MR to help reviewers find it. For example:
193 - Mesa changes affecting all drivers: mesa
194 - Hardware vendor specific code: AMD common, intel, ...
195 - Driver specific code: ANV, freedreno, i965, iris, radeonsi, RADV,
197 - Other tag examples: gallium, util
199 Tick the following when creating the MR. It allows developers to rebase
212 It is your responsibility to keep the MR alive and making progress, as
218 - Make changes and update your branch based on feedback
219 - After an update, for the feedback you handled, close the feedback
222 - Old, stale MR may be closed, but you can reopen it if you still want
224 - You should periodically check to see if your MR needs to be rebased
225 - Make sure your MR is closed if your patches get pushed outside of
227 - Please send MRs from a personal fork rather than from the main Mesa
233 -----------------
236 Requests <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests>`__
244 Reviewed-by: Joe Hacker <jhacker@foo.com>
250 Acked-by: Joe Hacker <jhacker@foo.com>
258 With the above fixes, Reviewed-by: Joe Hacker <jhacker@foo.com>
263 These Reviewed-by, Acked-by, and Tested-by tags should also be amended
264 into commits in a MR before it is merged.
266 When providing a Reviewed-by, Acked-by, or Tested-by tag in a GitLab MR,
271 `Reviewed-by: Joe Hacker <jhacker@example.com>`
276 Review by non-experts is encouraged. Understanding how someone else goes
285 ----------------------
295 Do not use the "Merge"/"Merge when pipeline succeeds"/"Set to auto-merge"
298 We use a `custom script <https://gitlab.com/marge-org/marge-bot>`__ to manage
299 this, triggered by **assigning the MR** to the pseudo-user `@marge-bot
300 <https://gitlab.freedesktop.org/marge-bot>`__.
304 :doc:`other channels <lists>` if the MR reviewers don't have access themselves.
306 Do not merge someone else's MR unless you are sure they don't have a new
308 **When in doubt, ask**, for instance by leaving a comment on that MR.
311 ---------------------------------------
316 - By adding the ``Fixes:`` tag in the commit message as described above, if you are fixing
318 - By adding the ``Cc: mesa-stable`` tag in the commit message as described above.
319 - By submitting a merge request against the ``staging/year.quarter``
322 Please **DO NOT** send patches to mesa-stable@lists.freedesktop.org, it
334 ---------------------------------------------------
340 accepted and which are not. The stable-release manager is also given
343 - Patch must conform with the :ref:`Basic guidelines <guidelines>`
344 - Patch must have landed in main first. In case where the original
347 - It must not introduce a regression - be that build or runtime wise.
350 If the regression is due to faulty Piglit/dEQP/CTS/other test
351 the latter must be fixed first. A reference to the offending test(s)
354 - Patch cannot be larger than 100 lines.
355 - Patches that move code around with no functional change should be
357 - Patch must be a bug fix and not a new feature.
360 An exception to this rule, are hardware-enabling "features". For
362 newly-developed hardware product can be accepted if they can be
365 - Patch must be reviewed, For example, the commit message has
366 Reviewed-by, Signed-off-by, or Tested-by tags from someone but the
368 - Performance patches are considered only if they provide information
373 :ref:`cherry-picked <pickntest>`. Alternatively the release
375 been rejected or would request a backport. The stable-release manager
376 may at times need to force-push changes to the stable branches, for
377 example, to drop a previously-picked patch that was later identified as
378 causing a regression). These force-pushes may cause changes to be lost
385 ---------------------------------------
387 By default merge conflicts are resolved by the stable-release manager.
394 stable branch (such as due to a rename), using a GitLab MR is most
395 appropriate. The MR should be based on and target the
397 per the stable branch policy. Assigning the MR to release maintainer for
400 Make sure to use ``git cherry-pick -x`` when cherry-picking the commits
407 ---------------------
410 :file:`docs` folder, and built using `Sphinx`_.
412 .. code-block:: sh
415 apk add coreutils graphviz py3-clang clang-dev musl-dev linux-headers
418 # Build docs
419 sphinx-build -W -b html docs docs-html/
424 suggest a spelling-change, either during review or as a follow-up
425 merge-request.
428 .. _Sphinx: https://www.sphinx-doc.org/
431 --------
433 - ``git rebase -i ...`` is your friend. Don't be afraid to use it.
434 - Apply a fixup to commit FOO.
436 .. code-block:: sh
439 git commit --fixup=FOO
440 git rebase -i --autosquash ...
442 - Test for build breakage between patches e.g last 8 commits.
444 .. code-block:: sh
446 git rebase -i --exec="ninja -C build/" HEAD~8