Lines Matching +full:mesa +full:- +full:rules
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
36 mesa: Add support for querying GL_VERTEX_ATTRIB_ARRAY_LONG
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
65 **Do not use the ``Fixes:`` tag for this!** Mesa already uses
69 - If there have been several revisions to a patch during the review
74 st/mesa: add ARB_texture_stencil8 support (v4)
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
170 $ git rebase --interactive --exec "meson test -C build/" origin/master
177 ------------------
179 Patches are submitted to the Mesa project via a
180 `GitLab <https://gitlab.freedesktop.org/mesa/mesa>`__ Merge Request.
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
204 there are no guarantees that a Mesa dev will independently take interest
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 -----------------
226 To participate in code review, you can monitor the GitLab Mesa `Merge
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 ---------------------------------------------------
299 Mesa has a designated release manager for each stable branch, and the
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 master 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.
364 --------
366 - ``git rebase -i ...`` is your friend. Don't be afraid to use it.
367 - Apply a fixup to commit FOO.
369 .. code-block:: console
372 git commit --fixup=FOO
373 git rebase -i --autosquash ...
375 - Test for build breakage between patches e.g last 8 commits.
377 .. code-block:: console
379 git rebase -i --exec="ninja -C build/" HEAD~8