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.

» 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.

Breaking backwards compatibility is only allowed in a new major
version.

» 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.

» 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.

» 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

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"

» PEAR on Windows

The PEAR Installer is now working on windows.

» 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

» 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.

» 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

» 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.

» 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.