Lines Matching +full:update +full:- +full:docs +full:- +full:branch
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:``, ``Backport-to:`` and/or other) to the commit messages.
110 ------------------
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
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 ---------------
164 pass before patches will be accepted, this may mean you have to update
174 tests on each commit. Assuming your branch is based off
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,
197 - Other tag examples: gallium, util
204 Allow commits from members who can merge to the target branch
206 If you revise your patches based on code review and push an update to
207 your branch, you should maintain a **clean** history in your patches.
210 branch.
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
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>`__.
310 Nominating a commit for a stable branch
311 ---------------------------------------
314 branch and release. In order or preference:
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``
320 branch on GitLab. Refer to the :ref:`instructions below <backports>`.
322 Please **DO NOT** send patches to mesa-stable@lists.freedesktop.org, it
329 branch <stagingbranch>`.
333 Criteria for accepting patches to the stable branch
334 ---------------------------------------------------
336 Mesa has a designated release manager for each stable branch, and the
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.
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
379 from the stable branch if developers push things directly. Consider
384 Sending backports for the stable branch
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
396 ``staging/year.quarter`` branch, not on the ``year.quarter`` branch,
397 per the stable branch policy. Assigning the MR to release maintainer for
398 said branch or mentioning them is helpful, but not required.
400 Make sure to use ``git cherry-pick -x`` when cherry-picking the commits
401 from the main branch. This adds the "cherry picked from commit ..." line
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