Submitting patches

Submitting Patches

Basic guidelines
Patch formatting
Testing Patches -
Mailing Patches +
Submitting Patches
Reviewing Patches
Nominating a commit for a stable branch
Criteria for accepting patches to the stable branch +
Sending backports for the stable branch +
Git tips

Basic guidelines

@@ -34,14 +36,16 @@ perhaps, in very trivial cases.)

Code patches should follow Mesa coding conventions. -

Whenever possible, patches should only effect individual Mesa/Gallium +

Whenever possible, patches should only affect individual Mesa/Gallium components.

Patches should never introduce build breaks and should be bisectable (see git bisect.)

Patches should be properly formatted.

Patches should be sufficiently tested before submitting. -

Patches should be submitted to submitted to mesa-dev -for review using git send-email. +

Patches should be submitted +to mesa-dev or with +a merge request +for review. @@ -64,27 +68,39 @@ with a module name. Examples: if needed. For example:

     i965: Remove end-of-thread SEND alignment code.
-    
+
     This was present in Eric's initial implementation of the compaction code
     for Sandybridge (commit 077d01b6). There is no documentation saying this
     is necessary, and removing it causes no regressions in piglit on any
     platform.

A "Signed-off-by:" line is not required, but not discouraged either. -

If a patch address a bugzilla issue, that should be noted in the -patch comment. For example: +

If a patch addresses an issue in gitlab, use the Closes: tag +For example: +

+    Closes: https://gitlab.freedesktop.org/mesa/mesa/issues/1
+

Prefer the full url to just

Closes: #1

, since the url makes it +easier to get to the bug page from

git log

+Do not use the Fixes: tag for this! Mesa already uses Fixes for something else. + +

If a patch addresses a issue introduced with earlier commit, that should be +noted in the patch comment. For example:

-   Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89689
+   Fixes: d7b3707c612 "util/disk_cache: use stat() to check if entry is a directory"

You can produce those fixes lines by running +

git config --global alias.fixes "show -s --pretty='format:Fixes: %h (\"%s\")'"

+once and then using

git fixes <sha1>

If there have been several revisions to a patch during the review process, they should be noted such as in this example:

     st/mesa: add ARB_texture_stencil8 support (v4)
-    
+
     if we support stencil texturing, enable texture_stencil8
     there is no requirement to support native S8 for this,
     the texture can be converted to x24s8 fine.
-    
+
     v2: fold fixes from Marek in:
        a) put S8 last in the list
        b) fix renderable to always test for d/s renderable
@@ -103,6 +119,22 @@ that should be documented with:
     Reviewed-by: Joe Hacker <jhacker@foo.com>
     Acked-by: Joe Hacker <jhacker@foo.com>

If sending later revision of a patch, add all the tags - ack, r-b, +Cc: mesa-stable and/or other. This provides reviewers with quick feedback if the +patch has already been reviewed. +

In order for your patch to reach the prospective reviewer easier/faster, +use the script scripts/get_reviewer.pl to get a list of individuals and include +them in the CC list. +

+Please use common sense and do not blindly add everyone. +

+    $ scripts/get_reviewer.pl --help # to get the help screen
+    $ scripts/get_reviewer.pl -f src/egl/drivers/dri2/platform_android.c
+    Rob Herring <robh@kernel.org> (reviewer:ANDROID EGL SUPPORT,added_lines:188/700=27%,removed_lines:58/283=20%)
+    Tomasz Figa <tfiga@chromium.org> (reviewer:ANDROID EGL SUPPORT,authored:12/41=29%,added_lines:308/700=44%,removed_lines:115/283=41%)
+    Emil Velikov <emil.l.velikov@gmail.com> (authored:13/41=32%,removed_lines:76/283=27%)
+

@@ -116,23 +148,46 @@ do whatever testing is prudent.

You should always run the Mesa test suite before submitting patches. -The test suite can be run using the 'make check' command. All tests +The test suite can be run using the 'meson test' command. All tests must pass before patches will be accepted, this may mean you have to update the tests themselves.

Whenever possible and applicable, test the patch with -Piglit and/or +Piglit and/or dEQP to check for regressions.

+As mentioned at the begining, 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: +

+$ git rebase --interactive --exec "meson test -C build/" origin/master
+

+replacing "meson test" with whatever other test you want to +run. +

+ -

Mailing Patches

Submitting Patches

-Patches should be sent to the mesa-dev mailing list for review: +Patches may be submitted to the Mesa project by +email or with a +GitLab merge request. To prevent +duplicate code review, only use one method to submit your changes. +

+ +

Mailing Patches

+ +

+Patches may be sent to the mesa-dev mailing list for review: mesa-dev@lists.freedesktop.org. When submitting a patch make sure to use @@ -156,8 +211,85 @@ When submitting follow-up patches you should also login to state of your old patches to Superseded.

+Some companies' mail server automatically append a legal disclaimer, +usually containing something along the lines of "The information in this +email is confidential" and "distribution is strictly prohibited". +

+These legal notices prevent us from being able to accept your patch, +rendering the whole process pointless. Please make sure these are +disabled before sending your patches. (Note that you may need to contact +your email administrator for this.) +

+ +

GitLab Merge Requests

+ +

+ GitLab Merge + Requests (MR) can also be used to submit patches for Mesa. +

+ +

+ If the MR may have interest for most of the Mesa community, you can + send an email to the mesa-dev email list including a link to the MR. + Don't send the patch to mesa-dev, just the MR link. +

+ Add labels to your MR to help reviewers find it. For example: +

Mesa changes affecting all drivers: mesa +
Hardware vendor specific code: amd, intel, nvidia, ... +
Driver specific code: anvil, freedreno, i965, iris, radeonsi, + radv, vc4, ... +
Other tag examples: gallium, util +

+ Tick the following when creating the MR. It allows developers to + rebase your work on top of master. +

Allow commits from members who can merge to the target branch

+ If you revise your patches based on code review and push an update + to your branch, you should maintain a clean history + in your patches. There should not be "fixup" patches in the history. + The series should be buildable and functional after every commit + whenever you push the branch. +

+ It is your responsibility to keep the MR alive and making progress, + as there are no guarantees that a Mesa dev will independently take + interest in it. +

+ Some other notes: +

Make changes and update your branch based on feedback +
After an update, for the feedback you handled, close the + feedback discussion with the "Resolve Discussion" button. This way + the reviewers know which feedback got handled and which didn't. +
Old, stale MR may be closed, but you can reopen it if you + still want to pursue the changes +
You should periodically check to see if your MR needs to be + rebased +
Make sure your MR is closed if your patches get pushed outside + of GitLab +
Please send MRs from a personal fork rather than from the main + Mesa repository, as it clutters it unnecessarily. +

Reviewing Patches

+ To participate in code review, you should monitor the + + mesa-dev email list and the GitLab + Mesa Merge + Requests page. +

When you've reviewed a patch on the mailing list, please be unambiguous about your review. That is, state either @@ -184,11 +316,34 @@ which tells the patch author that the patch can be committed, as long as the issues are resolved first.

+These Reviewed-by, Acked-by, and Tested-by tags should also be amended +into commits in a MR before it is merged. +

+ +

+When providing a Reviewed-by, Acked-by, or Tested-by tag in a gitlab MR, +enclose the tag in backticks: +

+  `Reviewed-by: Joe Hacker <jhacker@example.com>`

+This is the markdown format for literal, and will prevent gitlab from hiding +the < and > symbols. +

+ +

+Review by non-experts is encouraged. Understanding how someone else +goes about solving a problem is a great way to learn your way around +the project. The submitter is expected to evaluate whether they have +an appropriate amount of review feedback from people who also +understand the code before merging their patches. +

Nominating a commit for a stable branch

-There are three ways to nominate patch for inclusion of the stable branch and +There are three ways to nominate a patch for inclusion in the stable branch and release.

not

+If you are not the author of the original patch, please Cc: them in your +nomination request. +

+The current patch status can be observed in the staging branch. +

The stable tag

Here are some examples of such a note:

CC: <mesa-stable@lists.freedesktop.org>
CC: "9.2 10.0" <mesa-stable@lists.freedesktop.org>
CC: "10.0" <mesa-stable@lists.freedesktop.org>

+CC: <mesa-stable@lists.freedesktop.org>
+

+Note: by removing the tag [as the commit is pushed] the patch is +explicitly rejected from inclusion in the stable branch(es). +Thus, drop the line only if you want to cancel the nomination. +

Criteria for accepting patches to the stable branch

Patch must conform with the Basic guidelines
Patch must have landed in master 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. -The stable-release manager will work with the list of nominated patches, and -for each patch that meets the crtieria below will cherry-pick the patch with: -git cherry-pick -x <commit>. The -x option is -important so that the picked patch references the comit ID of the original -patch. + Note: If the regression is due to faulty piglit/dEQP/CTS/other test the + latter must be fixed first. A reference to the offending test(s) and + respective fix(es) should be provided in the nominated patch.
Patch cannot be larger than 100 lines.
Patches that move code around with no functional change should be + rejected.
Patch must be a bug fix and not a new feature. + + Note: An exception to this rule, are hardware-enabling "features". For + example, backports of new code to support a + newly-developed hardware product can be accepted if they can be reasonably + determined not to have effects on other hardware.
Patch must be reviewed, For example, the commit message has Reviewed-by, + Signed-off-by, or Tested-by tags from someone but the author.
Performance patches are considered only if they provide information + about the hardware, program in question and observed improvement. Use numbers + to represent your measurements.

cherry-picked

pre-release

Sending backports for the stable branch

+By default merge conflicts are resolved by the stable-release manager. In which +case he/she should provide a comment about the changes required, alongside the +Conflicts section. Summary of which will be provided in the +pre-release announcement. +

+Developers are interested in sending backports are recommended to use either a +[BACKPORT #branch] subject prefix or provides similar information +within the commit summary. +

Git tips

Patch introduces a regression. Any reported build breakage or other - regression caused by a particular patch, (game no longer work, piglit test - changes from PASS to FAIL), is justification for rejecting a patch.
Patch is too large, (say, larger than 100 lines)
Patch is not a fix. For example, a commit that moves code around with no - functional change should be rejected.
Patch fix is not clearly described. For example, a commit message - of only a single line, no description of the bug, no mention of bugzilla, - etc.
Patch has not obviously been reviewed, For example, the commit message - has no Reviewed-by, Signed-off-by, nor Tested-by tags from anyone but the - author.
Patch has not already been merged to the master branch. As a rule, bug - fixes should never be applied first to a stable branch. Patches should land - first on the master branch and then be cherry-picked to a stable - branch. (This is to avoid future releases causing regressions if the patch - is not also applied to master.) The only things that might look like - exceptions would be backports of patches from master that happen to look - significantly different.
Patch depends on too many other patches. Ideally, all stable-branch - patches should be self-contained. It sometimes occurs that a single, logical - bug-fix occurs as two separate patches on master, (such as an original - patch, then a subsequent fix-up to that patch). In such a case, these two - patches should be squashed into a single, self-contained patch for the - stable branch. (Of course, if the squashing makes the patch too large, then - that could be a reason to reject the patch.)
Patch includes new feature development, not bug fixes. New OpenGL - features, extensions, etc. should be applied to Mesa master and included in - the next major release. Stable releases are intended only for bug fixes. - - Note: As an exception to this rule, the stable-release manager may accept - hardware-enabling "features". For example, backports of new code to support - a newly-developed hardware product can be accepted if they can be reasonably - determined to not have effects on other hardware.
Patch is a performance optimization. As a rule, performance patches are - not candidates for the stable branch. The only exception might be a case - where an application's performance was recently severely impacted so as to - become unusable. The fix for this performance regression could then be - considered for a stable branch. The optimization must also be - non-controversial and the patches still need to meet the other criteria of - being simple and self-contained
Patch introduces a new failure mode (such as an assert). While the new - assert might technically be correct, for example to make Mesa more - conformant, this is not the kind of "bug fix" we want in a stable - release. The potential problem here is that an OpenGL program that was - previously working, (even if technically non-compliant with the - specification), could stop working after this patch. So that would be a - regression that is unaacceptable for the stable branch.
git rebase -i ... is your friend. Don't be afraid to use it. +

Apply a fixup to commit FOO. +

+    git add ...
+    git commit --fixup=FOO
+    git rebase -i --autosquash ...
+

Test for build breakage between patches e.g last 8 commits. +
```
+    git rebase -i --exec="ninja -C build/" HEAD~8
+
```
+

Sets the default mailing address for your repo. +

+    git config --local sendemail.to mesa-dev@lists.freedesktop.org
+

Add version to subject line of patch series in this case for the last 8 +commits before sending. +

+    git send-email --subject-prefix="PATCH v4" HEAD~8
+    git send-email -v4 @~8 # shorter version, inherited from git format-patch
+

Configure git to use the get_reviewer.pl script interactively. Thus you +can avoid adding the world to the CC list. +
```
+    git config sendemail.cccmd "./scripts/get_reviewer.pl -i"
+
```

The Mesa 3D Graphics Library

Submitting patches

Submitting Patches

Basic guidelines

Mailing Patches

Submitting Patches

Mailing Patches

GitLab Merge Requests

Reviewing Patches

Nominating a commit for a stable branch

The stable tag

Criteria for accepting patches to the stable branch

Sending backports for the stable branch

Git tips