A 45 minute talk I gave on 7/22/2009 for OSCAMP. It focused not only on how the pear proposal process works, but also when it does and does not make sense to publish your software through PEAR.

1. Contributing to PEAR
DOs and DON’Ts
by Bill Shupp
OSCAMP 2009

2. Why publish via PEAR?
• Well known distribution channel
• Lots of reusable dependencies
• Package manager
• Peer review (CS / Tests, OO Design)
• Supportive community (lists, irc, PEPr)

4. When to use PEAR for
distribution?
• Libraries (pear.php.net)
• Full applications/frameworks (channels)

5. When NOT to use
PEAR for distribution?
• Lots of components that change very frequently
• Complex package manager (PEAR, not Pyrus)

6. How to contribute
• To existing packages
• Bug fixes, feature requests/patches
• New packages
• Formal proposal process (PEPr)

7. Proposal Step 1:
Prerequisites
• Choose a name/category
• Description
• License
• Documentation/Examples
• List dependencies (pci)

8. Proposal Step 2:
Initiate a discussion
• Listen to feedback from the list.
(Remember, these are the folks that
will be voting on your package.)

9. Proposal Step 3:
Using PEPr
• Request a developer account (first time only)
• Formally propose package
• Respond to comments
• Call for votes (sum of 5 required)
• Profit!

10. Take-aways
• Tools for CS compliance
• Tools for testing

11. Coding Standards
• PHP_CodeSniffer
• Custom standards
• phpcs --standard=Digg

12. Testing Tips
Sample phpunit wrapper

13. Example Test Call

14. Example coverage report

15. Questions?

16. Thanks!
bill@shupp.org
http://pear.php.net/user/shupp