Table of Contents
This section describes how to send patches and additions when you don't have direct CVS access. In that case, you should send the contributions to the developer mailing list. That way, more people can test your contribution than if you send it to a specific developer. It could also happen that this developer has a lot of pending stuff, and your contribution gets delayed.
For the specifics on how to code, translate or write documentation, refer to the proper sections. Once you are done with the actual work, you have to create the patch file to send.
Have an updated cvs version of the release you are contributing to (HEAD, stable release, etc)
Make sure to run 'cvs upd' before you create the patch
If the update changes your sandbox, make sure that the changes still work
Run 'cvs diff -u' in the root directory. That should the create the patch to be applied to existing files
Inspect the patch that it does only contain your wanted changes
Make sure you write down on the email the location of each new file (The developer handling the patch will probably know how to find the correct location, but this will save her/him some precious time)
Compress the patch and any new files into a single .tar.gz file
Send to the developer mailing list, explaining the nature of the submission
The developer handling the patch should acknowledge that to the list as well, to avoid duplicate work
Keep in mind that there are times when all developers have plenty of work, or a patch should be best handled by a specific developer that may not be readily available, so be patient. Also, if you don't receive an acknowledgement after a few days, write to the list asking for the status of your patch. Subscribing to the developer mailing list would be a good idea if you are sending contributions.
|Producing Final Documents||Up||Translation|