PEAR Meeting - Summary

[May 16, 2003]

» Introduction

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.

  1. » Quality

    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.

    • PHP object-oriented APIs should follow the PEAR coding standards.
    • Breaking backwards compatibility is only allowed in a new major version.

  2. » Package policy

    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.

  3. » Documentation

    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 :

    • write tutorials on how to write documentation
    • provide tools to make doc generation easy since Docbook is currently the standard format.
    • ensure that this generation does not need any non-standard tool or services on pear.php.net to be made available so that people don't need so install this software locally.

    PHPDocumentoris now the official tool to generate API documentation.

  4. » PFC

    Christian Stocker's proposal as found in the RfCwill be used with the following changes:

    Platform support:
    • If someone can provide us an access to a test machine running OS X, we can include it in our supported platform list.
    • Solaris is a widely used platform

    5. Concurrent Packages:

    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"

  5. » PEAR on Windows

    The PEAR Installer is now working on windows.

  6. » PEAR group

    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:

    • keep the PEAR "roadmap" and quality
    • handle conflicts
    • organize the PEAR project
    • set standards

  7. » Website

    Website enhancements:

    • add votes and comments for packages
    • Proposals and voting will also be handled though the website only, including discussions of the package, this will not be done through the mailing list. Nevertheless the list will be cc'ed. QA and/or the PEAR Group can apply a veto.
    • We may require a certain amount of votes form certain groups (developers with CVS account, QA team) in order for a proposal to pass.

  8. » Installer

    • improve the version handling, we especially need to add a guide on version naming in the PEAR manual.
    • PECL installer does not work on Windows
    • PECL installer does not detect if an extension is loaded while upgrading it that creates a possible crash.
    • Need to check in the packager to verify if the version name is correct (that will be registered as an upgrade)
    • Need binaries handling for different platforms
    • updating stables should not be updated with lower "level" (beta, alpha) releases
    • BC breaking releases should not be done automaticly (i.e. upgrade-all)
    • Installation of older versions should not require the complete URL but only by adding the version number
    • BC breaks require a major version increase

    Future plans:

    • mirror support
    • automatic dependeny resolving through a local database
    • move away from xml-rpc
    • taking another look at an rpm based solution

  9. » Promotion

    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.

  10. » PHP5

    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.