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