Re: PFC-RFC

Christian Stocker wrote:

Hi After recent flame-wars and some really disappointed people, there was a short discussion on #pear

Server?

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.

- 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.

- 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?"

- 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.

- 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.

- 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.

- 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.

**** 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 :)

Just my 2 cents Jason Lotito