123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193 |
- Submitting Enhancements and Patches to PHP
- ==========================================
- This document describes how to submit an enhancement or patch for PHP.
- It's easy!
- You don't need any login accounts or special access to download,
- build, debug and begin submitting PHP or PECL code, tests or
- documentation. Once you've followed this README and had several
- patches accepted, commit privileges are often quickly granted.
- An excellent article to read first is:
- http:
- Online Forums
- -------------
- There are several IRC channels where PHP developers are often
- available to discuss questions. They include #php.pecl and #php.doc
- on the EFNet network and #php-dev-win on FreeNode.
- PHP Patches
- -----------
- If you are fixing broken functionality in PHP C source code first
- create a bug or identify an existing bug at http:
- bug can be used to track the patch progress and prevent your changes
- getting lost in the PHP mail archives.
- If your change is large then create a Request For Comment (RFC) page
- on http:
- and discuss it on the development mail list internals@lists.php.net.
- RFC Wiki accounts can be requested on
- http:
- be found in the EXTENSIONS file in the PHP source. Mail list
- subscription is explained on http:
- Information on PHP internal C functions is at
- http:
- Various external resources can be found on the web. A standard
- printed reference is the book "Extending and Embedding PHP" by Sara
- Golemon.
- Attach the patch to the PHP bug and consider sending a notification
- email about the change to internals@lists.php.net. Also CC the
- extension maintainer. Explain what has been changed by your patch.
- Test scripts should be included.
- Please make the mail subject prefix "[PATCH]". If attaching a patch,
- ensure it has a file extension of ".txt". This is because only MIME
- attachments of type 'text
- " style comments, not "
- - Create test scripts for use with "make test".
- - Run "make test" to check your patch doesn't break other features.
- - Rebuild PHP with --enable-debug (which will show some kinds of
- memory errors) and check the PHP and web server error logs after
- running your PHP tests.
- - Rebuild PHP with --enable-maintainer-zts to check your patch
- compiles on multi-threaded web servers.
- - Review the patch once more just before submitting it.
- What happens after submitting your PHP, PHP Documentation or PECL patch
- -----------------------------------------------------------------------
- If your patch is easy to review and obviously has no side-effects,
- it might be committed relatively quickly.
- Because PHP is a volunteer-driven effort more complex patches will
- require patience on your side. If you do not receive feedback in a
- few days, consider resubmitting the patch. Before doing this think
- about these questions:
- - Did I send the patch to the right mail list?
- - Did I review the mail list archives to see if these kind of
- changes had been discussed before?
- - Did I explain my patch clearly?
- - Is my patch too hard to review? Because of what factors?
- What happens when your PHP or PECL patch is applied
- ---------------------------------------------------
- Your name will likely be included in the Git commit log. If your
- patch affects end users, a brief description and your name might be
- added to the NEWS file.
- Thank you for patching PHP!
|