Re: PFC-RFC

On Mon, 2003-02-24 at 22:22, 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 :) Great initiative! More ideas: 1. Documentation! Inclusion in the PFC requires full peardoc2 API documentation. 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. 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. 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. 5. The installer and pearweb upload form does additional checks on PFC packages, such as installing the packages in a "jail" and running tests. 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. 7. All objects have customizable error reporting (ie. they inherit PEAR so users can do $obj->expectError() and so on). 8. Code must work with PHP 5. - Stig