If you have modified a package to expand its functionality or to fix a
bug, you should contribute your changes back to the community (some
licenses force you to do so, and it is generally considered immoral not to).
Before creating the patch, you must first obtain the latest sources of the
package you wish to patch from CVS by running the commands (the package
in this example is Foo_Bar):
cvs -d:pserver:cvsread@cvs.php.net:/repository login
password is phpfi
cvs -d:pserver:cvsread@cvs.php.net:/repository co pear/Foo_Bar
|
Now that you have the latest sources, you can edit the relevant file(s).
Make sure that your patch is fully compatible with the PEAR
coding
standards..
After you have finished adding/changing the code, TEST it: We will not
accept code that hasn't been carefully tested.
When you are absolutely sure the new code doesn't introduce bugs, create a
unified diff by running:
cd pear/Foo_Bar
cvs diff -u >Foo_Bar.diff |
The resulting .diff file contains your patch. This diff makes it easy
for us to see what has been changed.
Next step is to submit the patch. Send a mail to pear-dev@lists.php.net and
Cc the maintainer(s) of the package. The subject of the mail should be
prefixed with '[Patch]' to make it clear you are submitting a patch. Also
include a verbose explanation of what the patch does.
Don't forget to attach the .diff file to the mail. The maintainers of
the package are usually listed in the header of each source file. Apart
from that their email adresses are available on the package information
page on http://pear.php.net/.
Note:
If you are using Outlook or Outlook Express, please change the file
extension of the diff file to .txt, because Outlook's MIME-Type
detection depends on the file extension and attachments with a
MIME-Type not equal to text/plain will be rejected
by our mailinglist software.
Note:
If your patch does break backwards compatibility, the chances are fairly
good that the maintainers won't be happy about it. Thus you should always
try to fix a bug in a way that does not seriously change the public API.
But if there is absolutely no way to keep backwards compatibility and/or
if your patch contains a groundbraking improvement, even API changes are
fine.
