Lines Matching +full:vc4 +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
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 <[email protected]>
94 - If the patch was reviewed (usually the case) or acked by someone,
99 Reviewed-by: Joe Hacker <[email protected]>
100 Acked-by: Joe Hacker <[email protected]>
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 ---------------
177 .. code-block:: sh
179 $ git rebase --interactive --exec "meson test -C build/" origin/main
186 ------------------
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,
196 vc4, ...
197 - Other tag examples: gallium, util
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 <[email protected]>
250 Acked-by: Joe Hacker <[email protected]>
258 With the above fixes, Reviewed-by: Joe Hacker <[email protected]>
263 These Reviewed-by, Acked-by, and Tested-by tags should also be amended
266 When providing a Reviewed-by, Acked-by, or Tested-by tag in a GitLab MR,
271 `Reviewed-by: Joe Hacker <[email protected]>`
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>`__.
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-[email protected], it
334 ---------------------------------------------------
339 mechanism described above. The following rules define which patches are
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
345 patch is too large and/or otherwise contradicts with the rules set
347 - It must not introduce a regression - be that build or runtime wise.
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
372 If the patch complies with the rules it will be
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.
400 Make sure to use ``git cherry-pick -x`` when cherry-picking the commits
407 ---------------------
412 .. code-block:: sh
415 apk add coreutils graphviz py3-clang clang-dev musl-dev linux-headers
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