Re: PFC-RFC

On Tue, 2003-02-25 at 09:32, Stig S. Bakken wrote: > Great initiative! More ideas: > > 1. Documentation! Inclusion in the PFC requires full peardoc2 API > documentation. yep, i completely forgot that in my initial proposal. The same goes for unit testing... > 2. All PFC releases must be signed with either "the PFC key", held by a > small number of PFC leads who spend too much time online, or by > individual leads with a web of trust. The former solution is easier, > since the "PFC public key" may be included in PHP releases. good idea > 3. Additional coding guidelines that ensure that the same approach is > taken to solve the same problem. For example, for pattern > implementations, the same general design and method names are used. ditto > 4. APIs and package design should be reviewed and designed with > extension in mind (not a big process, just talk to other developers). > The purpose of this is to avoid unnecessary major version upgrades. This is very important, IMHO. I ended up more than once to take a PEAR-Class and extend it to fit my needs. So i'm now in upgrade-hell for these packages ;) If there's an easy way to extend classes, this would be very welcome > 5. The installer and pearweb upload form does additional checks on PFC > packages, such as installing the packages in a "jail" and running tests. Very good for Q&A indeed. > 6. PHP version and extension dependencies must be kept to a minimum. > Provide user-space implementations of new PHP functions such as > file_get_contents(), don't use preg if ereg does the job, etc. But they should use the native implementation, if they are available. PFC guidelines should set a minimum PHP Version, which PF Classes have to support. I would suggest, 4.2 is enough for the time being. > 7. All objects have customizable error reporting (ie. they inherit PEAR > so users can do $obj->expectError() and so on). isn't that already in PEAR CS? > 8. Code must work with PHP 5 At the moment, PHP5 seems still like a moving target... But I didn't do much with it till now. Some more points (some of them are maybe obvious): - PFCs have to work with error-reporting set to E_ALL. - PFCs have to work with register_globals = off - PFCs have to work on the most widely used platforms ( Windows and all those Unix-derivates (Linux, *BSD, Mac OS X)) About voting: I don't think, we really need voting for becoming a PF Class, if the criteria are met, it can get the PFC badge. But the question remains, who decides, if the criteria are met. Maybe a little PFC-group (the same as with the signing keys above) could do that. Last, but not least: one important question remains: "Who is going through all that hassle to become a PFC?". IMHO, the intention of PFC is not to put a lot of burden on one single developer, but to concentrate the work of the core PEAR-community on those PFCs. It should be the goal of the PEAR-community to provide as good as possible PFCs. At the moment, it's more a work of single developers working on single packages, which isn't the proclaimed way in open source projects ;) With PFC, we could maybe concentrate our efforts again. I'll update the PFC-RFC with the comments/additions made on this list and publish it again hopefully later this day. If their is widespread approval of the PFC idea (not the RFC), I could put it into CVS, as well. chregu -- christian stocker | bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich phone +41 1 240 56 70 | mobile +41 76 561 88 60 | fax +41 1 240 56 71 http://www.bitflux.ch | chregu@bitflux.ch | gnupg-keyid 0x5CE1DECB