vcs.maemo.org Git - uzbl-mobile/blob - docs/CONTRIBUTING

   1 ### Users
   2
   3 Just use Uzbl, hang around in our IRC channel, try out different things and tell us when things break.
   4 If you're feeling more adventerous, you can use one of the development branches and give bug
   5 reports and suggestions straight to the developer in charge of that, so the
   6 same problems don't occur when they get merged into the master branch.
   7 Play around with the configs and scripts and see if you can improve things.
   8 The wiki can be a good source of inspiration.
   9
  10 ### Developers
  11
  12 If you don't feel like just sending bug reports, by all means dive into the
  13 code and clone the code to start hacking. (github makes this really easy
  14 with their "fork" concept).  But it's usually a good thing to tell us first
  15 what you want to do, to avoid unneeded or duplicate work.
  16
  17 Note that cloning and letting us pull (preferably via github) is way more
  18 workable then submitting plain patches.  Git is good in merging in branches
  19 even if the base code has changed in the meanwhile.  This does not work with
  20 patches.
  21
  22 If you're new to Git/github, have no fear:
  23
  24 * [Github guides (highly recommended)](http://github.com/guides/home)
  25 * [Guides: Fork a project and submit your modifications](http://github.com/guides/fork-a-project-and-submit-your-modifications)
  26
  27 Our convention is to develop in the *experimental* branch, and keep only stable, tested stuff in *master*.
  28 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.
  29
  30
  31 ### Patch/branch requirements before merging:
  32
  33 * patches/merges must be about one thing.  If you want to work on multiple things, create new branches.
  34   I allow exceptions for trivial typo fixes and such, but that's it.
  35   This also implies that you also need to update your tree reguraly.  Don't fall behind too much. (ie merge from Dieter)
  36 * any change in functionality that you want merged in must also be documented.
  37   There is a readme and some files in the 'docs' directory who should correspond to the code base at all times.
  38   Update them, not only for end users but also for your fellow hackers.
  39 * We recommend you finish your stuff first and then let Dieter know you want your stuff to be merged in, but
  40   we know for bigger changes this is not always feasible.  Just try to keep the merges about bigger "clean changesets".
  41
  42 That said, you can always ask us to check on your stuff or ask for advice.
  43
  44
  45 ### Valgrind profiling
  46         $ add this to Makefile header: CFLAGS=-g
  47         $ recompile
  48         $ valgrind --tool=callgrind ./uzbl ....
  49         $ kcachegrind callgrind.out.foo
  50
  51 ### Memory leak checking
  52     valgrind --tool=memcheck --leak-check=full ./uzbl
  53
  54 ### Debugging / backtraces
  55
  56 * compile with -ggdb (enabled by default on experimental tree)
  57 * run: `gdb ./uzbl`
  58 * `(gdb) run -c /path/to/config`
  59 * `bt` if it segfaults to see a backtrace
  60 * you'll find more info on the interwebs