Well, patches are not implemented faster than the developers are working. They must be approved and tested before we implement them.
But patches are of course always welcome.
The proper way to give us patches (which is easier for us to handle):- Make a clone of our dev/stable repository, and make sure you have a updated repository before starting. We prefer patches for the development branch. Patches can be ported to the stable branch if they are compatible. Important: Do not mix dev and stable repositories, they are different and incompatible branches (changes in one branch cannot just be copied to another one). If you use the console version, the command is:
hg clone <remote source repos (one of our repositories at Google Code)> <local destination folder>
- Do your work.
- Commit. You may commit multiple times if you're working on multiple stuff to separate your work into separate revisions.
hg commit -u "<your name>" -m "<short description of the work done>"
- Export what you committed to a file in unified diff format (done by default in Mercurial). It should look like this: http://en.wikipedia.org/wiki/Unified...Unified_format
hg export -o my_work.patch <my revision(s)>
- Make a new ticket in our issue tracker and attach the patch file. Also tell us which branch it's based on (dev or stable).
To do this you need Mercurial (Linux, command line tool) or TortoiseHG (Windows, GUI + command line tool) to be installed.
Again, everyone are welcome to submit fixes/features for ZR. However they have to be reviewed and approved by us before they are eventually implemented in the official version.
Update - 2010.09.20:
We hope that there are someone interesting in learning how ZR work, because we
will need more developers soon. If you are interested, do like I did and read the
entire source, file by file. There are comments in plain english that explain what the code does (mostly for beginners, but also to help us remember what the code does).
Linear Mode
