In the early times of PEAR, all new packages were proposed by an
informal email to the PEAR
developers mailing list. Over the time, the number of new
proposals increased quite dramatically, making it hard to keep track
of all the proposals.
A web-based proposal handling system was established to solve these
problems. The system is called PEPr. It is pronounced like the
spice and stands for "PEAR
Proposal system".
This chapter describes the requirements and the workflow for a
PEPr-based proposal. After that we will provide you with information,
on how to actually start a proposal. Finally, you will learn what to
do once the proposal is finished.
After reading this chapter, you will will be able to start a proposal
for your code right away.
The following enumeration lists the most important things that need
to be done or be made available before starting
a new proposal.
Finding a name for the package
It is obvious that each package needs to have a unique name. To
get a "feeling" for proper package names, you should
browse the list of existing
packages.
Choosing a name for the package is an iterative process and it is
likely that you will change the name at a later stage of the
proposal process.
Finding a category for the package
Similar to each package having a unique name, it has to be placed
in one of the categories, which are listed in the package browser as well.
Writing a package description
For starting the proposal you will need to write a description of
the package. This description does not need to mention every
detail of the package, but it should at least outline the basic
concept and feature set. When your package has been accepted, you
will have to come up with a single-line summary and a fulltext
description.
Choosing a license for the package
Each package has to be licensed under an accepted OpenSource
license. If you are unsure about the license, you should opt for
the PHP License. The PEAR
Group has issued a License
Announcement, which provides further details concerning
this topic.
Writing examples and documentation
Without proper usage examples and documentation, neither will the
PEAR developers be able to evaluate your package nor will users be
able to make use of your package.
Listing dependencies
Making a list of dependencies basically means that you write down
all external entities such as other PEAR packages, certain
operating systems or external applications, which are required to
use your proposed package.
