This document aims at providing a comprehensive sum up of what was said and decided at the PEAR meeting which took place on Friday, 10th, May 2003 in Amsterdam.
For the record it should be noted that some people were attending this meeting in person while many others were participating via IRC and listening/watching video and audio streams. We would like to thank Jeroen Houben from Terenafor providing the facilities.
The following topics were discussed (in no particular order): Quality, Documentation, PFC (PEAR Foundation Classes), PEAR on windows, PEAR Installer, PEAR Website, PHP 5, Promotion, Future developments.
The following list explains every point in detail.
A QA team will be formed. It will make sure that quality standards are met. Those standards have yet to be defined more precisely; they should be measurable. They include the following minimum requirements: inline PHPDoc comments, proper summary of the package purpose and a detailed usage example. Further quality criterias are more documentation, user and developer unit tests (using any of PHPUnit or phpt), API stability etc.
Packages that follow more than the minimum requirements will be able to show this transparently to the user through the PEAR website.
Redundant packages are not allowed. Instead, merging and/or refactoring
with existing packages is expected.
Packages have to adhere to the versioning scheme (all BC breaks require a major version upgrade). There is no stable version below 1.0. BC breaks below version 1.0 are allowed.
An archive zone for deprecated package, aka "Siberia" should be created. This will also make it clear that PECL is NOT Siberia.
PEAR Coding Standards (CS) will include method naming conventions
(i.e.: methods which do similar things will be named the same across packages,
examples are connect, display, fetch, etc.).
A documentation team will be formed to handle all related issues.
The team is expected to :
PHPDocumentoris now the official tool to generate API documentation.
Christian Stocker's proposal as found in the RfCwill be used with the following changes:Platform support:
A "light" implementation of a package needs to be extended to provide
a richer set of features. Example cache_lite would have to extend cache,
i.e. "cache API extends cache_lite API".
It was not yet decided if this "extends" means that the class itself will have to be extended, but only that the interface needs to be "extended"
The PEAR Installer is now working on windows.
A PEAR Group should be formed. Its size will be 5-9 people,
an uneven number will be chosen.
It will be dynamic, people can join or leave it. What happens in that case (especially regarding maintaining an uneven number) was not made. The initial members are appointed by Stig. The Group will then regulate itself. The Group can apply a veto on a package proposal and can make decisions in the case the community needs direction or resolving of conflicts. For example the latest discussion on pear-dev about IT[X] vs. Sigma could have resulted in actions being taken by the PEAR Group.
The roles of this group are:
More and more magazines are publishing articles about PEAR, they even
approach us to ask us to write for them.
The International PHP Magazine (http://www.php-mag.net) will release articles if they are older than a few issues and we are working on ways to make them updateable. Also the Intl' PHP Magazine will distribute PEAR on the magazine CD.
Horde and Midgard are having closer looks at PEAR.
The PEAR Weekly News are part of the promotion effort and should be published again as soon as possible.
We need either nested classes and/or namespaces with working import. Well working exceptions are part of the requirements. We have yet not found a good solution about having PHP 4 and PHP 5 code in PEAR. We first have to figure out how ZE2 will look like. There is still the idea of code morphing at packaging. (see the peardev archives), although in Stig's original proposal, he suggested morphing on the server.