Re: Forking PEAR

David Costa wrote: > On Jul 15, 2004, at 9:17 AM, Heino H. Gehlsen wrote: > > > > Disagreeing is fine (it's surely not the entire PEAR community which is > > becoming fragmented), but that still doesn't change the fact that any > > further development of the current PEAR repository will tighten the > > knot even more. > > I don't think that PEAR should be for everyone. Is PECL for everyone ? > no.... Although I agree that PEAR shouldn't be for everyone nor everything, I see absolutely no connection between my works and yours. > I personally started to discuss about Exceptions before I knew anything > about them. Each discussion among skilled and intelligent > developers might often spring in a learning opportunity and this was > certainly the case for me and many developers. And I inherited an orphaned package, which ended up being totally rewritten - and so what? > The system is very democratic and that's what open source is all about. Eh, neither Linux nor Apache nor PHP is as 'democratic' as PEAR! Open source isn't all about being 'democratic' - quite of often oligarchy is the actual government of an open source free software project. > >> PEAR is an open source project that does not only deal with code, it's > >> about defining standards (which get accepted by a large variaty of > >> other > >> projects, open source and even more commercial). If you're unlucky > >> with > >> that, stay in coding and just keep an eye on what's really decided. > > > > Hmmm, that's strange. Last time I checked the front page, it clearly > > stated > > that "PEAR is a framework and distribution system for reusable PHP > > components". In my opinion way too much is currently put under the same > > umbrella. Take the recent PEPr wote "Proposal for ProtectedMembers" for > > instance. If PEAR's primary focus isn't code, why were only people who > > had a > > developer account allowed to have influence on the coding standard. > > Currently one practically has to be a maintainer of a package to be > > taken > > seriously, and that package doesn't even have to be well maintained or > > more > > than a few hundred lines. Come on, PEAR is all about code. > > > It is the same in PECL and any other official repository, to be taken > seriously you first have to help the community in > a way or another. Is like being able to vote once you gain > citizenship... What I meant here is that if PEAR is all about community, it shouldn't only be developers with a pear account who could vote on coding standard changes; it should be the whole community. That's all... Now that you mention 'citizenship', I believe that it's way to easy to get full 'citizenship'. One only has to get even the smallest package into PEAR, and one gets a vote, and thus get as much influence (when voting) as a the most active PEAR developers through years. > > My original point was that too much time is spent on arguing, and most > > certainly on people who keep arguing based on way too fragile > > knowledge of > > what they are arguing about. PEAR is IMHO currently suffering from a > > typical > > open source symptom: Too many chefs reduce productivity to a minimum. > > Sorry this is non sense. Mailing lists are opened and as such you can't > decide what people should or should not argue about. Your > statement is contradictory: first you don't want too many chefs then > you want to limit the discussion on public mailing list under some > unclear boundaries. Wow, did I write that? Sorry, but please read my words once again without being prejudiced. Reading my own words, I believe I said something like: "too much time is spent on arguing" and sometimes people "keep arguing based on [a] way too fragile knowledge". Finally I hinted that being too many people making decisions often take a lot of time... > If someone doesn't know a new concept like Exceptions (which is not > even documented beside very little material like Zend) how is he > supposed to learn without asking some questions ? (which at first > might come out as naive) Eh, I tried one search on Google (I'm Feeling Lucky) for "what is exceptions", and i ended up with one of Sun's tutorials, which introduces exceptions. Of cause it would have been optimal if PHP had had a better introduction of exceptions, but come on, some of those questions that have been asked on the dev mailing list should have been sent to general instead... > >> It's the other way around. Instead of saying "we make something new, > >> cause they made something new" we say "they made something new, let's > >> integrate it". > > Not really. Hey, we actually agree upon something ;-) > >> What you currently see (and saw in the last month) is the > >> process of creating something new, without completly breaking the old. > > > > What I'm currently seeing here is a lot of people who refuses to > > acknowledge > > that the current situation calls for tabula rasa, if we are to avoid > > the > > forthcoming mess. > > Whilst I do respect your opinion, please don't pretend that your view > reflect the majority ;) > There is no forthcoming mess. Rules and standards are made to avoid the > mess, not to create it. I don't believe in anarchy and we follow > the same structure as the PHP project, there is a group etc. Honestly I can't remember when I've seen an active/visible PEAR Group - for now all they've come up with is a few I've only seen a few administrational documents concerning version numbering, package proposals directory structure and license restrictions. To me is seems that the PEAR Group has become more of a formality that the once feared almighty kings of PEAR, who wasn't even elected. Today I'd personally like to see a much more powerful PEAR group as well a much more powerful QA Group. The members of those two groups does a low of work, and its about time the developers of PEAR came to that conclusion and accepted the structure! > Try to go on Internals and tell them that their group is a mess and you > want to add anything you like on PECL because is your visition... ??? Eh, I don't see any connection here... > > I wasn't saying that PAER will break in front of the challenges. What > > I'm > > trying to say here is that way too much effort is wasted at the moment > > because of the illusion that one repository can fit the all (both > > users and > > PHP versions). > > It can. We had PHP 5 only packages before PHP 5 went stable so we are > really on a good sync. Come on, having a few packages which rely on a few PHP5 features aren't what I'm talking about! Had PEAR been on a good sync we would have already had endless discussions about interfaces etc., and would at least have a few proposals as to some of the central packages could be improved... > > Sure we could start all over, and I could release a PHP5-only version > > of > > Net_NNTP, which didn't implement the same base interface as Net_POP3 > > etc., > > and we would once again and up with a repository containing a log of > > great > > packages which isn't designed to work together. > > > > We will suffer the same maintenance overhead in the current > > repository; we' > > ll just have to maintain multiple packages (different major versions > > of each > > package), when the PHP5-only packages kick in! > > Well do you have any other way to have a package PHP 4 and PHP 5 > E_STRICT at the same time ? If you do, let me know. I don't see any connection here either - all I said was that we'd end up maintaining two different versions of a lot of packages at the same time, so I don't see how it would generate any extra overhead having those two packages in two different channels. > There are a number of major changes from PHP 4 and PHP 5 and the straw > man that because of that PEAR is not good enough doesn't make sense to > me. > > The code should evolve and you should see this as an opportunity to > enhance your package. > > You are also free not to do a PHP 5 version so is really up to you. First of all I've already 'ported' my one package, Net_NNTP, to PHP5. I haven't released anything though, and will not do so until the debate about exception is over. And by the way, excuse me, but what happened to that community thing? Not it 's suddenly all up to me to do a PHP5 version? Wouldn't it be nice if e.g. the QA team first accepted some common interfaces, which should be implemented I every mail related networking package? > > Those of us, who talk so fondly of PHP5-only packages, don't think that > > simply adding a dependency to "PHP ge 5.0.0" does the job; that's > > merely a > > package property. > > Please don't try to mix your views with every PHP 5 developers > sentiment. I, for one, don't agree with you. I most certainly wouldn't do such a thing; I thought that by referring to "Those of us, who talk so fondly of PHP5-only packages" I wouldn't end up receiving such comments. > > What we foresee is a whole new situation where the new > > engine features will have a central role. > > > What you foresee.. Ok, now I'm actually becoming irritated too. Although I don't agree with your interpretation of "Those of us, who talk so fondly of PHP5-only packages", you don't have to point it out two times in the same email :-/ > > Well, I've been working on large projects too, and I do agree that such > > dependencies are normal, but PHP is only a mere scripting language! I > > don't > > suppose that you leave it up to the users of your projects to figure > > out > > which versions to use? > > > So we should perhaps even install the package for the user ? Sorry but > I don't think PEAR is for people which are too lazy > to read the docs.. Eh, come on, where did that come from? Have > > I'm not talking about throwing neither the installer nor the > > repository out > > of PEAR community! I'm talking about dividing PEAR into subprojects > > here. > > Having a base project containing the installer etc. and a number of > > subprojects handling different repositories etc. makes so much more > > sense to > > me than having one overly sized and totally unmanageable project. > > > -10 for me Personally I couldn't care less at the moment. > > In the end of my initial email I actually martially proposed that the > > installer should become the heart of PEAR, and that the repositories > > should be moved into official PHP subprojects. > > > why that ? Assuming you have already read that mail, I assume you have an idea since you have just 'voted' -10. > > No more than pretty much every other open source project under the > > Apache Software Foundation umbrella. > > > > Does that mean that I have to participate in the PEAR debate club > > simply > > because I some time ago chose to become a PEAR maintainer? No way! > > Well feel free to unsubscribe if this is the case. I do apologizes if > this came out as rude (and is not my intention) No offence taken, but once again, I simply can't figure out which historical email you cut and paste you comments from. (This is certainly not meant as a general offence, but that's my actual impression of the email I'm replying to) > but really I am somehow immune to the common argument "change PEAR > or..." Hmmm... That's funny you should write that, cause I've not used any common arguments like "change PEAR or...". After being absent and passive for half a year, I've only had time so follow the threads on the list, and when I got some spare time available I came with a straight forward proposal. Should I use arguments such as "change something, or ...", I would politely ask you to "change you attitude, or ..."... Hmmm... Perhaps I won't even bother to read any further mails from you. > > Perhaps being both a central installation framework, a > > community/institution > > (with 1000nds of users), AND a (PHP4 based ;-) code repository at the > > same > > time is one of PEAR's major problems. > > > PHP 5 just released a stable version two days ago. Yet it has been in beta testing for around a year. Once again I simply don't see any connection between what I wrote and your short comments... > >> Did you ever think, the Linux Kernel should be forked into > >> seperate projects for each major version? > > > > Aren't the Linux Kernel forked into separate branches at each major > > release? > > > No and you can't code for the Linux kernel unless you know what you are > doing and listen to the "chefs". No? Then it's rather funny that http://www.linuxheadquarters.com/howto/tuning/kernelreasons.shtml clearly mentions branches. > >> The name is weired, though. Just stay on the initial name "PHP > >> Extension > >> and Addon Repository" and you are fine. ;) > >> > >> (Sorry, I can only take that for a joke.) > > > > Well, I guess it was kind of a joke;-) the acronym is fine, but > > perhaps the > > time has come for a reevaluation of what is stands for. > > > I disagree. Sure, fine, whatever. After replying to you email, I've actually come to the conclusion that I actually don't care about your opinion - at least for now that is... > > Perhaps you are right, perhaps time has mutated PEAR into "The PHP > > Speakers Corner"; at least that's the impression I get, when > > I read the developers mailing list. > > So your ideal project is a moderated mailing list where only things > that you deem appropriate pass the check ? That's your words, not mine! > > Perhaps PEAR has become more of a forum where users can seek > > help, when they can't figure out the API's of the non-evolving > > repository. > > PEAR has run into serious problems, and if we keep following the > > current path, the repository will end up a complete mess. > > > That's your opinion but don't expect everyone to agree. If you want to > help, start helping with packages orphaned and things like that. Well, there is one minor problem here: I don't want to touch any of the old PHP4 code any more - that's history in my opinion, and I wont do any thing beyond fixing bugs etc. > Sorry but I started with Docs then doing things other developers didn't > fancy that much so I don't think PEAR should be only about you and what > you think but about the community. You've already written how you started once, and excuse me for saying this, but I am not the one to say that PEAR should be only about me and what I think. I came with a mere proposal based on an analysis of the current situation. What I proposed was a way to harmonize PEAR. > > One thing is for certain: Way too much time and effort is wasted in > > PEAR at > > the moment! Take Greg's Error_Stack for instance. People haven't even > > taken > > their time to study it, but they keep saying how bad it is at this and > > that. > > Not true. It was a PHP 5 discussion and I trust you can find my points > and the others clear enough. Then please explain to me why a clearly frustrated Greg stated that he "have become very annoyed with misinformation regarding PEAR_ErrorStack vs. Exceptions" and "[...] developers who have not yet used the package claim it does not solve any problems successfully." Regards, Heino