Helping ordinary people create extraordinary websites!


PEAR Manual
PrevNext

Chapter 5. PEAR2 Policies

Table of Contents
General policy rules
Policies in use in PEAR2 (version 0.2.0)

Note: This document cannot be considered complete.

  • This document contains the general policies for how coding and collaboration works in PEAR2.

  • These policies will expire on December 1, 2008, and must be reviewed and renewed by the PEAR Group in order to continue

General policy rules

List of rules that apply to PEAR2

Commit access to the repository

All collective members have full commit access and can commit minor bugfixes without requesting permission or notifying lead developers. However, as a courtesy, it is expected that all developers will communicate with a package's lead developers prior to taking action. If a dispute over a commit arises, it is also expected that the commit in question will be reverted pending a review.

This rule is intended to encourage open and friendly collaboration. For an example of this commit model, the PHP project developers often commit minor fixes for thread-safe errors, spelling mistakes, and other obvious mistakes without consultation. Exceptions can be made to this rule with explicit PEAR Group approval documented on the website.

Handling package design

All design decisions should be discussed freely in a Collective, and each Collective is responsible for enforcing these decisions in their own way. Some Collectives may require packages to adhere to basic interfaces, others may require common data storage formats, but individual package maintainers must adhere to these decisions or discuss ways of improving them. No cowboy coding! Ultimately, individual package developers have the full freedom to innovate without expecting too much interference, but are expected to learn how to both give and receive constructive criticism as a part of the privilege of having their code hosted at pear.php.net.

Pulling releases

All collective members can pull a release within 24 hours if there is a major regression or security bug. If at all possible, the primary lead maintainers should perform this action, but Collectives function as a unit, and have the role of policing huge problems.

Competing packages

Competing packages are allowed at the alpha level in PEAR2.

All alpha/devel stability packages have no claim to a package name. If a better package comes along that does the same thing, wants your package's name and achieves beta status, you have to either join forces or change the name of your package. The limit is that newer packages have to be unarguably better in implementation. It is up to the Collective to define "unarguably better"

Stale packages

Any package that is alpha (in svn.pear.php.net/PEAR2/sandbox) and inactive for more than a year will be deleted

What beta status means

To become beta, a package must undergo extensive review.

Package acceptance into PEAR2

Packages can be proposed either as 1) A completed, or relatively complete package to Pepr 2) A concept, or proof-of-concept to svn.pear.php.net/PEAR2/sandbox For proof-of-concept packages they should

Packages listed in the channel

Only packages with a status of beta or stable are added to the public channel

Version Control System

In order to submit code to PEAR2 you will need to use the provided svn repository.

PrevHomeNext
RulesUpContributing