Re: addition to PEAR2 coding standards that may be controversial

While what you describe about teams/groups working together to design and finalize a package is not unknown, it is the exception rather than the rule. Generally code is developed on a 'need' basis: eg. I need a Capatcha generator to protect my site from blog spam - I write one, then perhaps propose it to PEAR. The reverse of this is "Wouldn't it be good if PEAR had a Capatcha package, let's design one for PEAR,and see if anyone uses it." I would sumize that 99 out of 100 packages ever proposed will be because of the driving needs of a single developer, and are shared via PEAR, on the off-chance they are useful to someone else.. Pepr in it's current place is pretty well suited to this, I think if you are going to explore the idea of "collective design", then you need to decide how that overlaps with the current situation, rather than describe it as a replacement. Regards Alan Gregory Beaver wrote:

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