Re: so lets get going

On Thu, May 29, 2003 at 11:34:41AM +0200, Lukas Smith wrote: > My suggestion would be that we find 2 people that take responsibility > for each category. These people should be familiar with each package in > their category. That sounds reasonable, although I'd like to assert my interest in "general" PEAR QA and not assign myself to a specific set of packages. > Also the qa team could work up proposals about naming conventions of > methods (although I would say the final decision on this sort of thing > should be with the pear group). Yes. The QA group should enforce the decisions of the PEAR Group, and perhaps influence them. The QA group should not be a policy-making body. > Finally the qa team should think up and assign tasks and tools that are > needed the qa more efficiently. I'd like to see a gross set of modifications made to the current package / release submission process to support the QA pipeline. I may be somewhat influence by the way we do things at my development studio, but I think something like the following would be quite useful: When a new package is submitted, it is queued and must proceed through the following steps before it is "approved": 1. Initial submission 2. Conceptual acceptance (based on the "voting" system) 3. Category and package naming acceptance 4. Code review 5. Package requirements verification (PHPDoc, docs, tests, etc.) (This will get you approval for the package space but not for the initial release of the package (i.e. it gets you a name place holder and CVS space). The initial release must also pass the "new release" steps, as outlined below.) When a new release of a package is submitted, it is made "public" but is not "approved" until it passes the following steps: 1. Initial submission 2. Package integrity verification 3. Automated testing approval (unit tests and otherwise) 4. Clean documentation generation I imagine a progress queue for each of these procedures, making it easy to see where a package or release is on its way through the steps. Different parties would be responsible for promoting a package through the process (e.g. QA would handle code review, an automated system would run the unit tests, the PEAR community (or whomever) would perform the initial voting). This is just a rough sketch. The idea is entirely open to modification based on feedback and the needs of the community. Please only reply to the relevant parts of this message instead of tacking on your two sentence reply in a top-post. -- Jon Parise (jon@php.net) :: The PHP Project (http://www.php.net/)