<li><a href="#reviewing">Reviewing Patches</a>
<li><a href="#nominations">Nominating a commit for a stable branch</a>
<li><a href="#criteria">Criteria for accepting patches to the stable branch</a>
+<li><a href="#backports">Sending backports for the stable branch</a>
<li><a href="#gittips">Git tips</a>
</ul>
<pre>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89689
</pre>
+<li>If a patch addresses a issue introduced with earlier commit, that should be
+noted in the patch comment. For example:
+<pre>
+ Fixes: d7b3707c612 "util/disk_cache: use stat() to check if entry is a directory"
+</pre>
<li>If there have been several revisions to a patch during the review
process, they should be noted such as in this example:
<pre>
Please use common sense and do <strong>not</strong> blindly add everyone.
<br>
<pre>
- $ scripts/get_reviewer.pl --help # to get the the help screen
+ $ 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%)
state of your old patches to Superseded.
</p>
+<p>
+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".<br/>
+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.)
+</p>
+
<h2 id="reviewing">Reviewing Patches</h2>
<p>
</p>
<ul>
<li>CC: <mesa-stable@lists.freedesktop.org></li>
- <li>CC: "9.2 10.0" <mesa-stable@lists.freedesktop.org></li>
- <li>CC: "10.0" <mesa-stable@lists.freedesktop.org></li>
</ul>
Simply adding the CC to the mesa-stable list address is adequate to nominate
-the commit for the most-recently-created stable branch. It is only necessary
-to specify a specific branch name, (such as "9.2 10.0" or "10.0" in the
-examples above), if you want to nominate the commit for an older stable
-branch. And, as in these examples, you can nominate the commit for the older
-branch in addition to the more recent branch, or nominate the commit
-exclusively for the older branch.
+the commit for all the active stable branches. If the commit is not applicable
+for said branch the stable-release manager will reply stating so.
This "CC" syntax for patch nomination will cause patches to automatically be
copied to the mesa-stable@ mailing list when you use "git send-email" to send
Thus, drop the line <strong>only</strong> if you want to cancel the nomination.
</p>
+Alternatively, if one uses the "Fixes" tag as described in the "Patch formatting"
+section, it nominates a commit for all active stable branches that include the
+commit that is referred to.
+
<h2 id="criteria">Criteria for accepting patches to the stable branch</h2>
Mesa has a designated release manager for each stable branch, and the release
<li>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.</li>
+ example, <a href="#backports">backports</a> 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.</li>
<li>Patch must be reviewed, For example, the commit message has Reviewed-by,
Signed-off-by, or Tested-by tags from someone but the author.</li>
be lost from the stable branch if developers push things directly. Consider
yourself warned.
+<h2 id="backports">Sending backports for the stable branch</h2>
+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
+<code>Conflicts</code> section. Summary of which will be provided in the
+<a href="releasing.html#prerelease">pre-release</a> announcement.
+<br>
+Developers are interested in sending backports are recommended to use either a
+<code>[BACKPORT #branch]</code> subject prefix or provides similar information
+within the commit summary.
+
<h2 id="gittips">Git tips</h2>
<ul>
projects / mesa.git / blobdiff