Re: PEAR Quality (vs. Quantity) RFC

Short summary of the newly mentioned aspects * in general, this RFC is meant to determine the stages which PEAR will have for giving out quality-seals (or whatever that is called). This is not a definition of what is allowed in CVS and what not, since the CVS is the working repository! If any of this stages will be a requirment for a release or anything then the script/mechanism responsible for that, can simply check if the package fulfills the required stage. May be like this if($qualityStages->fulfills(PEAR_QA_STAGE_X,$packageName)) { OK } * phpDocumentor I think this tool could be used as the base for implementing the check for 'Stage 1 and Stage 2. PhpDocumentor does already parse the files, so all we have to do (i hope) would be i.e. this: if ($phpDocumentor->areAllMethodsCommented && other-checks) { return "stage 2 - passed"; } * i agreee, that Zend simply is a proprietary format. I think Zend should rather be encouraged/told to become standard conform, which is phpDoc! * checking CS can be done automatically for the biggest part, of course, i will add this to the RFC, thanks. But assuming that i.e. tabs will not appear at all would be too dangerous, one could compose mails inside a class or any other text content! * i would suggest that examples should be required (but that is actually not part of this RFC, see first note, above). What the user finally does is programming and an example is always something that is quick to look at and mostly easy to understand. * If the package needs a DB to run the unit tests there should be a common setup to be defined. The easiest for the one who has to run the test, will be using Mock-Objects, since you dont have to set up the DB-connection or anything. But i would suggest to provide some common setup for DB and MDB (since currently both are widely used). I have something, which might not be perfect in the Tree-Unit tests, see: this is the sql definition http://cvs.php.net/co.php/pear/Tree/docs/UnitTest/sql.php?r=1.1 and here it is 'executed' http://cvs.php.net/co.php/pear/Tree/docs/UnitTest/index.php?r=1.1 To ensure automatic running of the unit test, that DB_DSN should may be be possible to be passed as a parameter (either command line or URL). * Using Mock objects or alike should also be thought of when writing proprietary extension, which require a certain counter part, like Payment systems for example. I think there is no unique solution for those special cases, it should be deccided on case-by-case basis. * the UML diagrams as jpg/gif/png or whatever was just the idea, so that people, who dont have the tool that those diagrams were made with can also look at them. They should also go in the user documetation, i would suggest. -- Wolfram ... opensource @ vision:produktion ... http://opensource.visionp.de ... translating template engine .... http://sf.net/projects/simpletpl ... authentication system .... http://sf.net/projects/auth