Come to the PEAR-fest

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

lastcraft
Forum Commoner
Posts: 80
Joined: Sat Jul 12, 2003 10:31 pm
Location: London

Post by lastcraft »

Hi...

Firstly thanks for taking the time out to respond.
lsmith wrote:One thing that alot of the people bashing PEAR.php fail to take into account is that PEAR is one of the main reasons why are getting all these nice features into PHP5. So its kind of lame to be attacking PEAR that its a poor-mans PHP5. Without we will not be having the PHP5 we are having now.
I hate to start on a bad note, but I have to say I simply don't buy this. PHP3 and PHP4 had already started on the OO road without PEAR. PHP5 is a continuation of this and necessary to compete with .NET and to leverage Java designs anyway. Also there is a lot of OO stuff that is not needed by PEAR (final - why?) or anybody else. I would say Java has more infulence on PHP than PEAR judging from the result.

The web is not a Perl world anymore.
lsmith wrote:So what is a redundant package?
That's just the problem. There all sorts of reasons why one package may be better than another, ranging from simplicity, performance, support for procedural approaches, conformance to an industry standard and many others. It would be a lot easier to decide which packages are redundant once they have spent some time in the library. Doing it at the proposal time is impossible.

Also some existing packages just aren't very good. The only way to fairly oust the incumbent is to develop the new one along side.

Besides, what is actually wrong with a redundant package? What if both apd and XDebug were in PEAR at the same time for example? Does the sky fall in? You won't get thousands of packages if the barrier to entry is one of minimum quality and usage.
lsmith wrote:It was pointed out that a good core library needs to be driven by a core developer tema instead that can work on any part as they see fit.
Which is the nub. Is PEAR a core library (STL, boost) or is it a package repository (CPAN)? PEAR should decide and then open up the other field to something else. These goals are diametrically opposed.
lsmith wrote:We are taking a very different approach in our current effort to build up a QA team.
This is another god view way of doing things. Quality is an impossible characteristic to judge and open to even more abuse than before. Evolution and self selection would shift the problem.
lsmith wrote:However I dont agree that error handling should not be handled inside the libs. Handling it outside is impossible.
This is not true if we stick to error handling. Error handling is not the same as logging however which is a more complicated cross cutting issue (the usual clean way to deal with logging is to attach a logging decorator around the observed object). Good error handling means that you actually have to log less information. The target of the logged data is also up to the application, in the same way an error handler should be.

It worries me that these two things are being mixed together. Are we going to end up with another framework style solution here with a PEAR error class having to know about lot's of additional resources and so forcing it's own inclusion? This has a ring of deja vu. A dependency injection approach (PHP5 now has interfaces after all) would be so much more flexible.
lsmith wrote:Of course PHP5 opens new possibilities, but remember again that PEAR was one of the main groups of people making sure that exceptions have made it into PHP5
There were plenty of people clammoring for exceptions outside the PEAR community too. It's nice to hear that they didn't get heard :(.
lastcraft
Forum Commoner
Posts: 80
Joined: Sat Jul 12, 2003 10:31 pm
Location: London

Post by lastcraft »

Hi...

Of course my last post was rather negative :(. How about some random proposals in no particular order so that PEAR people can take pot shots at me. I will assume that PEAR does (for good or ill) want to be a class library rather than just a repository. For this you need quality above all.

1) If PEAR wants to be a class library (it obviously does) then how about promoting the phpclasses site into the php.net domain. Yes I know Manuel can be an ascerbic **** at times, but he has done more to build a PHP community than just about any other single person, as well as being a highly skilled developer. If he occupied classes.php.net then the flak would be taken from PEAR.

2) Change the name to PEAL.

3) Have a two tier system where the top tier membership is rule based. If there are two competing packages, then choose on dependency and popularity. PFC is still an old boys network. I suspect that we will see DB and DataObject in there pretty quick with no way of getting rid of them (for good or bad). The PFC should start empty or not at all. It should also be promotional as a search option only. No requirements to depend only on top tier packages for example. You want an enabler for change. Quality must emerge.

4) Allow competing packages in the second tier. The requirements should be perfect installation (both tarball and installer), regression tests and a low latency in fixing bugs. Also the other requirements below. Documentation will sort itself out via the installer requirement and in the popularity of the package. Add more tiers if these have motivational effects.

5) Allow outsiders to attach tutorials to packages to promote their own sites. You want documentation...why not get it for free?

6) Insist that every package has at least two maintainers. Nothing improves code quality like peer review. These maintainers should be of equal status (no yes men and no empires). The Apache foundation insists on three, so maybe even three.

7) Refactoring is stone dead within PEAR and this is the root of the poor quality and rigidity. The QA hit team is a start (and I do actually wish this experiment well), but package maintainers need to be able to edit dependent packages. This means that if you declare a dependency you are giving that package the right to edit yours in the event of a test failure. If you don't want behaviour changed, then it is up to you to protect it with tests. You only have yourself to blame. The pear-dev list should carry warnings and discussion on this (rather than silly voting traffic). The QA (better "integration") team should resolve disputes.

8 ) All packages should have install tests (like CPAN) to ensure correct installation. A failure here is an end user failure and should be considered very serious. Packages should be withdrawn until these errors are fixed. This could cause a cascade of withdrawn packages and so the motivation to fix this will be high anyway. Dependent packages have the right to edit the low level package or to write test cases as requirements. Again, the QA hit squad will be called in. This whole process of package withdrawal can be automated (rolling back to previous versions). Quality has to be taken seriously.

9) All packages should have regression tests. If you don't want other package maintainers wrecking your code then you should protect that feature with a test. If a test gets in the way of other work then that feature should be removed unless it was documented as part of the package. Note how this approach forces testing, documentation and refactoring as aside effect of the methodology.

10) The release numbering scheme has to be defined better. At the moment the only significant digit is the first which is causing rigormortis. Have a simple release number, r1, r2, etc for every change of interface. Make the alpha, beta and release definitions tighter. It you want evolution to work for you (you do, you do) then you need a way of safely propogating changes.

11) Top tier deprecation needs to happen cleanly and ruthlessly. The whole goal of a two tier scheme is to remove packages, not to add them. There should only be one or two releases in the top tier. Older releases should be removed and dependent code refactored. This places a burden on package maintainers to keep dependent packages up to date or get them dropped because of install failures. You were saying that you would get swamped by thousands of packages, right? Not with this scheme. You should find that peple will voluntarily withdraw from PEAR and move their packages to the open repository because of the workload. Evolution again.

12) Integration and reuse will be a problem because author's may protect themselves by writing everything from scratch. Well only if they want to document everything and test everything afresh and good luck to them. Even if they do (reuse has always been a bit of a red herring) the result will be greater stability allowing more refactoring. Quality over reuse if you will. I acknowledge this is an open issue, but methodologies are susceptible to iterative development as well. Also note that they cannot get into the top tier without dependents.

13) Avoid micromanagement. The "one true brace" convention would have died out years ago if it wasn't for PEAR. Let the package maintainers and the refactorers take care of these things so that pear-dev can discuss the utility of different interfaces. Let the automated systems take care of it. If they are writing high quality code that passes tests, has docs and has plenty of users and dependent libraries then they are doing it right. Lump it.

If PEAR really wants quality then it should organise itself around this characteristic. Quality just doesn't arise from dictats.

If you want I or you can repost this in pear-dev (like you need more comments :) ).

yours, Marcus
Roja
Tutorials Group
Posts: 2692
Joined: Sun Jan 04, 2004 10:30 pm

Post by Roja »

lastcraft wrote:The "one true brace" convention would have died out years ago if it wasn't for PEAR.
Ignoring every other point you made, I have to comment on this. Total flamebait, and frankly, I completely disagree. All of my projects follow it, phpbb follows it, and so do many of the major php projects out there. Plenty of others (adodb comes to mind) don't, as well. Its very much an opinion-thing, which is the point you shore up after this statement, but the statement itself implies the one-true-brace is less-widely-used, and inferior, and thats plain incorrect.
lsmith
Forum Newbie
Posts: 12
Joined: Fri Apr 09, 2004 9:54 am

Post by lsmith »

lastcraft wrote: I hate to start on a bad note, but I have to say I simply don't buy this. PHP3 and PHP4 had already started on the OO road without PEAR. PHP5 is a continuation of this and necessary to compete with .NET and to leverage Java designs anyway. Also there is a lot of OO stuff that is not needed by PEAR (final - why?) or anybody else. I would say Java has more infulence on PHP than PEAR judging from the result.
Of course PEAR was not the sole driving force. Anyways I didnt make this comment to start a <span style='color:blue' title='I'm naughty, are you naughty?'>smurf</span> contest :-)

What I wanted to say is that PEAR does have a certain amount of influence on internals@ and that we pushed for a fair amount of features to get in.
lastcraft wrote:
lsmith wrote:So what is a redundant package?
That's just the problem. There all sorts of reasons why one package may be better than another, ranging from simplicity, performance, support for procedural approaches, conformance to an industry standard and many others. It would be a lot easier to decide which packages are redundant once they have spent some time in the library. Doing it at the proposal time is impossible.

Also some existing packages just aren't very good. The only way to fairly oust the incumbent is to develop the new one along side.

Besides, what is actually wrong with a redundant package? What if both apd and XDebug were in PEAR at the same time for example? Does the sky fall in? You won't get thousands of packages if the barrier to entry is one of minimum quality and usage.
Yes and all of the reasons stated above (we wouldnt allow a procedural interface due to namespacing issues, which could easily be fixed by putting a class around a bunch of methods that can be called statically .. yeah lame but what can you do if the feature is missing from the language) sound like valid reasons for a "redundant" package.

We have Cache and Cache_lite for example.
We have DB and MDB.
We have have multiple template engines (well PHPLIB, IT[X] and Sigma are a useless redundancy .. but if you flame hard enough any opensource has a hard time to keep itself clean)
lastcraft wrote:
lsmith wrote:It was pointed out that a good core library needs to be driven by a core developer tema instead that can work on any part as they see fit.
Which is the nub. Is PEAR a core library (STL, boost) or is it a package repository (CPAN)? PEAR should decide and then open up the other field to something else. These goals are diametrically opposed.
Well we are a library of loosly tide packages and we never closed any field to anyone else.
lastcraft wrote:
lsmith wrote:We are taking a very different approach in our current effort to build up a QA team.
This is another god view way of doing things. Quality is an impossible characteristic to judge and open to even more abuse than before. Evolution and self selection would shift the problem.
I dont know if you read the actual QA team RFC, but the QA is more about assisting maintainers. But at the same time they are sort of a means to ensure a checks and balances between the users (and their bug reports) and the control over a package that a given maintainer has.
lastcraft wrote:
lsmith wrote:However I dont agree that error handling should not be handled inside the libs. Handling it outside is impossible.
This is not true if we stick to error handling. Error handling is not the same as logging however which is a more complicated cross cutting issue (the usual clean way to deal with logging is to attach a logging decorator around the observed object). Good error handling means that you actually have to log less information. The target of the logged data is also up to the application, in the same way an error handler should be.

It worries me that these two things are being mixed together. Are we going to end up with another framework style solution here with a PEAR error class having to know about lot's of additional resources and so forcing it's own inclusion? This has a ring of deja vu. A dependency injection approach (PHP5 now has interfaces after all) would be so much more flexible.
I dont follow your argument at all. The PEAR error handling doesnt handle logging. Thats why there is a separate package for that in PEAR. Its entire purpose is to ensure that there is a standard way to handle error codes, error messages in order to allow the creation of handlers that work across all packages.
lastcraft wrote:
lsmith wrote:Of course PHP5 opens new possibilities, but remember again that PEAR was one of the main groups of people making sure that exceptions have made it into PHP5
There were plenty of people clammoring for exceptions outside the PEAR community too. It's nice to hear that they didn't get heard :(.
[/quote]

See above. I wasnt claiming that.
lsmith
Forum Newbie
Posts: 12
Joined: Fri Apr 09, 2004 9:54 am

Post by lsmith »

lastcraft wrote: 1) If PEAR wants to be a class library (it obviously does) then how about promoting the phpclasses site into the php.net domain. Yes I know Manuel can be an ascerbic **** at times, but he has done more to build a PHP community than just about any other single person, as well as being a highly skilled developer. If he occupied classes.php.net then the flak would be taken from PEAR.
This is not our decision to make obviously. It is also not something we would oppose (not even if we even could). Actually I am good friends with Manuel.
lastcraft wrote: 2) Change the name to PEAL.
I fear its too late in the game to change the name, especially as I think the value in such a move is minimal.
lastcraft wrote: 3) Have a two tier system where the top tier membership is rule based. If there are two competing packages, then choose on dependency and popularity. PFC is still an old boys network. I suspect that we will see DB and DataObject in there pretty quick with no way of getting rid of them (for good or bad). The PFC should start empty or not at all. It should also be promotional as a search option only. No requirements to depend only on top tier packages for example. You want an enabler for change. Quality must emerge.
Actually the PFC system is about fullfilling alot of criterias, like documentation, tests, multiple active maintainers. Sounds to me like the concept is exactly what you are clamoring for.
lastcraft wrote: 4) Allow competing packages in the second tier. The requirements should be perfect installation (both tarball and installer), regression tests and a low latency in fixing bugs. Also the other requirements below. Documentation will sort itself out via the installer requirement and in the popularity of the package. Add more tiers if these have motivational effects.
I really dont understand the benefits in competing packages. There are plenty of places to have competing packages. If they fall into the definition of a non redundant package they are allowed in anyways. Competition is good and if someone comes with a fresh idea there is nothing stopping him getting his stuff into PEAR. If the idea is not fresh then we expect the person to rather work with the maintainer. If he is unwilling tough luck.
lastcraft wrote: 5) Allow outsiders to attach tutorials to packages to promote their own sites. You want documentation...why not get it for free?
We are talking about adding a comments system. Actually its just about someone implementing it. Beyond that we list external ressources on the supports page on pear.php.net
lastcraft wrote: 6) Insist that every package has at least two maintainers. Nothing improves code quality like peer review. These maintainers should be of equal status (no yes men and no empires). The Apache foundation insists on three, so maybe even three.
Well we have very different sized packages. However for PFC's we do have the 2 maintainer rule.
lastcraft wrote: 7) Refactoring is stone dead within PEAR and this is the root of the poor quality and rigidity. The QA hit team is a start (and I do actually wish this experiment well), but package maintainers need to be able to edit dependent packages. This means that if you declare a dependency you are giving that package the right to edit yours in the event of a test failure. If you don't want behaviour changed, then it is up to you to protect it with tests. You only have yourself to blame. The pear-dev list should carry warnings and discussion on this (rather than silly voting traffic). The QA (better "integration") team should resolve disputes.
Well maybe this is an extreme example, but in order to have this level of protection for MDB2 I would assume to require about 400-500 test cases.
lastcraft wrote: 8 ) All packages should have install tests (like CPAN) to ensure correct installation. A failure here is an end user failure and should be considered very serious. Packages should be withdrawn until these errors are fixed. This could cause a cascade of withdrawn packages and so the motivation to fix this will be high anyway. Dependent packages have the right to edit the low level package or to write test cases as requirements. Again, the QA hit squad will be called in. This whole process of package withdrawal can be automated (rolling back to previous versions). Quality has to be taken seriously.
Well tests are a very relative thing. I have a test suite for MDB and MDB2. It doesnt cover the entire API, all possible combinations of methods by far. So just checking for the existance of a test suite seems a bit off base as the quality of the test suite is a bit harder to judge than that. For PFC's we expect that the test suite is complete (and this will be checked in order to gain and keep the PFC status). However this is always a question of barrier to entry and ressources.
lastcraft wrote: 9) All packages should have regression tests. If you don't want other package maintainers wrecking your code then you should protect that feature with a test. If a test gets in the way of other work then that feature should be removed unless it was documented as part of the package. Note how this approach forces testing, documentation and refactoring as aside effect of the methodology.
this point sounds a bit redundant .. anyways see my previous comments above.
lastcraft wrote: 10) The release numbering scheme has to be defined better. At the moment the only significant digit is the first which is causing rigormortis. Have a simple release number, r1, r2, etc for every change of interface. Make the alpha, beta and release definitions tighter. It you want evolution to work for you (you do, you do) then you need a way of safely propogating changes.
I dont understand what you mean about only the first one mattering. here is a recent announcement that covers this topic:
http://pear.php.net/group/docs/20040226-vn.php
lastcraft wrote: 11) Top tier deprecation needs to happen cleanly and ruthlessly. The whole goal of a two tier scheme is to remove packages, not to add them. There should only be one or two releases in the top tier. Older releases should be removed and dependent code refactored. This places a burden on package maintainers to keep dependent packages up to date or get them dropped because of install failures. You were saying that you would get swamped by thousands of packages, right? Not with this scheme. You should find that peple will voluntarily withdraw from PEAR and move their packages to the open repository because of the workload. Evolution again.
right this is what the PFC package are all about
lastcraft wrote: 12) Integration and reuse will be a problem because author's may protect themselves by writing everything from scratch. Well only if they want to document everything and test everything afresh and good luck to them. Even if they do (reuse has always been a bit of a red herring) the result will be greater stability allowing more refactoring. Quality over reuse if you will. I acknowledge this is an open issue, but methodologies are susceptible to iterative development as well. Also note that they cannot get into the top tier without dependents.
Sounds more like the barrier to entry in your system is so high that nobody will bother. Also I know that most of the people in PEAR have chosen PEAR exactly because they have wide control over their package. They are using their package in commercial apps and their company would prohibit them from putting their package in PEAR if the chance of them having to follow someone elses changes frequently.
lastcraft wrote: 13) Avoid micromanagement. The "one true brace" convention would have died out years ago if it wasn't for PEAR. Let the package maintainers and the refactorers take care of these things so that pear-dev can discuss the utility of different interfaces. Let the automated systems take care of it. If they are writing high quality code that passes tests, has docs and has plenty of users and dependent libraries then they are doing it right. Lump it.
Sorry but the CS is a fact of life. Its simple to follow if you care the least bit, especially as there are tons of tools to handle it for you. I use a different CS at my company btw but I simply accepted the PEAR CS.
lastcraft wrote: If PEAR really wants quality then it should organise itself around this characteristic. Quality just doesn't arise from dictats.
Code doesnt either. PEAR cant support itself from computer science students that have too much time on their hands. Some of your suggestions are fairly out of this world. Especially since PEAR packages are not self contained apps or plugins. Most changes in a PEAR package will have immediate results on the API which means that tons of hands working on a single package will probably not make anyone happy.
lastcraft wrote: If you want I or you can repost this in pear-dev (like you need more comments :) ).
There is a common theme in all of these comments. People feel that PEAR should have a higher barrier to entry, or a lower or both. They stress different things etc. Especially since PEAR is a PHP subproject that provides userland implementations, developers who also write userland code that they necessary need to be represented in PEAR. While we certainly try to get as many competent developers inside PEAR the reality is that we cant possibly fit all of their tastes. The same is true of PHP itself. I have tried to get my share of functions into PHP and so far I havent succeeded.

Does that make PHP the elitest devil? No it just means that for one reason or another my contributions havent been accepted into PHP. Of course its a bit dissapointing. However I didnt feel the need to create a fork. But the good thing is that there are all sorts of userland repositories and libraries that provide userland implementations for you all to join.

Our developer number is increasing rapidly. We are getting tons of proposals and we are getting tons of packages accepted. At the same time our infrastructure as well as existing packages improve. For those of you reading the pear-dev mailinglist you know that not everything is total agreed upon among the PEAR developer community. But by and large I fail to see where PEAR is going down the drain. Quite the opposite I would say that PEAR is becoming better and better and growing nicely. Therefore I think that there is little need for PEAR to turn itself upside down.

However that doesnt mean that there is no room for competition. Actually we all know there is plenty already. So I wouldnt say all is well in PEAR, but I would claim that our direction is generally ok.
lastcraft
Forum Commoner
Posts: 80
Joined: Sat Jul 12, 2003 10:31 pm
Location: London

Post by lastcraft »

Hi...

I promise this will be my last post on the subject. I never feel happy ranting anyway.
lsmith wrote:This is not our decision to make obviously. It is also not something we would oppose (not even if we even could).
No obviously, I was just illustrating that PEAR is trying to do two things.
lsmith wrote:I fear its too late in the game to change the name, especially as I think the value in such a move is minimal.
Sorry, I should have put a smiley after that one as it was tounge in cheek. I'll put one in now :).
lsmith wrote: Actually the PFC system is about fullfilling alot of criterias, like documentation, tests, multiple active maintainers. Sounds to me like the concept is exactly what you are clamoring for.
Yes, but not quite. If packages get in by private discussion then nothing has changed. We will just get a headlong rush by existing maintainers of existing packages. The quality goal will not ultimately be achieved.
lsmith wrote:Competition is good and if someone comes with a fresh idea there is nothing stopping him getting his stuff into PEAR. If the idea is not fresh then we expect the person to rather work with the maintainer. If he is unwilling tough luck.
What if the original maintainer is not willing? What if all is needed is an extra feature and the original maintainer does not have time or interest to add it. There are umpteen ways this could (and sadly does) fail. Getting good packages would have to start by getting good packages in the first place so that they can demonstrate their worth. It may take that to make a point against the original maintainer. At the moment PEAR is stuck with whoever got their first. Tough luck indeed.

Yes I am in favour of PFC, but from the earlier docs at least (I have stopped following pear-dev) it just seems adornments to the same system.
lsmith wrote: We are talking about adding a comments system.
I would be +1 for that, but what about tutorials? It would be easy (usual security aside) to add a tutoral linking option to the docs pages.
lsmith wrote: Well we have very different sized packages. However for PFC's we do have the 2 maintainer rule.
Which is good (actually I knew this, but thought it worth emphasising).
lsmith wrote: Well maybe this is an extreme example, but in order to have this level of protection for MDB2 I would assume to require about 400-500 test cases.
You would only need test cases for enforcing features that you would want to keep. Also, with respect, that is an exaggeration. I have built object persistence layers with less than 100 test cases all in. You don't test combinations unless the design is so broken you have no control over it.
lsmith wrote: However this is always a question of barrier to entry and ressources.
But that is my very point in the post. You can tune the barrier to entry to get the quality desired. You cannot claim on the one hand that you will get swamped by duplicate packages and on the other that no one will submit anything. Drop the silly redundacy rule (a non quality discriminator) and introduce rules that have built in motivatiors to quality.
lsmith wrote: this point sounds a bit redundant .. anyways see my previous comments above.
I just wanted the list to be reasonably complete.
lsmith wrote: I dont understand what you mean about only the first one mattering. here is a recent announcement that covers this topic:
http://pear.php.net/group/docs/20040226-vn.php
OK, I cannot keep up with every single announcement and again I wanted to get every suggestion out in one go.
lsmith wrote: right this is what the PFC package are all about
I hope so. I have to say I will reserve judgement until I see a package actually removed in favour of another.
lsmith wrote: Sounds more like the barrier to entry in your system is so high that nobody will bother. Also I know that most of the people in PEAR have chosen PEAR exactly because they have wide control over their package. They are using their package in commercial apps and their company would prohibit them from putting their package in PEAR if the chance of them having to follow someone elses changes frequently.
Well that is fine in a package repository. It is a disaster if you want to produce a cohesive class library. Again we get the question - which do you want?
lsmith wrote: Sorry but the CS is a fact of life. Its simple to follow if you care the least bit, especially as there are tons of tools to handle it for you. I use a different CS at my company btw but I simply accepted the PEAR CS.
It wasn't the existence of a CS that is the problem, it is the scale of it. Code indentation really is not important in a CS, just a personal preference. Pretty printing can always be included as part of the package release. Such things as naming conventions (whether to have "get and "set" on accessors, calling storage solutions "finders" or "repositories") and structural decisions (avoiding static methods, all bridges to use interface parameters, factories for object creation, etc, etc) are far more important interfaces. Why is someone's personal preference enshrined in PEAR? It is micro management. Let the coders code and concentrate on bigger issues.
lsmith wrote: Code doesnt either. PEAR cant support itself from computer science students that have too much time on their hands. Some of your suggestions are fairly out of this world.
Apparently it does if you are about to be swamped by redundant packages ;). Also refactoring, regression testing, shared code ownership do not come from CS students, they came from the Smalltalk and Java trenches nearly ten years ago. Is PEAR so far behind that it considers these terms part of computer science?

Ok, that last comment was gratuitously rude and I apologise. Yes my comments are wild - extreme even - for a public repository. But PEAR doesn't want to be a publi c repository does it? It wants to be a class library. Also you can tune bariers to entry to get the desired level of support. At the moment the barrier to entry is how late you enter the PEAR club.
lsmith wrote:Especially since PEAR packages are not self contained apps or plugins. Most changes in a PEAR package will have immediate results on the API which means that tons of hands working on a single package will probably not make anyone happy.
This is an unfounded fear. You won't get this situation except with dependency breakage. I regularily consult on projects with 500+ classes and completely shared code ownership. It all works out fine even with developers in remote locations.You do need tests though.
lsmith wrote:People feel that PEAR should have a higher barrier to entry, or a lower or both.
It is in a state of contradiction and you avoided my main question. Is PEAR CPAN or is it a class library? Myself I would like to see PEAR go the CPAN route, but would be nearly as happy with it becoming a class library. What do you think it is?
lsmith wrote:the reality is that we cant possibly fit all of their tastes.
Then don't do it on taste at all. The tastes selected are pretty random anyway, on a first come first served basis or whoever screams the loudest it seems. Also this is not about appeasing sour grapes from developers getting rejected, it is about an evolutionary approach to improve quality. Rejecting packages because of lack of tests or failing to keep up with dependencies is way more brutal .
lsmith wrote:Does that make PHP the elitest devil?
The core language has to be controlled by a small band of professionals because it must be minimal (if only :( ). The extension system is more open and I would say that the PHP language is not elitest at all. I am not saying PEAR is elitest even. I think that PEAR's processes are broken however and produce pretty much random results.
lsmith wrote:So I wouldnt say all is well in PEAR, but I would claim that our direction is generally ok.
There is a bit of a bubble surrounding PEAR. The authors do their conferences, write their articles, see the Netcraft surveys and think all is well. The PHP crowd averages only a few years of experience and so criticisms are few. Unfortunately it just isn't real. These developers are getting better and they are trying out other environments. When they do they just don't come back. Vincent Oostinde and Joe Walnes have gone to Java to name two.

I have to deal with Java develpers a lot, and guess what? PHP is a bit of a joke. Such things as JDO, lexers, SAX streaming, mock objects, HTML parsers, full text database support, SOAP, RDF, custom tag templates are still missing, alpha, broken or incomplete. Ok, Java has lumbered itself with Struts and is just about the most verbose language I have ever seen (Cobol excepted) so there are still reasons to use PHP. Trouble is, Ruby has been around a lot less time and already has better library support. Perl just isn't the benchmark anymore.

Now I love PHP, and actually I do like a lot of what is in PEAR. I am optomistic that the new focus on testing will cause a major shakedown and that is a major step forward. I have made minor anonymous contributions to PEAR and tried to submit whole packages. I have been rebuffed, but I didn't whine about it, I just carried on. I still write PHP code and I still publish it (on Sourceforge), so I am not trying to shoe-in my own stuff to PEAR. I also see a lot of PHP developers starting to come on really strong now and things are getting exciting with the new language. Why the posts of gloom? It is just that I think PEAR is mired in stagnation because of it's processes and draws publicity from other worthy projects. I think it will hamper PHP and probably already does :(.

That really would be tough luck.

yours, Marcus
lsmith
Forum Newbie
Posts: 12
Joined: Fri Apr 09, 2004 9:54 am

Post by lsmith »

lastcraft wrote:
lsmith wrote: Well maybe this is an extreme example, but in order to have this level of protection for MDB2 I would assume to require about 400-500 test cases.
You would only need test cases for enforcing features that you would want to keep. Also, with respect, that is an exaggeration. I have built object persistence layers with less than 100 test cases all in. You don't test combinations unless the design is so broken you have no control over it.
Well in the case of MDB things can get tricky with buffering emulation and so on. So alot of internals things affect how different methods work. Anyways an extreme example of course.
lastcraft wrote:
lsmith wrote: However this is always a question of barrier to entry and ressources.
But that is my very point in the post. You can tune the barrier to entry to get the quality desired. You cannot claim on the one hand that you will get swamped by duplicate packages and on the other that no one will submit anything. Drop the silly redundacy rule (a non quality discriminator) and introduce rules that have built in motivatiors to quality.
Well with your requirements we will only get packages from bored computer science students. I can tell you that while I am not saying these guys are not competent, but they do tend to lack knowledge of about the real world. Right now we get most code from people who actually work in the real world. This however creates the problem of lack of documentation and to some extend testing suites. However especially the documentation problem should be addressed by having people who help out (most of PHP docs were written by someone else than the original author).
lastcraft wrote:
lsmith wrote: Code doesnt either. PEAR cant support itself from computer science students that have too much time on their hands. Some of your suggestions are fairly out of this world.
Apparently it does if you are about to be swamped by redundant packages ;). Also refactoring, regression testing, shared code ownership do not come from CS students, they came from the Smalltalk and Java trenches nearly ten years ago. Is PEAR so far behind that it considers these terms part of computer science?
The development methods used for PHP and Java are very different. Developing PHP like its Java is senseless imho as you loose out all the advantages that PHP has and end up with an inferior "Java wannabe".
lastcraft wrote:
lsmith wrote:People feel that PEAR should have a higher barrier to entry, or a lower or both.
It is in a state of contradiction and you avoided my main question. Is PEAR CPAN or is it a class library? Myself I would like to see PEAR go the CPAN route, but would be nearly as happy with it becoming a class library. What do you think it is?
Its a library.
lastcraft wrote:
lsmith wrote:the reality is that we cant possibly fit all of their tastes.
Then don't do it on taste at all. The tastes selected are pretty random anyway, on a first come first served basis or whoever screams the loudest it seems. Also this is not about appeasing sour grapes from developers getting rejected, it is about an evolutionary approach to improve quality. Rejecting packages because of lack of tests or failing to keep up with dependencies is way more brutal .
A fundamental philisophy in PEAR is that we dont want to make our users switch to new API's constantly. We think this would diminish our users value even more than missing out on some new feature (or maybe just having to wait a bit longer). At the same time we assume the willingness to cooperate. This doesnt always hold true, but so far it worked alright.

One thing that I want to make clear since I am not sure I have made that point so far:
There is room for refactoring in PEAR. Any author can create a new BC breaking major version. If a package becomes abonded this new major version can be provided by someone else. Either way we ask the API changes to be as small as possible.
lastcraft wrote:
lsmith wrote:So I wouldnt say all is well in PEAR, but I would claim that our direction is generally ok.
There is a bit of a bubble surrounding PEAR. The authors do their conferences, write their articles, see the Netcraft surveys and think all is well. The PHP crowd averages only a few years of experience and so criticisms are few. Unfortunately it just isn't real. These developers are getting better and they are trying out other environments. When they do they just don't come back. Vincent Oostinde and Joe Walnes have gone to Java to name two.

--snip--java--snip-- Trouble is, Ruby has been around a lot less time and already has better library support. Perl just isn't the benchmark anymore.

--snip--gloom--snip-- It is just that I think PEAR is mired in stagnation because of it's processes and draws publicity from other worthy projects. I think it will hamper PHP and probably already does :(.
This is software, we dont do the higlander "there can only be one" thing. Furthermore I think you are underestimating the level of growth the PEAR community is experiencing over the last years. But then again I havent been closely monitiring RUBY either. I do envy their language level sandboxing (aka taint levels).
lsmith
Forum Newbie
Posts: 12
Joined: Fri Apr 09, 2004 9:54 am

Post by lsmith »

In summary I will take all of your comments and while I dont agree with some, feel that we already have resolved or are about to resolve others there is obviously value in all your suggestions. I will see how things will go and how PEAR will evolve. Knowing the world is not black and white it still might be that we, the PEAR folks, are all wrong. Maybe even my vision is just all wrong. Knowing how hard the opensource world can be on projects who fail to keep their userbase coming it just might be too late to change PEAR around in case it turns out that the current PEAR vision is wrong. So lets all hope its not :-)
Post Reply