PFC-RFC

Hi After recent flame-wars and some really disappointed people, there was a short discussion on #pear about the future of PEAR. It was decided, that PEAR should take up the idea of the PEAR Foundation Classes (aka PFC) again. I'm not sure, what the initial idea of PFC was, but here's a proposal, what it could be. In the last months, PEAR changed from the idea of having high quality code to everything-goes (this is not entirely true, but some tendencies are here and it's just MHO). Basically, this is not wrong, as the whole pear-infrastructure and especially the pear installer are really nice things to have. But pear was started with the intention of having good programmed, well thought and ready-to-use code. This is where PFC comes in. Good, well-established classes should be able to get a PFC badge and users can recognize maintained and reviewed classes with this. Yes, this will introduce a two class system within pear, but it should please both parties, the ones, which want have as much as possible in PEAR and those who only want high-quality code. Users can furthermore decide, if they only want to use highly tested code or if they are more "adventurous" and use other code. The alpha/beta/stable category was introduced for that, too, but the developer itself do decide, if they want to declare their class as stable. There is no outside review of that. Enough talking, here's my proposal, what PFC should mean. It's more a brainstorming write down, than a real RFC, but I hope, it starts a discussion and will end in some results :) *** PEAR Foundation Classes RFC - Only "stable" classes can become a PF Class. - PFCs should preferably have 2 lead-developer or at least some active maintainers. - A class can only become a PFC, if at least 2 independent (none developer) people have reviewed the code and gave their approval. - Peers, which review the code, should preferably be someone with a pear-account. - Concurrent classes shouldn't be included in PFC. The emphasis is on "should". In some areas, it makes sense to have concurrent classes, 'cause there's no "one size fits all" for everything (Cache, Templates, maybe DB, and certainly others) - PF Classes do not break BC without giving the user enough time to change its code. Meaning, there should be some releases between non-BC API changes with the new and the old behaviour integrated (if possible) - PF Classes should only depend on PF Classes. - PF Classes do strictly follow the PEAR CS - If the Packages shows enough downloads and active developement in the last months and was peer-reviewed, it can apply for a PFC. There's a vote on pear.php.net about giving the PFC badge to a class or not (I'm not sure, if it really neads a vote as long as noone gives his/her veto on pear-dev.) **** I think, with the introduction of PFC, PEAR can still be a place of high quality (whatever that means) code and on the other hand include a lot of useful classes, which are not yet reviewed or programmed according to PEAR CS. A second RFC about what's needed to get into PEAR (the before PFC stage...) should also be written. I think it's quite a mess right now, as everyone else has a different idea... Maybe someone likes to take that part :) chregu -- 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