Re: Discussion of SCM_SVN Proposal

Hello all, Since there have been several responses to this thread since I last checked in, I'll try to hit my responses in one shot ... On 4/17/04 5:43 AM Pacific Time, Stefan Neufeind (stefan@neufeind.net) wrote: > I know that Horde is open towards PEAR and that the collaboration is > good. So I can't see why we shouldn't take the offer and try to make > Horde_VC (if needed a bit more pear-ified) part of PEAR. Horde could > still use the PEAR-package and ship it with their apps. And as soon > as channels become available they can even add a dep to the PEAR-code > *and* their Horde-packages. Stefan, as Chuck as already indicated earlier in this thread .. On 4/15/04 2:52 PM Pacific Time, Chuck Hagenbuch (chuck@horde.org) wrote: > I can pretty much guarantee that won't happen. I'd rather peek at your > code for ideas/examples for improving the VC svn driver than add another layer of abstraction to Chora's dependancies. I mean, I'm willing to be flexible, but > ... why? And ... On 4/15/04 9:20 PM Pacific Time, Chuck Hagenbuch (chuck@horde.org) wrote: > I'm quite happy to crib ideas and > bugfixes from other open source code. It's not really duplicate effort for > *me*, since I'd have to do the improvements/bugfixes anyway regardless of > whether other implementations exist. And relying on yet more PEAR packages > really just makes things harder for Horde's users, at least with the current > state of things. So maybe having a standalone package is the best way to go. So, it doesn't sound to me like Chuck is interested in using SCM_SVN directly. As he said, it's open source, and he can crib ideas as he chooses.. On 4/16/04 11:11 AM Pacific Time, Martin Jansen (mj@php.net) wrote: > 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. Martin, is Horde_VC a stable and proven API? When I was reviewing the source, it was under a HORDE_3_0_ALPHA tag. Has it been released and field tested and proven stable? If we were talking about rewriting an existing PEAR API, I could certainly see your point much clearer. But, as has already been pointed out, all this fuss is over a package that isn't even a PEAR package. : ) There is no version control package of any kind in PEAR. So, I don't see why the continued discussion of this is worth the bandwidth -- Chuck has indicated he's not interested, and I feel that there's so much work to be done to Horde_VC to get it where I need a version control package to go, I might as well start with a clean slate. So I did, and I'm submitting that clean slate to PEAR. Honestly, I get the feeling from a lot of the posts on this thread that there's not too much interest in my package unless it pays some respect to Horde. Maybe a disclaimer needs to be added to the PEPr interface that states that solid packages that fill a hole in the PEAR offerings *may not be welcomed* if others in a completely separate group of developers indicated an interest in doing something similar six months prior. Kind of silly, isn't it? On 4/17/04 3:39 AM Pacific Time, Klaus Guenther (klaus@capitalfocus.org) wrote: > 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. Smarty is stable code. Are the developers of the four PEAR template packages merging their efforts with Smarty? JpGraph is also stable code. As such, why are there so many PEAR Image_* packages in the works relating to graphing functionality? I'd really like to hear more about this viewpoint that seems to be shared by several on the list. Is PEAR continuing to expand its own set of package offerings? Or is PEAR-DEV turning into a developer clearinghouse for external projects? > 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. Actually, Völker expressed an interest in expanding on the architecture I proposed and have implemented with SCM_SVN. He said he'd take a look at Horde_VC, and we haven't heard back from him on the topic since his statement. On 4/16/04 11:11 AM Pacific Time, Martin Jansen (mj@php.net) wrote: > On Fri Apr 16, 2004 at 02:2651PM +0200, Klaus Guenther wrote: [snip] >> 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. "Starting to feel pissed" ...? <rant> How about members of *this* gang: - Developers who've reviewed the available "package groups" in the community, and decided on contributing code to PEAR. - Developers who diligently followed all instructions in the PEAR manual for contributing code. - Developers who wrote a fully extensible package from the ground up, and have offered to convert it to an abstraction layer like many others within PEAR. - Developers who've documented the hell out of their as-yet-unproposed-much-less-accepted package, complete with examples, API docs **AND** DocBook docs that can be dropped directly into the PEAR online manual. - Developers who have jumped on the bandwagon with the brand new PEAR_ErrorStack and implemented it in their new package. ... And after all that, are told: "Hey, go join this other group instead." I've put a lot of effort into putting a package together that should have little to no resistance for getting included in PEAR _based on what is documented_. As I said above, maybe PEPr needs to be modified with a disclaimer. Or, something needs to be added here [1]: <listitem> <simpara>Prowl for Similar Packages</simpara> <para> Do a little surfing around. Search <ulink url="&url.google;">Google</ulink>, dig around on <ulink url="&url.hotscripts;">HotScripts.com</ulink>, <ulink url="&url.phpclasses;">PHPClasses.org</ulink>, and <ulink url="&url.horde;">Horde.org</ulink>. Look in the <ulink url="mailto:&email.php.general;">&email.php.general;</ulink> archives as well. </para> <para> If you find another package not in PEAR that is similar to what you have in mind (even one that has not been formally announced or released anywhere, and <emphasis>especially</emphasis> if the other package is in <literal>HORDE_*_ALPHA</literal></emphasis>), strongly consider putting your efforts into getting <emphasis>that</emphasis> package whipped into shape enough that it meets your needs <emphasis>and</emphasis> can be used by whatever applications are already dependent upon it, then consider submitting it to PEAR. </para> </listitem> (I'll send a diff for that right over to the peardoc list...) : ) Maybe we need to fork this off onto a new thread, but I think it's worth some kind of mention that developers should at least take a look through the Horde CVS tree to see what they've got cooking before they consider proposing anything to PEAR. That's how it looks from where I'm sitting. </rant> -Clay [1] http://pear.php.net/manual/en/developers.contributing.howto.php -- Killersoft.com