Re: PFC-RFC

I don't mind the hierarchy myself (so +1 I guess), but I'd suggest that PFC classes also absolutely require proper documentation and unit tests. Otherwise, I can't see how the assumed quality difference claim could be justified. As for a rating system for PEAR packages not in the PFC, what if we created some sort of team whose job it was to go through and review/test/play with/whatever each package in turn (over time of course) and give it ratings or approval in certain predetermined criteria. I'm thinking of something similar to the CPAN Testers. This could help ensure that package merits aren't purely based on votes (which might not necessarily reflect the actual _quality_ of the package), and so packages that aren't in PFC still have a reliable amount of quality assurance to provide for their users. Thoughts? Lux On Monday, February 24, 2003, at 03:22 PM, Christian Stocker wrote:

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

-- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

-- John Luxford President and Chief Developer ______________________________ SIMIAN systems Driving Web Content Management ______________________________ web : http://www.simian.ca/ email : lux@simian.ca phone : 204.452.8537