1b8e80941Smrg<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> 2b8e80941Smrg<html lang="en"> 3b8e80941Smrg<head> 4b8e80941Smrg <meta http-equiv="content-type" content="text/html; charset=utf-8"> 5b8e80941Smrg <title>Submitting patches</title> 6b8e80941Smrg <link rel="stylesheet" type="text/css" href="mesa.css"> 7b8e80941Smrg</head> 8b8e80941Smrg<body> 9b8e80941Smrg 10b8e80941Smrg<div class="header"> 11b8e80941Smrg <h1>The Mesa 3D Graphics Library</h1> 12b8e80941Smrg</div> 13b8e80941Smrg 14b8e80941Smrg<iframe src="contents.html"></iframe> 15b8e80941Smrg<div class="content"> 16b8e80941Smrg 17b8e80941Smrg<h1>Submitting patches</h1> 18b8e80941Smrg 19b8e80941Smrg 20b8e80941Smrg<ul> 21b8e80941Smrg<li><a href="#guidelines">Basic guidelines</a> 22b8e80941Smrg<li><a href="#formatting">Patch formatting</a> 23b8e80941Smrg<li><a href="#testing">Testing Patches</a> 24b8e80941Smrg<li><a href="#submit">Submitting Patches</a> 25b8e80941Smrg<li><a href="#reviewing">Reviewing Patches</a> 26b8e80941Smrg<li><a href="#nominations">Nominating a commit for a stable branch</a> 27b8e80941Smrg<li><a href="#criteria">Criteria for accepting patches to the stable branch</a> 28b8e80941Smrg<li><a href="#backports">Sending backports for the stable branch</a> 29b8e80941Smrg<li><a href="#gittips">Git tips</a> 30b8e80941Smrg</ul> 31b8e80941Smrg 32b8e80941Smrg<h2 id="guidelines">Basic guidelines</h2> 33b8e80941Smrg 34b8e80941Smrg<ul> 35b8e80941Smrg<li>Patches should not mix code changes with code formatting changes (except, 36b8e80941Smrgperhaps, in very trivial cases.) 37b8e80941Smrg<li>Code patches should follow Mesa 38b8e80941Smrg<a href="codingstyle.html" target="_parent">coding conventions</a>. 39b8e80941Smrg<li>Whenever possible, patches should only affect individual Mesa/Gallium 40b8e80941Smrgcomponents. 41b8e80941Smrg<li>Patches should never introduce build breaks and should be bisectable (see 42b8e80941Smrg<code>git bisect</code>.) 43b8e80941Smrg<li>Patches should be properly <a href="#formatting">formatted</a>. 44b8e80941Smrg<li>Patches should be sufficiently <a href="#testing">tested</a> before submitting. 45b8e80941Smrg<li>Patches should be <a href="#submit">submitted</a> 46b8e80941Smrgto <a href="#mailing">mesa-dev</a> or with 47b8e80941Smrga <a href="#merge-request">merge request</a> 48b8e80941Smrgfor <a href="#reviewing">review</a>. 49b8e80941Smrg 50b8e80941Smrg</ul> 51b8e80941Smrg 52b8e80941Smrg<h2 id="formatting">Patch formatting</h2> 53b8e80941Smrg 54b8e80941Smrg<ul> 55b8e80941Smrg<li>Lines should be limited to 75 characters or less so that git logs 56b8e80941Smrgdisplayed in 80-column terminals avoid line wrapping. Note that git 57b8e80941Smrglog uses 4 spaces of indentation (4 + 75 < 80). 58b8e80941Smrg<li>The first line should be a short, concise summary of the change prefixed 59b8e80941Smrgwith a module name. Examples: 60b8e80941Smrg<pre> 61b8e80941Smrg mesa: Add support for querying GL_VERTEX_ATTRIB_ARRAY_LONG 62b8e80941Smrg 63b8e80941Smrg gallium: add PIPE_CAP_DEVICE_RESET_STATUS_QUERY 64b8e80941Smrg 65b8e80941Smrg i965: Fix missing type in local variable declaration. 66b8e80941Smrg</pre> 67b8e80941Smrg<li>Subsequent patch comments should describe the change in more detail, 68b8e80941Smrgif needed. For example: 69b8e80941Smrg<pre> 70b8e80941Smrg i965: Remove end-of-thread SEND alignment code. 71b8e80941Smrg 72b8e80941Smrg This was present in Eric's initial implementation of the compaction code 73b8e80941Smrg for Sandybridge (commit 077d01b6). There is no documentation saying this 74b8e80941Smrg is necessary, and removing it causes no regressions in piglit on any 75b8e80941Smrg platform. 76b8e80941Smrg</pre> 77b8e80941Smrg<li>A "Signed-off-by:" line is not required, but not discouraged either. 78b8e80941Smrg<li>If a patch addresses a bugzilla issue, that should be noted in the 79b8e80941Smrgpatch comment. For example: 80b8e80941Smrg<pre> 81b8e80941Smrg Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89689 82b8e80941Smrg</pre> 83b8e80941Smrg<li>If a patch addresses a issue introduced with earlier commit, that should be 84b8e80941Smrgnoted in the patch comment. For example: 85b8e80941Smrg<pre> 86b8e80941Smrg Fixes: d7b3707c612 "util/disk_cache: use stat() to check if entry is a directory" 87b8e80941Smrg</pre> 88b8e80941Smrg<li>If there have been several revisions to a patch during the review 89b8e80941Smrgprocess, they should be noted such as in this example: 90b8e80941Smrg<pre> 91b8e80941Smrg st/mesa: add ARB_texture_stencil8 support (v4) 92b8e80941Smrg 93b8e80941Smrg if we support stencil texturing, enable texture_stencil8 94b8e80941Smrg there is no requirement to support native S8 for this, 95b8e80941Smrg the texture can be converted to x24s8 fine. 96b8e80941Smrg 97b8e80941Smrg v2: fold fixes from Marek in: 98b8e80941Smrg a) put S8 last in the list 99b8e80941Smrg b) fix renderable to always test for d/s renderable 100b8e80941Smrg fixup the texture case to use a stencil only format 101b8e80941Smrg for picking the format for the texture view. 102b8e80941Smrg v3: hit fallback for getteximage 103b8e80941Smrg v4: put s8 back in front, it shouldn't get picked now (Ilia) 104b8e80941Smrg</pre> 105b8e80941Smrg<li>If someone tested your patch, document it with a line like this: 106b8e80941Smrg<pre> 107b8e80941Smrg Tested-by: Joe Hacker <jhacker@foo.com> 108b8e80941Smrg</pre> 109b8e80941Smrg<li>If the patch was reviewed (usually the case) or acked by someone, 110b8e80941Smrgthat should be documented with: 111b8e80941Smrg<pre> 112b8e80941Smrg Reviewed-by: Joe Hacker <jhacker@foo.com> 113b8e80941Smrg Acked-by: Joe Hacker <jhacker@foo.com> 114b8e80941Smrg</pre> 115b8e80941Smrg<li>If sending later revision of a patch, add all the tags - ack, r-b, 116b8e80941SmrgCc: mesa-stable and/or other. This provides reviewers with quick feedback if the 117b8e80941Smrgpatch has already been reviewed. 118b8e80941Smrg<li>In order for your patch to reach the prospective reviewer easier/faster, 119b8e80941Smrguse the script scripts/get_reviewer.pl to get a list of individuals and include 120b8e80941Smrgthem in the CC list. 121b8e80941Smrg<br> 122b8e80941SmrgPlease use common sense and do <strong>not</strong> blindly add everyone. 123b8e80941Smrg<br> 124b8e80941Smrg<pre> 125b8e80941Smrg $ scripts/get_reviewer.pl --help # to get the help screen 126b8e80941Smrg $ scripts/get_reviewer.pl -f src/egl/drivers/dri2/platform_android.c 127b8e80941Smrg Rob Herring <robh@kernel.org> (reviewer:ANDROID EGL SUPPORT,added_lines:188/700=27%,removed_lines:58/283=20%) 128b8e80941Smrg Tomasz Figa <tfiga@chromium.org> (reviewer:ANDROID EGL SUPPORT,authored:12/41=29%,added_lines:308/700=44%,removed_lines:115/283=41%) 129b8e80941Smrg Emil Velikov <emil.l.velikov@gmail.com> (authored:13/41=32%,removed_lines:76/283=27%) 130b8e80941Smrg</pre> 131b8e80941Smrg</ul> 132b8e80941Smrg 133b8e80941Smrg 134b8e80941Smrg 135b8e80941Smrg<h2 id="testing">Testing Patches</h2> 136b8e80941Smrg 137b8e80941Smrg<p> 138b8e80941SmrgIt should go without saying that patches must be tested. In general, 139b8e80941Smrgdo whatever testing is prudent. 140b8e80941Smrg</p> 141b8e80941Smrg 142b8e80941Smrg<p> 143b8e80941SmrgYou should always run the Mesa test suite before submitting patches. 144b8e80941SmrgThe test suite can be run using the 'meson test' command. All tests 145b8e80941Smrgmust pass before patches will be accepted, this may mean you have 146b8e80941Smrgto update the tests themselves. 147b8e80941Smrg</p> 148b8e80941Smrg 149b8e80941Smrg<p> 150b8e80941SmrgWhenever possible and applicable, test the patch with 151b8e80941Smrg<a href="https://piglit.freedesktop.org">Piglit</a> and/or 152b8e80941Smrg<a href="https://android.googlesource.com/platform/external/deqp/">dEQP</a> 153b8e80941Smrgto check for regressions. 154b8e80941Smrg</p> 155b8e80941Smrg 156b8e80941Smrg<p> 157b8e80941SmrgAs mentioned at the begining, patches should be bisectable. 158b8e80941SmrgA good way to test this is to make use of the `git rebase` command, 159b8e80941Smrgto run your tests on each commit. Assuming your branch is based off 160b8e80941Smrg<code>origin/master</code>, you can run: 161b8e80941Smrg</p> 162b8e80941Smrg<pre> 163b8e80941Smrg$ git rebase --interactive --exec "meson test -C build/" origin/master 164b8e80941Smrg</pre> 165b8e80941Smrg<p> 166b8e80941Smrgreplacing <code>"meson test"</code> with whatever other test you want to 167b8e80941Smrgrun. 168b8e80941Smrg</p> 169b8e80941Smrg 170b8e80941Smrg 171b8e80941Smrg<h2 id="submit">Submitting Patches</h2> 172b8e80941Smrg 173b8e80941Smrg<p> 174b8e80941SmrgPatches may be submitted to the Mesa project by 175b8e80941Smrg<a href="#mailing">email</a> or with a 176b8e80941SmrgGitLab <a href="#merge-request">merge request</a>. To prevent 177b8e80941Smrgduplicate code review, only use one method to submit your changes. 178b8e80941Smrg</p> 179b8e80941Smrg 180b8e80941Smrg<h3 id="mailing">Mailing Patches</h3> 181b8e80941Smrg 182b8e80941Smrg<p> 183b8e80941SmrgPatches may be sent to the mesa-dev mailing list for review: 184b8e80941Smrg<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev"> 185b8e80941Smrgmesa-dev@lists.freedesktop.org</a>. 186b8e80941SmrgWhen submitting a patch make sure to use 187b8e80941Smrg<a href="https://git-scm.com/docs/git-send-email">git send-email</a> 188b8e80941Smrgrather than attaching patches to emails. Sending patches as 189b8e80941Smrgattachments prevents people from being able to provide in-line review 190b8e80941Smrgcomments. 191b8e80941Smrg</p> 192b8e80941Smrg 193b8e80941Smrg<p> 194b8e80941SmrgWhen submitting follow-up patches you can use --in-reply-to to make v2, v3, 195b8e80941Smrgetc patches show up as replies to the originals. This usually works well 196b8e80941Smrgwhen you're sending out updates to individual patches (as opposed to 197b8e80941Smrgre-sending the whole series). Using --in-reply-to makes 198b8e80941Smrgit harder for reviewers to accidentally review old patches. 199b8e80941Smrg</p> 200b8e80941Smrg 201b8e80941Smrg<p> 202b8e80941SmrgWhen submitting follow-up patches you should also login to 203b8e80941Smrg<a href="https://patchwork.freedesktop.org">patchwork</a> and change the 204b8e80941Smrgstate of your old patches to Superseded. 205b8e80941Smrg</p> 206b8e80941Smrg 207b8e80941Smrg<p> 208b8e80941SmrgSome companies' mail server automatically append a legal disclaimer, 209b8e80941Smrgusually containing something along the lines of "The information in this 210b8e80941Smrgemail is confidential" and "distribution is strictly prohibited".<br/> 211b8e80941SmrgThese legal notices prevent us from being able to accept your patch, 212b8e80941Smrgrendering the whole process pointless. Please make sure these are 213b8e80941Smrgdisabled before sending your patches. (Note that you may need to contact 214b8e80941Smrgyour email administrator for this.) 215b8e80941Smrg</p> 216b8e80941Smrg 217b8e80941Smrg<h3 id="merge-request">GitLab Merge Requests</h3> 218b8e80941Smrg 219b8e80941Smrg<p> 220b8e80941Smrg <a href="https://gitlab.freedesktop.org/mesa/mesa">GitLab</a> Merge 221b8e80941Smrg Requests (MR) can also be used to submit patches for Mesa. 222b8e80941Smrg</p> 223b8e80941Smrg 224b8e80941Smrg<p> 225b8e80941Smrg If the MR may have interest for most of the Mesa community, you can 226b8e80941Smrg send an email to the mesa-dev email list including a link to the MR. 227b8e80941Smrg Don't send the patch to mesa-dev, just the MR link. 228b8e80941Smrg</p> 229b8e80941Smrg<p> 230b8e80941Smrg Add labels to your MR to help reviewers find it. For example: 231b8e80941Smrg</p> 232b8e80941Smrg<ul> 233b8e80941Smrg <li>Mesa changes affecting all drivers: mesa 234b8e80941Smrg <li>Hardware vendor specific code: amd, intel, nvidia, ... 235b8e80941Smrg <li>Driver specific code: anvil, freedreno, i965, iris, radeonsi, 236b8e80941Smrg radv, vc4, ... 237b8e80941Smrg <li>Other tag examples: gallium, util 238b8e80941Smrg</ul> 239b8e80941Smrg<p> 240b8e80941Smrg Tick the following when creating the MR. It allows developers to 241b8e80941Smrg rebase your work on top of master. 242b8e80941Smrg</p> 243b8e80941Smrg<pre>Allow commits from members who can merge to the target branch</pre> 244b8e80941Smrg<p> 245b8e80941Smrg If you revise your patches based on code review and push an update 246b8e80941Smrg to your branch, you should maintain a <strong>clean</strong> history 247b8e80941Smrg in your patches. There should not be "fixup" patches in the history. 248b8e80941Smrg The series should be buildable and functional after every commit 249b8e80941Smrg whenever you push the branch. 250b8e80941Smrg</p> 251b8e80941Smrg<p> 252b8e80941Smrg It is your responsibility to keep the MR alive and making progress, 253b8e80941Smrg as there are no guarantees that a Mesa dev will independently take 254b8e80941Smrg interest in it. 255b8e80941Smrg</p> 256b8e80941Smrg<p> 257b8e80941Smrg Some other notes: 258b8e80941Smrg</p> 259b8e80941Smrg<ul> 260b8e80941Smrg <li>Make changes and update your branch based on feedback 261b8e80941Smrg <li>Old, stale MR may be closed, but you can reopen it if you 262b8e80941Smrg still want to pursue the changes 263b8e80941Smrg <li>You should periodically check to see if your MR needs to be 264b8e80941Smrg rebased 265b8e80941Smrg <li>Make sure your MR is closed if your patches get pushed outside 266b8e80941Smrg of GitLab 267b8e80941Smrg <li>Please send MRs from a personal fork rather than from the main 268b8e80941Smrg Mesa repository, as it clutters it unnecessarily. 269b8e80941Smrg</ul> 270b8e80941Smrg 271b8e80941Smrg<h2 id="reviewing">Reviewing Patches</h2> 272b8e80941Smrg 273b8e80941Smrg<p> 274b8e80941Smrg To participate in code review, you should monitor the 275b8e80941Smrg <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev"> 276b8e80941Smrg mesa-dev</a> email list and the GitLab 277b8e80941Smrg Mesa <a href="https://gitlab.freedesktop.org/mesa/mesa/merge_requests">Merge 278b8e80941Smrg Requests</a> page. 279b8e80941Smrg</p> 280b8e80941Smrg 281b8e80941Smrg<p> 282b8e80941SmrgWhen you've reviewed a patch on the mailing list, please be unambiguous 283b8e80941Smrgabout your review. That is, state either 284b8e80941Smrg</p> 285b8e80941Smrg<pre> 286b8e80941Smrg Reviewed-by: Joe Hacker <jhacker@foo.com> 287b8e80941Smrg</pre> 288b8e80941Smrgor 289b8e80941Smrg<pre> 290b8e80941Smrg Acked-by: Joe Hacker <jhacker@foo.com> 291b8e80941Smrg</pre> 292b8e80941Smrg<p> 293b8e80941SmrgRather than saying just "LGTM" or "Seems OK". 294b8e80941Smrg</p> 295b8e80941Smrg 296b8e80941Smrg<p> 297b8e80941SmrgIf small changes are suggested, it's OK to say something like: 298b8e80941Smrg</p> 299b8e80941Smrg<pre> 300b8e80941Smrg With the above fixes, Reviewed-by: Joe Hacker <jhacker@foo.com> 301b8e80941Smrg</pre> 302b8e80941Smrg<p> 303b8e80941Smrgwhich tells the patch author that the patch can be committed, as long 304b8e80941Smrgas the issues are resolved first. 305b8e80941Smrg</p> 306b8e80941Smrg 307b8e80941Smrg<p> 308b8e80941SmrgThese Reviewed-by, Acked-by, and Tested-by tags should also be amended 309b8e80941Smrginto commits in a MR before it is merged. 310b8e80941Smrg</p> 311b8e80941Smrg 312b8e80941Smrg<p> 313b8e80941SmrgWhen providing a Reviewed-by, Acked-by, or Tested-by tag in a gitlab MR, 314b8e80941Smrgenclose the tag in backticks: 315b8e80941Smrg</p> 316b8e80941Smrg<pre> 317b8e80941Smrg `Reviewed-by: Joe Hacker <jhacker@example.com>`</pre> 318b8e80941Smrg<p> 319b8e80941SmrgThis is the markdown format for literal, and will prevent gitlab from hiding 320b8e80941Smrgthe < and > symbols. 321b8e80941Smrg</p> 322b8e80941Smrg 323b8e80941Smrg<p> 324b8e80941SmrgReview by non-experts is encouraged. Understanding how someone else 325b8e80941Smrggoes about solving a problem is a great way to learn your way around 326b8e80941Smrgthe project. The submitter is expected to evaluate whether they have 327b8e80941Smrgan appropriate amount of review feedback from people who also 328b8e80941Smrgunderstand the code before merging their patches. 329b8e80941Smrg</p> 330b8e80941Smrg 331b8e80941Smrg<h2 id="nominations">Nominating a commit for a stable branch</h2> 332b8e80941Smrg 333b8e80941Smrg<p> 334b8e80941SmrgThere are three ways to nominate a patch for inclusion in the stable branch and 335b8e80941Smrgrelease. 336b8e80941Smrg</p> 337b8e80941Smrg<ul> 338b8e80941Smrg<li> By adding the Cc: mesa-stable@ tag as described below. 339b8e80941Smrg<li> Sending the commit ID (as seen in master branch) to the mesa-stable@ mailing list. 340b8e80941Smrg<li> Forwarding the patch from the mesa-dev@ mailing list. 341b8e80941Smrg</li> 342b8e80941Smrg</ul> 343b8e80941Smrg<p> 344b8e80941SmrgNote: resending patch identical to one on mesa-dev@ or one that differs only 345b8e80941Smrgby the extra mesa-stable@ tag is <strong>not</strong> recommended. 346b8e80941Smrg</p> 347b8e80941Smrg<p> 348b8e80941SmrgIf you are not the author of the original patch, please Cc: them in your 349b8e80941Smrgnomination request. 350b8e80941Smrg</p> 351b8e80941Smrg 352b8e80941Smrg<p> 353b8e80941SmrgThe current patch status can be observed in the <a href="releasing.html#stagingbranch">staging branch</a>. 354b8e80941Smrg</p> 355b8e80941Smrg 356b8e80941Smrg<h3 id="thetag">The stable tag</h3> 357b8e80941Smrg 358b8e80941Smrg<p> 359b8e80941SmrgIf you want a commit to be applied to a stable branch, 360b8e80941Smrgyou should add an appropriate note to the commit message. 361b8e80941Smrg</p> 362b8e80941Smrg 363b8e80941Smrg<p> 364b8e80941SmrgHere are some examples of such a note: 365b8e80941Smrg</p> 366b8e80941Smrg<ul> 367b8e80941Smrg <li>CC: <mesa-stable@lists.freedesktop.org></li> 368b8e80941Smrg</ul> 369b8e80941Smrg 370b8e80941SmrgSimply adding the CC to the mesa-stable list address is adequate to nominate 371b8e80941Smrgthe commit for all the active stable branches. If the commit is not applicable 372b8e80941Smrgfor said branch the stable-release manager will reply stating so. 373b8e80941Smrg 374b8e80941SmrgThis "CC" syntax for patch nomination will cause patches to automatically be 375b8e80941Smrgcopied to the mesa-stable@ mailing list when you use "git send-email" to send 376b8e80941Smrgpatches to the mesa-dev@ mailing list. If you prefer using --suppress-cc that 377b8e80941Smrgwon't have any negative effect on the patch nomination. 378b8e80941Smrg 379b8e80941Smrg<p> 380b8e80941SmrgNote: by removing the tag [as the commit is pushed] the patch is 381b8e80941Smrg<strong>explicitly</strong> rejected from inclusion in the stable branch(es). 382b8e80941Smrg<br> 383b8e80941SmrgThus, drop the line <strong>only</strong> if you want to cancel the nomination. 384b8e80941Smrg</p> 385b8e80941Smrg 386b8e80941SmrgAlternatively, if one uses the "Fixes" tag as described in the "Patch formatting" 387b8e80941Smrgsection, it nominates a commit for all active stable branches that include the 388b8e80941Smrgcommit that is referred to. 389b8e80941Smrg 390b8e80941Smrg<h2 id="criteria">Criteria for accepting patches to the stable branch</h2> 391b8e80941Smrg 392b8e80941SmrgMesa has a designated release manager for each stable branch, and the release 393b8e80941Smrgmanager is the only developer that should be pushing changes to these branches. 394b8e80941SmrgEveryone else should nominate patches using the mechanism described above. 395b8e80941Smrg 396b8e80941SmrgThe following rules define which patches are accepted and which are not. The 397b8e80941Smrgstable-release manager is also given broad discretion in rejecting patches 398b8e80941Smrgthat have been nominated. 399b8e80941Smrg 400b8e80941Smrg<ul> 401b8e80941Smrg <li>Patch must conform with the <a href="#guidelines">Basic guidelines</a></li> 402b8e80941Smrg 403b8e80941Smrg <li>Patch must have landed in master first. In case where the original 404b8e80941Smrg patch is too large and/or otherwise contradicts with the rules set within, a 405b8e80941Smrg backport is appropriate.</li> 406b8e80941Smrg 407b8e80941Smrg <li>It must not introduce a regression - be that build or runtime wise. 408b8e80941Smrg 409b8e80941Smrg Note: If the regression is due to faulty piglit/dEQP/CTS/other test the 410b8e80941Smrg latter must be fixed first. A reference to the offending test(s) and 411b8e80941Smrg respective fix(es) should be provided in the nominated patch.</li> 412b8e80941Smrg 413b8e80941Smrg <li>Patch cannot be larger than 100 lines.</li> 414b8e80941Smrg 415b8e80941Smrg <li>Patches that move code around with no functional change should be 416b8e80941Smrg rejected.</li> 417b8e80941Smrg 418b8e80941Smrg <li>Patch must be a bug fix and not a new feature. 419b8e80941Smrg 420b8e80941Smrg Note: An exception to this rule, are hardware-enabling "features". For 421b8e80941Smrg example, <a href="#backports">backports</a> of new code to support a 422b8e80941Smrg newly-developed hardware product can be accepted if they can be reasonably 423b8e80941Smrg determined not to have effects on other hardware.</li> 424b8e80941Smrg 425b8e80941Smrg <li>Patch must be reviewed, For example, the commit message has Reviewed-by, 426b8e80941Smrg Signed-off-by, or Tested-by tags from someone but the author.</li> 427b8e80941Smrg 428b8e80941Smrg <li>Performance patches are considered only if they provide information 429b8e80941Smrg about the hardware, program in question and observed improvement. Use numbers 430b8e80941Smrg to represent your measurements.</li> 431b8e80941Smrg</ul> 432b8e80941Smrg 433b8e80941SmrgIf the patch complies with the rules it will be 434b8e80941Smrg<a href="releasing.html#pickntest">cherry-picked</a>. Alternatively the release 435b8e80941Smrgmanager will reply to the patch in question stating why the patch has been 436b8e80941Smrgrejected or would request a backport. 437b8e80941Smrg 438b8e80941SmrgA summary of all the picked/rejected patches will be presented in the 439b8e80941Smrg<a href="releasing.html#prerelease">pre-release</a> announcement. 440b8e80941Smrg 441b8e80941SmrgThe stable-release manager may at times need to force-push changes to the 442b8e80941Smrgstable branches, for example, to drop a previously-picked patch that was later 443b8e80941Smrgidentified as causing a regression). These force-pushes may cause changes to 444b8e80941Smrgbe lost from the stable branch if developers push things directly. Consider 445b8e80941Smrgyourself warned. 446b8e80941Smrg 447b8e80941Smrg<h2 id="backports">Sending backports for the stable branch</h2> 448b8e80941SmrgBy default merge conflicts are resolved by the stable-release manager. In which 449b8e80941Smrgcase he/she should provide a comment about the changes required, alongside the 450b8e80941Smrg<code>Conflicts</code> section. Summary of which will be provided in the 451b8e80941Smrg<a href="releasing.html#prerelease">pre-release</a> announcement. 452b8e80941Smrg<br> 453b8e80941SmrgDevelopers are interested in sending backports are recommended to use either a 454b8e80941Smrg<code>[BACKPORT #branch]</code> subject prefix or provides similar information 455b8e80941Smrgwithin the commit summary. 456b8e80941Smrg 457b8e80941Smrg<h2 id="gittips">Git tips</h2> 458b8e80941Smrg 459b8e80941Smrg<ul> 460b8e80941Smrg<li><code>git rebase -i ...</code> is your friend. Don't be afraid to use it. 461b8e80941Smrg<li>Apply a fixup to commit FOO. 462b8e80941Smrg<pre> 463b8e80941Smrg git add ... 464b8e80941Smrg git commit --fixup=FOO 465b8e80941Smrg git rebase -i --autosquash ... 466b8e80941Smrg</pre> 467b8e80941Smrg<li>Test for build breakage between patches e.g last 8 commits. 468b8e80941Smrg<pre> 469b8e80941Smrg git rebase -i --exec="ninja -C build/" HEAD~8 470b8e80941Smrg</pre> 471b8e80941Smrg<li>Sets the default mailing address for your repo. 472b8e80941Smrg<pre> 473b8e80941Smrg git config --local sendemail.to mesa-dev@lists.freedesktop.org 474b8e80941Smrg</pre> 475b8e80941Smrg<li> Add version to subject line of patch series in this case for the last 8 476b8e80941Smrgcommits before sending. 477b8e80941Smrg<pre> 478b8e80941Smrg git send-email --subject-prefix="PATCH v4" HEAD~8 479b8e80941Smrg git send-email -v4 @~8 # shorter version, inherited from git format-patch 480b8e80941Smrg</pre> 481b8e80941Smrg<li> Configure git to use the get_reviewer.pl script interactively. Thus you 482b8e80941Smrgcan avoid adding the world to the CC list. 483b8e80941Smrg<pre> 484b8e80941Smrg git config sendemail.cccmd "./scripts/get_reviewer.pl -i" 485b8e80941Smrg</pre> 486b8e80941Smrg</ul> 487b8e80941Smrg 488b8e80941Smrg 489b8e80941Smrg</div> 490b8e80941Smrg</body> 491b8e80941Smrg</html> 492