blob: 9a2ff35f7886f9d797f8da4cdc7bdebf34ff4cf6 (
plain)
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
|
### Users
Right now, the best way to contribute to Uzbl is to use it, hang around in
our IRC channel, 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. Have
a look at the CHECKLIST file to see all the stuff that is supposed to work.
Play around with the configs and scripts and see if you can improve things.
### 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.
### VALGRIND PROFILING
$ add this to Makefile header: CFLAGS=-g
$ recompile
$ valgrind --tool=callgrind ./uzbl ....
$ kcachegrind callgrind.out.foo
|
