<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="#gittips">Git tips</a>
</ul>
<h2 id="guidelines">Basic guidelines</h2>
<code>git bisect</code>.)
<li>Patches should be properly <a href="#formatting">formatted</a>.
<li>Patches should be sufficiently <a href="#testing">tested</a> before submitting.
-<li>Patches should be submitted to <a href="#mailing">submitted to mesa-dev</a>
+<li>Patches should be submitted to <a href="#mailing">mesa-dev</a>
for <a href="#reviewing">review</a> using <code>git send-email</code>.
</ul>
Reviewed-by: Joe Hacker <jhacker@foo.com>
Acked-by: Joe Hacker <jhacker@foo.com>
</pre>
+<li>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.
+<li>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.
+<br>
+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 -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%)
+</pre>
</ul>
<p>
Patches should be sent to the mesa-dev mailing list for review:
<a href="https://lists.freedesktop.org/mailman/listinfo/mesa-dev">
-mesa-dev@lists.freedesktop.org<a/>.
+mesa-dev@lists.freedesktop.org</a>.
When submitting a patch make sure to use
<a href="https://git-scm.com/docs/git-send-email">git send-email</a>
rather than attaching patches to emails. Sending patches as
<p>
When you've reviewed a patch on the mailing list, please be unambiguous
about your review. That is, state either
+</p>
<pre>
Reviewed-by: Joe Hacker <jhacker@foo.com>
</pre>
<pre>
Acked-by: Joe Hacker <jhacker@foo.com>
</pre>
+<p>
Rather than saying just "LGTM" or "Seems OK".
</p>
<p>
If small changes are suggested, it's OK to say something like:
+</p>
<pre>
With the above fixes, Reviewed-by: Joe Hacker <jhacker@foo.com>
</pre>
+<p>
which tells the patch author that the patch can be committed, as long
as the issues are resolved first.
</p>
patches to the mesa-dev@ mailing list. If you prefer using --suppress-cc that
won't have any effect negative effect on the patch nomination.
+<p>
+Note: by removing the tag [as the commit is pushed] the patch is
+<strong>explicitly</strong> rejected from inclusion in the stable branch(es).
+<br>
+Thus, drop the line <strong>only</strong> if you want to cancel the nomination.
+</p>
+
<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
described above.
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:
+for each patch that meets the criteria below will cherry-pick the patch with:
<code>git cherry-pick -x <commit></code>. The <code>-x</code> option is
-important so that the picked patch references the comit ID of the original
+important so that the picked patch references the commit ID of the original
patch.
The stable-release manager may at times need to force-push changes to the
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.</li>
+ regression that is unacceptable for the stable branch.</li>
+</ul>
+
+<h2 id="gittips">Git tips</h2>
+
+<ul>
+<li><code>git rebase -i ...</code> is your friend. Don't be afraid to use it.
+<li>Apply a fixup to commit FOO.
+<pre>
+ git add ...
+ git commit --fixup=FOO
+ git rebase -i --autosquash ...
+</pre>
+<li>Test for build breakage between patches e.g last 8 commits.
+<pre>
+ git rebase -i --exec="make -j4" HEAD~8
+</pre>
+<li>Sets the default mailing address for your repo.
+<pre>
+ git config --local sendemail.to mesa-dev@lists.freedesktop.org
+</pre>
+<li> Add version to subject line of patch series in this case for the last 8
+commits before sending.
+<pre>
+ git send-email --subject-prefix="PATCH v4" HEAD~8
+ git send-email -v4 @~8 # shorter version, inherited from git format-patch
+</pre>
+<li> Configure git to use the get_reviewer.pl script interactively. Thus you
+can avoid adding the world to the CC list.
+<pre>
+ git config sendemail.cccmd "./scripts/get_reviewer.pl -i"
+</pre>
</ul>
projects / mesa.git / blobdiff