X-Git-Url: http://vcs.maemo.org/git/?a=blobdiff_plain;ds=inline;f=docs%2FCONTRIBUTING;h=a45618a8e566d62230fb41a4f0c65398a4f08c2c;hb=9ffda40a7fe43be4df100aa1e599d4556833b4ad;hp=86655dd4cffcac08d7baaa44f22ad23420acb767;hpb=870b1fda3c0093fdc9fe3e05c85173992cc7d69c;p=uzbl-mobile diff --git a/docs/CONTRIBUTING b/docs/CONTRIBUTING index 86655dd..a45618a 100644 --- a/docs/CONTRIBUTING +++ b/docs/CONTRIBUTING @@ -1,39 +1,109 @@ ### 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 +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. Have -a look at the CHECKLIST file to see all the stuff that is supposed to work. +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, 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 +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. -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. +Read on for more info... -If you're new to Git/github, have no fear: +### Clone/patch/merge workflow -* [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) +1. clone the code with git. + Either you host your git repo yourself, or use something userfriendly + like [Github](http://www.github.com) + If you want to use github, you basically just need to register and click + the fork button on [Dieterbe/uzbl](http://github.com/Dieterbe/uzbl) + If you're new to Git/github, have no fear: -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. + * [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) +2. Do your work, test it and push to your repo. It may be interesting to ask + others for input on your work. Make sure you do not develop against the + master branch! It is meant for stable, tested code. + All contributors develop in their experimental or other specific branches, + which get merged into the mainline experimental, and after QA it gets merged into the main master. -### VALGRIND PROFILING +3. If you think your code should be in the main uzbl code and meets all + requirements (see below), then ask Dieter to merge it. + + * send a mail to the mailing list with subject "`Pull request: