Lines Matching +full:commit +full:- +full:message +full:- +full:check
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.
50 for Sandybridge (commit 077d01b6). There is no documentation saying this
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 ------------------
112 If a patch addresses a issue introduced with earlier commit, that
113 should be noted in the commit message. For example::
115 Fixes: d7b3707c612 ("util/disk_cache: use stat() to check if entry is a directory")
119 git config --global alias.fixes "show -s --pretty='format:Fixes: %h (\"%s\")'"
126 If you want a commit to be applied to a stable branch, you should add an
127 appropriate note to the commit message.
130 is the preferred way to nominate a commit that should be backported.
137 Cc: mesa-stable
138 Cc: 20.0 <mesa-stable>
139 CC: 20.0 19.3 <mesa-stable>
148 ---------------
161 check for regressions.
165 tests on each commit. Assuming your branch is based off
170 $ git rebase --interactive --exec "meson test -C build/" origin/master
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
200 buildable and functional after every commit whenever you push the
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
273 Nominating a commit for a stable branch
274 ---------------------------------------
279 - By adding the ``Fixes:`` tag in the commit message as described above, if you are fixing
280 a specific commit.
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 master first. In case where the original
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
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