Re: [PHP4BETA] php and MS SQL Server....

> The way I see it, unless you want to block the access to PEAR CVS > repository to anybody outside the core developers, you are pushing PEAR as > a repository for code that developers have to give away loosing the control > of its development to have it accepted in PEAR. That's correct. Code in PEAR is released for others to hack on. Yet another plus as far as I am concerned. This is what Open Source is all about. If people don't want to let others have access, they don't need to put their code into PEAR. We won't force anybody. > CPAN doesn't put someone else's code under CVS because they are just a > means of distribution of code, not a way to take over the development > of everybody's packages. This isn't a question of taking over the development, but rather one of opening up the development to the PHP community as a whole. > Of course, but doing so you are assuming that each contributor is willing > to give up the control of the code that he has developed, probably under his > own CVS respository eventually trashing the original CVS version tags. > > Maybe you haven't thought of this since nobody is doing it as you want, but how > the original developer is supposed to keep track of the versions of his source > files when your CVS repository will overwrite the original version tags? We have thought about this plenty, and the version tags are not much of an issue. These are kept in CVS itself. The ones you see in actual code files are optional and just informative. They have nothing to do with the cvs process itself. > Nah, I don't think putting contributions in the CVS respository is a good > idea to start with. Not sure why you are so hung up on this point. Tracking changes is never a bad thing, and code can live in 2 trees rather easily. There is also no real requirement to have all PEAR modules live in the PHP code base. You could for example make all your classes PEAR compatible and distribute them separately with a simple install script that sticks them into the right place so people can do a 'use blah'. This stuff is making your life easier, not harder. I really don't understand what you are bickering about. > I don't see a point there. You have probably subscribed (supplied your > e-mail address) to tens of mailing lists to get often more noise the sound, > and you have a problem to subscribe to one site that provides you free code > right away?!? Yup > The only good reason for you to not subscribe to a site like this, is because > you are not interested in its content at all, or you are interested in its > content but don't want the content provider to know about it. In that > case, there is little point in arguing that is annoying to people. > > In the Internet it was created a misconception that everything has to be > free and you should be able to get it without having at least to let the > provider that you are using it. What do you want next? Have a bunch of > slaves working for you for free without a minimal recognition or moral > compensation? You are getting completely silly here. Like I said in my original message. PEAR is intended to be distributed widely via many different mediums. There is no way to track everyone who gets the code anyway. Enforcing such a system means that you can't include it in any of the Linux distributions or on ftp.cdrom.com, *.php.net, etc. Bad idea. > Have you ever considered in approaching all the site maintainers and > propose to merge all into one site instead of starting your own from > scratch? Yup, I did. As far as I recall you were one of the ones not interested in this because you had your own ideas on how to do it. That's fine, we happen to have our own ideas of how it should be done as well. PX was the first. You obviously decided to start your own instead of contributing to PX as well. Why was this? > Not at all. I just feel that PEAR sounds pretty much like a "me too" > project that will duplicate most if not all that others already have > available. Not at all, it will be a place to put large and mature packages. A lot of the stuff in PX is not of the caliber that would end up in PEAR. I know because I wrote a bunch of those PX code snippits. > This is a very bad thing, because unlike CPAN that helped a lot to bring > the Perl community together, doing a separate repository for PHP code at > this very late stage will only help to tear the PHP community apart. You are the only person who has expressed any such sentiment. Everybody else has been quite positive about it. > So why don't you just sanction the database abstraction layers that exist > and work today and promote them in php.net instead of doing your own from > scratch that will most likely take a long time until it reaches a solid > state? Because they are all different. Which one would be sanctioned? Stig is taking good ideas from the various different ones. > Wouldn't it be better to help developing new drivers for at least one of > the existing database abstraction layer package instead of doing it all on > your own? > > Why not benefitting from the knowledge accumulated by those that did it > before and have it matured during many months of development? We are. > Another thing that makes me wonder about PEAR is its bindings to PHP 4. > The way I got it (correct me if I am wrong) PEAR modules will only work > under PHP 4. If that is the case, personally I think this is a bad move. > You don't need PHP 4 to have a proper code repository. Well, like you said yourself, there are plenty of code repositories catering to PHP 3. There are features in PHP 4 that make PEAR cleaner and easier to do at this point. That doesn't mean that PEAR modules couldn't necessarily be built to also work with PHP 3, but we have to start somewhere. > Another thing that makes me wonder is how the code for PEAR will be > accepted. Who may contribute? How? Personally, I don't anybody should be > discriminated and left out. Everybody should be able to contribute. It it > is not going to be that democratic, it will most likely be a dictatorship > where judgements may be influenced by personal reasons completely unrelated > to the quality and usefulness of the contributed code. Anybody may contribute. You are insinuating that there is currently discrimination going on. > These are just my opinions. Given that there is no hope that PEAR will be > built upon the knowledge and the content of existing code repository sites, > at least I am try to be constructive in the sense that I would like to see > it grow and benefit the PHP community. Given that the code in these repositories is presumably open source, any and all of it could eventually be incorporated into PEAR, so I have no idea how you can make this statement. -Rasmus