Re: addition to PEAR2 coding standards that may be controversial

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, consider this: you're a new developer and hacking around in svn on your soon-to-become beta project like a monkey and then the vote is negative and your work won't see the light of the day, at least not on pear. Ok, this is an extreme case and such a vote must have reasons, too. But this is the first thing which came into my mind after your suggestion. I agree that the current status needs improvement and I am very unfortunate that I cannot make a better suggestion now, but maybe someone else can. In my mind I've this picture of the man, given the torch to run and he runs and runs but then isn't allowed to pass the goal ... Maybe I'm exaggerating this point. - - Markus 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 > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG4o6l1nS0RcInK9ARAsiMAJ938SDF5L3T1FQ/g562+zgCFEOYIQCeIE7u TJqRZ5tRH4AikphFw7/KDoE= =6Vn8 -----END PGP SIGNATURE-----