1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
|
### Users
Just use Uzbl, hang around in our IRC channel, try out different things and tell us when things break.
If you're feeling more adventerous, 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.
### Developers
If you don't feel like just sending bug reports, by all means dive into the
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.
### Patch/branch requirements before merging:
* patches/merges must be about one thing. If you want to work on multiple things, create new branches.
I allow exceptions for trivial typo fixes and such, but that's it.
This also implies that you also need to update your tree reguraly. Don't fall behind too much. (ie merge from Dieter)
* any change in functionality that you want merged in must also be documented.
There is a readme and some files in the 'docs' directory who should correspond to the code base at all times.
Update them, not only for end users but also for your fellow hackers.
* We recommend you finish your stuff first and then let Dieter know you want your stuff to be merged in, but
we know for bigger changes this is not always feasible. Just try to keep the merges about bigger "clean changesets".
That said, you can always ask us to check on your stuff or ask for advice.
### 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
### 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
|
