Lines Matching +full:iris +full:- +full:rules +full:- +full:performance
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
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 ---------------
168 .. code-block:: console
170 $ git rebase --interactive --exec "meson test -C build/" origin/main
177 ------------------
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
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
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 ---------------------------------------------------
302 mechanism described above. The following rules define which patches are
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
308 patch is too large and/or otherwise contradicts with the rules set
310 - It must not introduce a regression - be that build or runtime wise.
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
335 If the patch complies with the rules it will be
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.
363 Make sure to use ``git cherry-pick -x`` when cherry-picking the commits
370 ---------------------
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