RE: [PEAR-DEV] PFC-RFC Update

Hi Christian, My initial opinion is that classes for PHP5 will be written differently to classes written for PHP4. Do you expect PFC's to have to maintain two classes? Best regards, Stu -- > -----Original Message----- > From: Christian Stocker [mailto:chregu@bitflux.ch] > Sent: 25 February 2003 12:16 > To: pear-dev@lists.php.net > Subject: [PEAR-DEV] 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 > > > -- > PEAR Development Mailing List (http://pear.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > >