addition to PEAR2 coding standards that may be controversial
| From: | Gregory Beaver | Date: | Sat, 08 Sep 2007 05:24:57 +0000 |
| Subject: | addition to PEAR2 coding standards that may be controversial | ||
| Groups: | php.pear.dev | ||
| Request: | Send a blank email to pear-dev+get-47943@lists.php.net to get a copy of this message | ||
Hi all,
I moved dependency resolution to controversial changes, pending further
review of the autoloading feature in PHP 6 (or 5.3 if namespaces get
backported).
I've also added some text that more clearly redefines the way that
packages would be accepted into PEAR2. Currently, in order to get a
package accepted into PEAR, the package must first undergo a rigorous
examination, PEPr vote, and then after acceptance, no further
requirements are made. This results in many packages "coasting" and
never reaching the "stable" label. Due to competing package rules, new
developers are required to adopt these packages if they wish to write a
package that supports the same protocol, and must contact existing
developers and jump through many hoops. None of these rules encourage
development or experimentation.
I'd like to propose we move the PEPr stage to the point at which a
package is declared to be "beta" status. Before this point, as the
PEAR2 proposal states, a package is not publicly listed, but is only
available on the website to other PEAR devs. This would mean that
interesting projects could host their codebase at svn.pear.php.net and
develop freely, experimenting with impunity until they feel it is time
to propose the package as beta. At that time, the collective would have
an opportunity to vote on the package, and decide whether it is ready
for the prestige of "beta" and the public exposure this would imply. A
package marked as "beta" is expected to have a stable API, meaning the
only changes would be for bug fixes prior to the stable release. As
such, the point of examination would be just prior to a stable release,
where it allows us to truly enforce and encourage the practices of
documentation and testing. In addition, it will allow us to get to know
new developers before we are locked into supporting their packages in
perpetuity.
This will encourage much more innovation under PEAR's umbrella, as well
as encourage more stable packages with better documentation on the
public website. Win-win. Here is the actual language added to the
proposal on http://wiki.pear.php.net/index.php/PEAR2_Standards
===Package acceptance into PEAR2===
Packages may begin development at svn.pear.php.net prior to official
proposal as a new package for PEAR2. A package is considered to be
proposed when it reaches beta status, and must undergo full review by a
collective. PEPr is used by the collective to vote on
documentation, test suite conformance, and API. If a user objects to
the acceptance of a package by a collective, a formal proposal to
PEAR Group through email to pear-group@php.net can be used to call a
general PEPr vote on a package's acceptance.
Are there any objection, or other considerations to take into account?
Greg