Re: Discussion of SCM_SVN Proposal

Last message in this thread... just have to set some things straight... no need to leave people with misunderstandings: I never meant to insult the wonderful people at Horde... Martin Jansen <mj@php.net> wrote: > > The handicap that Horde code brings with it is that it's being used in > > production and actively distributed, so it would be kinda difficult to > > completely rewrite the API. > > Why in the world would one consider rewriting an API that has proven its > stability in production environments? Netscape has shown the world that > rewriting stable systems is no good. Of course that's not a handicap! I forgot to mark the sarcasm. I'll remember to do that next time. Yesterday wasn't my day... > > In this case, though, I'm of the impression that this package has not too > > much in common with Horde_VC. And even if it did: Horde_VC is not yet in > > PEAR, and Clay may not feel up to working himself into the Horde framework. > > Again, I do not think that one has to dive into the complete framework > in order to work on just one package. I meant, however, that if you change something in this package, you have no idea how much will need to be changed in the other horde modules. So it will require careful BC compliance. Nothing negative about that, unless there is some legacy API. Which could easily be solved by using wrappers, etc. Seriously, I think it would be best for Clay to go ahead and merge his efforts with the Horde code. Because as has been pointed out, Horde is stable code. And Völker also expressed a willingness to put some effort into working with the Horde people on an interface with a lot of VC systems. Clay seems to want to provide merely a low-level interface, which could easily be included in the Horde package. If a higher level interface is needed (which apparently is the case), that can be based on his class or whatever. That would help Horde as well as PEAR. > > Maybe if we start accepting competitive packages, the people over at Horde > > will step up their efforts to have their packages included in PEAR :-) Until > > then, they already have their own package server. And it's linked to on > > pearweb, so why should they really complain? ;-) > > If I was a member of the Horde gang, I'd start to feel pissed at least > at this point. But I'm probably over-interpreting as well. EOT. The smileys were supposed to show that I'm not really serious. I believe very much that Horde code is a great addition to the PHP community. More after the following quote from Chuck: Chuck Hagenbuch <chuck@horde.org> wrote: > ... and you wonder why I haven't taken the time to put together proposals for > the 60+ packages in Horde. What on earth would I get out of it? You'd claim > that the code would get more eyes, etc., but I see no evidence of that. Fair enough, Horde has a very active group of developers. Pear developers tend to stick with their packages. Hopefully the development of a pear qa team will help change that. > All > I've tried to point out is, when there are people proposing baby new packages > that we have mature code for, that maybe it'd make more sense to take that > energy going into the new code and instead use it to clean up and extend > mature, production code that could live happily in PEAR with just a bit of > work. See, I understand and agree. No need to duplicate what's already tried and proven. Which is why I'm generally against competitive packages in Pear. If I feel like generating forms, why not use QuickForm? So what if I have to learn it! I had to learn PHP, too. (One exception: templating systems... they are a whole different story... duplication there isn't dumb...) However, when there is the no duplicate package rule, the packages in the repository need to be versatile enough to provide what everyone needs. And the maintainers need to be flexible and willing to provide missing functionality. > But that'd be NIH, and that's not the pear way - competing packages ... > and writing everything from scratch is the pear way. I don't think that's valid: I wrote a class (XHTML_Page) and was considering proposing it to pear, when someone pointed out that there used to be an HTML_Page class. I looked it over, and realized that it had some API advantages over my code and that I could at least reuse the API. So I wrote to the author and merged my code in. Yes, it took a few full days of work. But it was well worth it. Now I can support a bunch of people who used the old code: I already had a bunch of people who were using my class and were interested in my updates. And I've received a number of suggestions and contributions since then. As soon as I have more time, I'll be very happy to take a look at what Horde has in their repository and consider helping port it to PEAR. However, I still stick to my view that just because there is code existing in Horde is not sufficient reason to reject a package proposal. Of course, if API problems can be pointed out, Horde certainly has the benefit of a long history of use in production. Most proposed packages don't have that. And if they can collaborate with Horde, that would be preferable. Hopefully this email mollifies any and all hard feelings that resulted from my previous one. Klaus