Re: addition to PEAR2 coding standards that may be controversial

Getting there = It needs to be laid out as bullet points, there is alot of information in that single paragraph, It also needs expanding a little. Packages can be proposed either as a) A completed, or relatively complete package to Pepr b) A concept, or proof of concept to svn.pear.php.net/concepts [?? use a subdirectory/different repo for them ??] For concept packages they should = Be approved on the mailing list by??? before being accepted into the concept directory = Undergo a review [??what exactly does this mean?? = a Pepr vote??] by the collective when going from Alpha to Beta?? = Pepr may be used by the collective to vote on package [?? at what point - paragraph below is vauge - is a one vote needed for API, docs etc.??] = [At what point should the be put into the 'release system']

Hi, After Alan and Markus's initial criticism, I revised the language to this: ===Package acceptance into PEAR2=== Packages can be proposed for PEPr as new ideas or as completed code. Development for new packages must be at svn.pear.php.net. A package must undergo full review by a collective when moving from alpha to beta status, but it is expected that this review will be ongoing as development progresses to make the review a smooth process. PEPr is used by the collective to vote on documentation, test suite conformance, and API. Does that look acceptable? Now the only big change here is that packages can be proposed as ideas and started as development from scratch in svn.pear.php.net in addition to being proposed as fully fleshed-out code. The whole of PEAR still votes on package acceptance as we do now, that part of my changes was dropped. All of these proposals would require tweaking to PEPr, but that's a minor issue. Greg