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

   1 ### Users
   2
   3 Right now, the best way to contribute to Uzbl is to use it, hang around in
   4 our IRC channel, and tell us when things break. If you're feeling more
   5 adventerous, you can use one of the development branches and give bug
   6 reports and suggestions straight to the developer in charge of that, so the
   7 same problems don't occur when they get merged into the master branch. Have
   8 a look at the CHECKLIST file to see all the stuff that is supposed to work.
   9 Play around with the configs and scripts and see if you can improve things.
  10
  11 ### Developers
  12
  13 If you don't feel like just sending bug reports, by all means dive into the
  14 code and clone the code to start hacking. (github makes this really easy
  15 with their "fork" concept).  But it's usually a good thing to tell us first
  16 what you want to do, to avoid unneeded or duplicate work.
  17
  18 Note that cloning and letting us pull (preferably via github) is way more
  19 workable then submitting plain patches.  Git is good in merging in branches
  20 even if the base code has changed in the meanwhile.  This does not work with
  21 patches.
  22
  23 If you're new to Git/github, have no fear:
  24
  25 * [Github guides (highly recommended)](http://github.com/guides/home)
  26 * [Guides: Fork a project and submit your modifications](http://github.com/guides/fork-a-project-and-submit-your-modifications)
  27
  28 Our convention is to develop in the *experimental* branch, and keep only stable, tested stuff in *master*.
  29 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.
  30
  31
  32 ### VALGRIND PROFILING
  33         $ add this to Makefile header: CFLAGS=-g
  34         $ recompile
  35         $ valgrind --tool=callgrind ./uzbl ....
  36         $ kcachegrind callgrind.out.foo