Re: Forking PEAR

Stephan Schmidt wrote: > Heino H. Gehlsen wrote: > > > The current endless discussions proves to me, that some > > serious decisions have to be made, and considering some of the inexperienced > > opinions on this list I'd say, that every single opinion shouldn't always be > > taken into account at all times - perhaps people should simply keep quiet > > when they know not of what they speak (e.g. recent discussions about > > exceptions and protected) Just to clarify what I meant here is that if you are not absolutely sure of what you speak; don't talk with too much authority. If you don't make it clear from start that you might lack experience, you might end up wasting other people's time, and even confuse people who as initially unsure, but had actually gotten it right from the start (e.g. PER_ErrorStack). There are also many who read the list without participating at all. They read the list to stay up do to date; not to suffer from misinformation etc. > On what do you base your judgement? Personal empirical observations through the past two years = my own opinion/experience ;-) > I've been expressing my opinion on > exceptions and I'm against using them at the current point. I too have mixed feelings about exceptions at this very moment; I'm used to exceptions, and would like to se them well implemented in PEAR, but I don't want to se every package rewritten just to use exceptions for the sake of exceptions. While the talks have often been about exceptions etc., I'd rather have talks of interfaces. If we don't have a rather well designed set of interfaces, we might as well keep on updating the current repository. On the other hand should we choose to use interfaces, I personally would like to se a completely new repository, which wouldn't suffer for historically bad decisions. Interfaces would even make the QA work so much easier, since the developers would have to comply with the predefined interface, and generally there would be so much less confusion. > But this has > nothing to do with my knowledge about exceptions, but my knowledge about > the users of PEAR. I'm not only maintaining PEAR packages, but also > working on php-tools.net for three years now and get a lot of feedback > from the users of my packages. I'm sure that a lot of people will be > having a hard time adjusting to exceptions and this will take a while. This is something everybody on the list should be able to foresee, or at least that is my hope!!! And that is just one of the reasons I believe forking of the repository is the way forward. > Furthermore I'm working for Europe's largest ISP and they just switched > to PHP4.3 about one month ago. So it will surely take some time, till > the standard PHP developer will be able to use PHP5 only packages. Being the maintainer of Net_NNTP I know all too well that PHP4.3 has also had it flaws. In fast Net_NNTP haven't worked acceptably on PHP4.3 until the recent v4.3.7 release. > I have to admit that I feel a little insulted by Hans and you if you > supress my arguements by writing that I wouldn't have enough > knowledge about PHP5 or exceptions. Thank you for not automatically assuming that I (can't speak for Hans, can I ;-) believe that you don't have any/enough knowledge about PHP5 or exceptions. During the year 2004 I've only had spare time enough to read a good handful threads on the dev mailing list on a temporary basis, and I've often forgotten who wrote what rater quickly, so I actually don't remember if I (dis)agree with you. > If I develop something, that does not fit into PEAR I'm not all "PEAR > must change", I just put it on php-tools.net as I can do what I want, > there... That's the case for patTemplate, as I did not want another > flame war on templating engines. I'm not saying that PEAR should change to allow any of my stuff into the project. What I'm actually saying is that PEAR should take the consequence for the updated engine and start planning of a complete new well-designed repository. I have myself rewritten quite a few PEAR packages from the ground up, and I should be damned if PEAR blindly accepted my own repository as a basis after a tabula rasa. I too have code in my own toy box ;-) > PEAR is huge, and huge things tend to change slowly. PHP5 took 2 years, > why do we have to change in 1 month? We shouldn't, that's for sure! The reason I'm a little frustrated is that while PHP5 have been in beta testing for around a year, almost nothing that concerns PHP5 have happened in PEAR until recently. > I certainly embrace PHP5 with all its features and I will be playing > with it as I did since beta1 That was also the version which caught my serious interest, and I've been planning ever since. > (in fact I'm currently developing a PHP5 > only PECL extensions), but I don't think that we should rush things with > PEAR, as PEAR is mainly about stability. But this is absolutely why I propose this forking into channels, since the existing code would still be stable, and a lot of development could still be do, without preventing those of us, who'd like to work out on optimal infrastructure from working. > I had several problems with BC > breaks in packages and I'm really grateful that people like Lukas and > Greg are putting effort into keeping PEAR compatible with older > versions. Surely Greg could have been implementing channels a lot > faster, if he did not care about keeping the installer compatible with > pre-channel versions. Backward compatibility is a nice and important thing, but sometimes one has to start over. A few examples comes into mind: Apache HTTPD 2, Apache Tomcat (instead of Jserv), Apache Cocoon, Apache PHP4, MacOS X, Windows 95 & Longhorn. I could keep on writing. > I will not take part this discussion, as I got more pressing things to > do, I just wanted to express my views on these topics. I respect that, and will use BCC instead of CC in case someone should reply ;-) Regards, Heino