dsg/mesa
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

docs: Rename master branch to main

Browse source 
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Eric Engestrom <eric@engestrom.ch>
This commit is contained in:
Jordan Justen 2021-04-26 13:51:33 -07:00
parent 2ec9cd3104
commit 57897b4095
No known key found for this signature in database
GPG key ID: 37F99F68CAF992EB
6 changed files with 23 additions and 23 deletions
Download patch file Download diff file Expand all files Collapse all files

10
docs/submittingpatches.rst
View file

@ -163,11 +163,11 @@ check for regressions.
As mentioned at the beginning, patches should be bisectable. A good way
to test this is to make use of the \`git rebase\` command, to run your
tests on each commit. Assuming your branch is based off
``origin/master``, you can run:
``origin/main``, you can run:
.. code-block:: console
$ git rebase --interactive --exec "meson test -C build/" origin/master
$ git rebase --interactive --exec "meson test -C build/" origin/main
replacing ``"meson test"`` with whatever other test you want to run.
@ -188,7 +188,7 @@ Add labels to your MR to help reviewers find it. For example:
- Other tag examples: gallium, util
Tick the following when creating the MR. It allows developers to rebase
your work on top of master.
your work on top of main.
::
@ -304,7 +304,7 @@ accepted and which are not. The stable-release manager is also given
broad discretion in rejecting patches that have been nominated.
- Patch must conform with the :ref:`Basic guidelines <guidelines>`
- Patch must have landed in master first. In case where the original
- Patch must have landed in main first. In case where the original
patch is too large and/or otherwise contradicts with the rules set
within, a backport is appropriate.
- It must not introduce a regression - be that build or runtime wise.
@ -353,7 +353,7 @@ conflicts they should ask the original author to provide a backport or
de-nominate the patch.
For patches that either need to be nominated after they've landed in
master, or that are known ahead of time to not not apply cleanly to a
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