Re: Discussion of SCM_SVN Proposal

I really hesitated to enter this thread, but now I'll try to tone it down a bit to avoid this becoming a flame war. Zitat von Clay Loveless <clay@killersoft.com>:

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?

Horde_VC has been extracted from Chora for the sole purpose of being available as a standalone package. Not a PEAR package necessarily but all Horde packages are potential PEAR packages and we have spent a lot of time and effort to get to that point. Having its source in Chora, Horde_VC is actually on production level for 4 years. I guess that counts as being 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.

Wrong, Chuck has more than once indicated that he (and the whole Horde Project) is interested in contributing packages to PEAR. And wrong, lot's of packages are already "horde-free" in the sense of not having Horde dependancies. As obviously noone is willing to help us getting the remaining packages to that state, Chuck and I spent the last few days to at least do that with VC. Since a few minutes, this package is also free from fixed Horde dependancies. Does this change your mind?

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?

Yeah, and not true. As a common user, I'd expect the packages in PEAR (as an "official PHP project") being the best available for their purposes. We all know (and unfortunately the common user knows that already too) that this is not true, but we still should try to make this happen. I'd expect from people contributing packages that they not only look if such a package exists in PEAR already, but that they look a bit further and see if there is anywhere else free, good code available for that purpose before they start writing their own from scratch, just because they want to be the first in PEAR.

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" ...?

It really cost me some effort to answer to this rant, but it has some valid points so I'll try to answer seriously.

<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.

See above, *my* point of view is that not the first package should make it into PEAR, but the best. This might involve getting in touch with the developers having already the best or at least a good package for that purpose. If they refuse to cooperate or contribute their package to PEAR, go ahead.

- Developers who diligently followed all instructions in the PEAR manual for contributing code.

Agreed, if my POV is common sense (it might not of course), it should be stated somewhere more clearly.

- 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.

This is definately more fun than working yourself into and improving an existing package, but nothing more.

- 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.

Absolutely agreed, you did great work on documentation, something that Horde_VC is really lacking. We could use some help in that area. ;-)

<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>

This was really not necessary and is indeed suitable for pissing off people. Alright, this was my personal POV. I would really appreciate if you could think it over and try to work with us to integrate your features into Horde's VC and then contribute it back to PEAR. If you don't want to, fine, propose your package to PEAR, we won't vote against it, or submit a competing package to get your out of the race. If you are already fed up with PEAR and decide to no longer promote your package, I can understand that too. Jan. P.S.: HORDE_3_0_ALPHA simpy means that this version was bundled with the Hore 3.0-ALPHA, the first alpha version of the next major Horde version. -- http://www.horde.org - The Horde Project http://www.ammma.de - Neue Wege des Lernens http://www.tip4all.de - Deine private Tippgemeinschaft