PFC-RFC Update

Hi I rewrote and extended it with all the comments I got. So here it is: ******************************* * PEAR Foundation Classes RFC * ******************************* Goal: The intention of PEAR Foundation Classes is to provide well-written, well-documentated, well-tested and well-extendable code within PEAR and mark them as such. For becoming a PFC, a class has to follow strict rules. Users of PFCs can be assured that those class went through thorough reviewing and testing and therefore should be the first choice for everyone needing a class for a given task. Prerequesites: -------------- - PFCs should only depend on PFCs. If a needed library is not yet a PFC, the developers should take the appropriate steps to make it a PFC, as well. - PFCs should preferably have 2 lead-developer or at least some active and dedictated maintainers. - PFCs have to strictly follow the PEAR Coding Standards - PFCs have to provide scripts for unit testing - PFCs have to have thoroughly documented. This applies to inline docs (PHPDoc), as well as external documentation (peardoc) - PFCs have to work on all widely used platforms (Windows, Linux, *BSD, Mac OS X), except where it doesn't make sense. - PFCs have to have customizible error reporting (ie. they inherit PEAR so users can do $obj->expectError() and so on). - PFCs do not break BC without providing users enough time to adjust. A well thought upgrade path should be provided. - PFCs have to work with error-reporting set to E_ALL and throw no NOTICEs, WARNINGs. - PFCs have to work with register_globals = off - PFCs have to run on each released PHP-version since 4.2. If PHP 5 has matured, they have to run on PHP 5 as well. If new functionality of later versions is needed, PFCs should provide a user-land implementation of this functionality. - PFCs should keep the dependencies on non-standard extensions as low as possible. There should always be a fallback, if the extension is not available. - PFCs should follow the additional guidelines (to be written) to 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. - PFCs have to show some kind of stability (in API-sense) and should be widely used. Further Stuff: -------------- - PFCs packages are signed with a PFC Key by the PFC core group (see below). - PFCs are automatically tested on upload. If tests fail, the package will not be published (multiple platform testing?) Concurrent Packages: -------------------- - Concurrent PFC Packages should be avoided as much as possible. They are only allowed, if they take a whole different approach to the same problem and if it's really not fitable in an existing PFC. It is always preferred to extend existing PFCs before providing a new one. Becoming a PFC: --------------- - A class can only become a PFC, if at least 2 independent people have reviewed the code and gave their approval. - All prerequesites have to be accomplished. - If everything is ok, the PFC core group decides, if it conforms to everything asked for and changes the state of that package in the PEAR databse. There is no public vote for becoming a PFC, since a class should become a PFC if it conforms to the points above, and not if the public thinks it should... [but how do you measure, if a class has enough documentation/unittesting/etc..] PFC core group: --------------- - The PFC core group consists of some (5?) core developers, which decide, when a class conforms to the standards and can get the PFC badge. - The PFC core group signs newly uploaded PFC packages - If more than "some" people want to become a PFC Core member, a public vote should be held. - PFC core group does not decide about which classes should go into PEAR. This is still task of the whole PEAR community and the exact procedure should be discussed in another RFC. PFC core group should be an administrative counsil like the php-group and not make "political" desicions. This wouldn't be in the spirit of php development. To be discussed: ---------------- - Concurrent Packages: The above point is not very clearly defined. From my point of view, it would make sensde to not allow concurrent packages in PFC. But then again, when is a package a concurrent package and when it's a new one. Who decides that? - Who has the last saying? If some people want to do something this way and some the other way, who decides? the lead developer(s)? the community? - Who can commit to PFCs? at the moment, everyone with a pear-cvs-account can commit to every package. Shouldn't be this restricted for PFC classes? Or is this getting to copmlicated for maintaining CVSROOT/avail. - If there is common approval of this RFC, what should be the next steps? -- nam...christian stocker adr...pflanzschulstr. 31, ch-8004 zurich pho...+41 43 317 9984 www...http://blog.bitflux.ch mob...+41 76 561 8860 ema...chregu@phant.ch wor...+41 1 240 5670 gpg...0x5CE1DECB