merge from Uli Schlachter: policy callback + experimental Makefile + tiny fixes

[uzbl-mobile] / docs / CONTRIBUTING

diff --git a/docs/CONTRIBUTING b/docs/CONTRIBUTING
index bd733a9..74d1b36 100644 (file)
--- a/docs/CONTRIBUTING
+++ b/docs/CONTRIBUTING
@@ -15,6 +15,18 @@ code and clone the code to start hacking. (github makes this really easy
 with their "fork" concept).  But it's usually a good thing to tell us first
 what you want to do, to avoid unneeded or duplicate work.
 
+Note that cloning and letting us pull (preferably via github) is way more
+workable then submitting plain patches.  Git is good in merging in branches
+even if the base code has changed in the meanwhile.  This does not work with
+patches.
+
+If you're new to Git/github, have no fear:
+
+* [Github guides (highly recommended)](http://github.com/guides/home)
+* [Guides: Fork a project and submit your modifications](http://github.com/guides/fork-a-project-and-submit-your-modifications)
+
+Our convention is to develop in the *experimental* branch, and keep only stable, tested stuff in *master*.
+So ideally, all contributors develop in their experimental, that gets merged into the mainline experimental, and after QA it gets merged into the main master.
 
 
 ### VALGRIND PROFILING
@@ -22,3 +34,14 @@ what you want to do, to avoid unneeded or duplicate work.
        $ recompile
        $ valgrind --tool=callgrind ./uzbl ....
        $ kcachegrind callgrind.out.foo
+
+### MEMORY LEAK CHECKING
+    valgrind --tool=memcheck --leak-check=full ./uzbl
+
+### DEBUGGING / BACKTRACES
+
+* compile with -ggdb (enabled by default on experimental tree)
+* run: `gdb ./uzbl`
+* `(gdb) run -c /path/to/config`
+* `bt` if it segfaults to see a backtrace
+* you'll find more info on the interwebs