diff options
author | Timothy Arceri <[email protected]> | 2013-09-05 02:54:00 -0600 |
---|---|---|
committer | Brian Paul <[email protected]> | 2013-09-06 07:52:18 -0600 |
commit | 238201158fd5caefb960b6b7eb5c4e92ac802f8b (patch) | |
tree | 96a58a27c61ccb3195dc4ba490b157a3f2ef7163 | |
parent | 505fad04f10eee1efdfcd8986b4d484b49d39986 (diff) |
docs: Add some notes on submitting patches
Signed-off-by: Timothy Arceri <[email protected]>
Reviewed-by: Brian Paul <[email protected]>
-rw-r--r-- | docs/devinfo.html | 23 |
1 files changed, 23 insertions, 0 deletions
diff --git a/docs/devinfo.html b/docs/devinfo.html index 4c1099c5e32..b495097c9d0 100644 --- a/docs/devinfo.html +++ b/docs/devinfo.html @@ -155,6 +155,29 @@ of <tt>bool</tt>, <tt>true</tt>, and src/mesa/state_tracker/st_glsl_to_tgsi.cpp can serve as examples. </p> +<h2>Submitting patches</h2> + +<p> +You should always run the Mesa Testsuite before submitting patches. +The Testsuite can be run using the 'make check' command. All tests +must pass before patches will be accepted, this may mean you have +to update the tests themselves. +</p> + +<p> +Patches should be sent to the Mesa mailing list for review. +When submitting a patch make sure to use git send-email rather than attaching +patches to emails. Sending patches as attachments prevents people from being +able to provide in-line review comments. +</p> + +<p> +When submitting follow-up patches you can use --in-reply-to to make v2, v3, +etc patches show up as replies to the originals. This usually works well +when you're sending out updates to individual patches (as opposed to +re-sending the whole series). Using --in-reply-to makes +it harder for reviewers to accidentally review old patches. +</p> <h2>Marking a commit as a candidate for a stable branch</h2> |