Re: PFC-RFC

On Mon, 24 Feb 2003, Jason Lotito wrote: > Christian Stocker wrote: > > Hi > > > > After recent flame-wars and some really disappointed people, there was a > > short discussion on #pear > > Server? the same as #php, EFNet. > > 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. > . . . > > > *** > > PEAR Foundation Classes RFC > > > > - Only "stable" classes can become a PF Class. > > By "stable", do you mean the developer says it's stable, or the > user-base says it's stable. yep, the developer decides. > > - PFCs should preferably have 2 lead-developer or at least some active > > maintainers. > > Or simply work. If someone creates a class that is simple and works, > why shouldn't it get in? Technically, once a class is completed, the > only thing needed is to update it to take advantage of the latest PHP > version it's being released for. ACK. > > - A class can only become a PFC, if at least 2 independent (none > > developer) people have reviewed the code and gave their approval. > > I assume you mean non-developer as in "people who haven't worked on the > code but can still be programmers and developers of other PEAR/PFC classes?" yep, was not clear on that, > > - 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) > > I disagree here, or else it's just PEAR for those that have an ego. The > PFC should be solid, sleek, properly designed. Having 2 classes that do > the same thing in different ways (XML_Reader and Read_XML for example) > would not work. Sure, people may not like the one true way, but they > still have PEAR to look at other solutions. PFC is a solid library of > code. I may not agree with how PEAR::DB is written, but if it's > included in the PFC as the database layer, that that is what we use. But especially in the templates world, there is no "one size fits all", there may be other examples. Therefore, I wouldn't rule concurrent classes completely out. It makes sense in some areas. > > - 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) > > That's an independant developer decision I think. If a major API change > is going to happen, then probably a major version increase is in order. > If the developer needs to make a change to a PFC API, then he makes > the change. Granted, PF classes shouldn't need to be changed often, or > else they weren't designed properly from the beginning. "should give the user enough time to adopt" :) Like for example with the register_globals=off stuff. 4.1 has the new features, 4.2 turns the old behaviour off by default, etc.. If it's inevitable, then so be it and bump the major number (users get used to that ;) ) > > > > - PF Classes should only depend on PF Classes. > > > > And if the PF Class needs to depend on a class that isn't in the PFC? > It should use a PEAR then. The needed functionality should NOT simply > be included. but even better would be to rewiew/improve and PFC the needed include ;) > > - PF Classes do strictly follow the PEAR CS > > But of course. > > > > > - 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.) > > The number of downloads should have nothing to do with whether a class > gets a PFC badge or not. The quality of the code is what is important. > If it's a class that is good and solid, then it should be included. A > vote by other PEAR developer's is a good idea. A vote in the negative > should be taken seriously and considered. Majority rules, but minority > rights. =) Deevloper A may get +10 votes because everyone likes him, > but gets -2 votes from 2 people. Why? Maybe they are right. That's not easy to implement, but certainly a point and the majority is definitively not always right (I "loose" most of the votes here in democracy-laden Switzerland, so the majority is definitively not always right ;) ) chregu