LD SoftwareBespoke Software, Web Design, Security Consultants and Host Services.

Menu

Sentinel
You have been warned!
We have caught 5846 shameful hackers.

NukeSentinel(tm)

Paypal Referral
Sign up for PayPal and start accepting credit card payments instantly.

Link Exchange
Join our free link exchange

Click Here
 
The formal proposal process

Chapter 10. The formal proposal process

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.

Step 1: Requirements for a proposal

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.

    Example 10-1. Example for a dependency list

    If your package does only work on Linux, requires the DB package, version 1.8.4 or higher of the Log package and at least PHP 4.3.0, your dependency list looks like this:

    Linux
    DB
    Log >= 1.8.4
    PHP >= 4.3.0
    
 

Text Ads
There isn't content right now for this block.

Community Login
Welcome,
Anonymous

Nickname
Password
   

People Online:
Visitors: 10
Members: 1
Total: 11

Online Now:
01 : Monty

Like my code
Then please make a donation.

Which help me produce more free code.


Paypal Verified

Information

Powered by PHP-Nuke

Valid CSS!


Valid Robots.txt

Bad Behavior

[Valid RSS]

[Valid RSS]
You can syndicate our News with backend.php And our Forums with rss.php
You can also access our feeds via Feedburner Site News and LD Software Forums
© 2009 ld-software.co.uk All Rights Reserved.
PHP-Nuke Copyright © 2005 by Francisco Burzi. This is free software, and you may redistribute it under the GPL. PHP-Nuke comes with absolutely no warranty, for details, see the license.
Page Generation: 0.69 Seconds