mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2026-01-06 06:40:08 +01:00
docs: improve "backport MR" instructions
Mainly, the MR should target `YY.N` instead of `staging/YY.N` to avoid conflicts when the release manager works on the staging branch. Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36136>
This commit is contained in:
parent
b74e641c04
commit
76f1e08222
1 changed files with 10 additions and 4 deletions
|
|
@ -394,10 +394,16 @@ denominate the patch.
|
|||
For patches that either need to be nominated after they've landed in
|
||||
main, or that are known ahead of time to not not apply cleanly to a
|
||||
stable branch (such as due to a rename), using a GitLab MR is most
|
||||
appropriate. The MR should be based on and target the
|
||||
``staging/year.quarter`` branch, not on the ``year.quarter`` branch,
|
||||
per the stable branch policy. Assigning the MR to release maintainer for
|
||||
said branch or mentioning them is helpful, but not required.
|
||||
appropriate. The MR must be based on and target the ``YY.N`` branch, and the
|
||||
release manager will change the target to the ``staging/YY.N`` branch when
|
||||
merging it; this avoid issues with the rebasing nature of the ``staging``
|
||||
branches. Assigning the MR to release maintainer for said branch or mentioning
|
||||
them is not required but helpful, to allow them to see the MR as soon as
|
||||
possible.
|
||||
|
||||
.. warning::
|
||||
Do not merge your backport MR yourself, even if you think it's ready.
|
||||
The release manager will do it once everything is ok.
|
||||
|
||||
Make sure to use ``git cherry-pick -x`` when cherry-picking the commits
|
||||
from the main branch. This adds the "cherry picked from commit ..." line
|
||||
|
|
|
|||
Loading…
Add table
Reference in a new issue