Users

Just use Uzbl, hang around in our IRC channel, try out different things and report bugs. If you're feeling more adventurous, you can use one of the development branches and give bug reports and suggestions straight to the developer in charge of that, so the same problems don't occur when they get merged into the master branch. Play around with the configs and scripts and see if you can improve things. The wiki can be a good source of inspiration. You may also find mistakes in our documentation.

Developers

If you don't feel like just sending bug reports, you can dive into the code and start hacking. Even if you're not good at C, thanks to uzbl's 'ecosystem' of scripts there is a lot that can be done. However, it's usually a good idea to tell us first what you want to do, to avoid unneeded or duplicate work.

Read on for more info...

Clone/patch/merge workflow

  1. clone the code with git. Either you host your git repo yourself, or use something userfriendly like Github If you want to use github, you basically just need to register and click the fork button on Dieterbe/uzbl If you're new to Git/github, have no fear:
  1. Do your work, test it and push to your repo. It may be interesting to ask others for input on your work. Develop against master for small changes/fixes, experimental or a new topic branch for experimental/intrusive work.

  2. If you think your code should be in the main uzbl code and meets all requirements (see below), then ask Dieter to merge it.

This is a relatively easy, solid and transparent way to handle all requests in order.

Patch/branch requirements before merging:

Bugreporting

Bug reports are also welcome, especially the ones that come with a patch ;-) Before making a new ticket, check whether the bug is reported already. If you want to report a bug and you don't know where the problem in the code is, please supply:

Valgrind profiling

$ add this to Makefile header: CFLAGS=-g
$ recompile
$ valgrind --tool=callgrind ./uzbl ....
$ kcachegrind callgrind.out.foo

Memory leak checking

valgrind --tool=memcheck --leak-check=full ./uzbl

Writing unit tests

If you can, write a unit test for a bugfix or new functionality. Add relevant unit tests to existing .c files in tests/. Others should be made in new source files with corresponding changes to the tests/Makefile. Run all tests with make tests

Debugging / backtraces