Re: code from other repositories and PEAR (was: Discussion of SCM_SVN Proposal)

From: Date: Sun, 18 Apr 2004 13:54:40 +0000
Subject: Re: code from other repositories and PEAR (was: Discussion of SCM_SVN Proposal)
References: 1  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-27914@lists.php.net to get a copy of this message
I am moving this to a new thread as I really dont think it belongs into the original thread which should focus on the technical and not the political path my new subthread will be going. DISCLAIMER: As I dont know the original thread at all, nor do I expect everyone who will participate in this thread to know the original thread well enough, people should not interpret this thread too much. For example while further down I talk about code being superior or inferior I am not commenting that either side in the original thread fills either role necessarily. So all in all this thread is about talking about how code outside of PEAR affects what we allow inside PEAR. Bertrand Mansion wrote:
So what I wanted to say is that you all are really doing a hood job of getting to the root of things and that "outsiders" need to really know what they are saying before they jump in. Otherwise they run the danger of heating up a debate that was well on its way in the right direction
What do you mean by "outsiders" ?
People who are not fully aware of the entire topic at hand.
Maybe clarify that a bit more .. since I dont consider my self an "insider" of the topic at hand, I wouldnt know who all the "insiders" are, but they would certainly include be Chuck, Jan, Clay and Volker. All I am saying is the thread is moving in the right direction from my perspective as an "outsider" to the topic, so I just wanted to say that people trying to mediate should be aware that they might do harm to something which doesnt seem to need mediation. That being said I am not telling people to shut up who have valueable things to say and who have taken the time to get intimate with the topci at hand.
I personally think that people familiar with Subversion and who have reviewed Clay's code, are, in your own terms, "insiders" because they are trying to find out if Clay's code is ok to be included in PEAR and which changes are needed. Alan's comments on Clay's code are actually very pertinent.
Exactly.
On the other hand, I think Chuck and Jan are "outsiders", because whether Horde_VC is to go in PEAR or Clay's code is to go in Horde has nothing to do with Clay's proposal and our all proposal system in PEAR.
No, by my definition they are "insiders", because they know the topic quite intimately (aside from that they are also PEAR developers .. being Horde developers doesnt make them any less a PEAR developer, actually due to the close relation PEAR and Horde has every Horde developer is half on the way of being a PEAR developer).
In the past, we have said no to Binary Cloud, to PHPlib, and maybe a few others. I don't see why Horde should be treated differently. If people from Horde want to contribute to PEAR, good. There is PEPr for that. If they think their code is better available only in Horde, good too. There are probably advantages to both solution.
No, we have not said no to BC, PHPLib or Horde for that matter. We have said we want the best code in PEAR. And we want whatever code to follow our coding standards. This means to me that we will not accept inferior code (especially from an architectural POV) even if there is opensource source code which uses a PEAR compatible license. It also means that any code from other repositories that is to become part of PEAR needs to be PEARified. We obviously have a problem if there is a need for a given set of features but the person willing to offer his code, which for some reason or another we find to be inferior to PEAR license compatible code that does not follow the PEAR conventions. This should not happen ideally because the person offering the code should then instead incorporate that other code into PEAR. Reality tells us that what is "inferior" is relative and that the willingness of people to work with other peoples code might be limited. This is when we have to start mediating and/or making difficult decisions, which in the end might bave to be resolved through a vote in PEPr.
But that's not the point. The point is really that people see PEAR as being closed (as shown in the recent discussions we had) and the way Clay's proposal has been treated won't help give a better image of PEAR, and won't help us to get more proposals. I am surprised that you are not worried about the low number of proposals we actually get. Well, as a PEAR Group member, you should be worried.
Actually I think we are getting a fair number if proposals. Of course there could be more, and at the same time we would also need more people looking at the proposals as well. This needs to scale in paralellel.
And you should be worried too that Horde people have so much power here that they can stop a good proposal, without saying anything interesting about the proposed code. I understand that they are trying to promote their project, a bit like Manuel Lemos used to do with PHPClasses, but they should do it more wisely and try not to discourage other people making proposals. What if Manuel commented every proposal by saying "I think you should look at phpclasses.org, there is a class that already does just that". At least, he stopped doing it.
"Power" is the wrong term to use in this context. Chuck, Jan etc dont have any "Power", but they do seem to have a certain amount of (atleast to me wellearned) "Trust" inside the community. So that their voice is heard. If it turns out that they were wrong then that level of "Trust" will decrease in the future. This is how opensource works.
PEAR is strong enough not to rely on outside projects like Horde and, in the future, it is projects like Horde that will maybe rely on PEAR. But to achieve this, we have to be more open. I already know a lot of projects that rely on PEAR.
I think you are polarizing something here. Its not a Horde vs. PEAR war here. Its not a war for that matter anyways. It was about some people pointing out that they have well established code and asking if the proposed code matches that code in quality. Notice that I am not taking sides on this topic as I dont have the necessary inside information to tell. I didnt notice that both sides used strong language but it seemed to me that things were on track to a productive resolution. So to me its important that PEAR doesnt get the first code but the best code. If there is better code outside of PEAR then we should try to get that code. However if the "better" code doesnt follow our standards and nobody is willing to modify it accordingly we have a balancing act to make. Furthermore no code that exists is high quality based on its membership in some repository. This godes for Binarycloud just as much as Horde or PEAR for that matter.
Those were just comments from an "outsider".
Actually since this topic is definately about PEAR I would of course consider you an "insider". :-) regards, Lukas Smith smith@backendmedia.com _______________________________ BackendMedia www.backendmedia.com berlin@backendmedia.com Linn Zwoch Smith GbR Pariser Str. 44 D-10707 Berlin Tel +49 30 83 22 50 00 Fax +49 30 83 22 50 07

« previous php.pear.dev (#27914) next »