Re: Discussion of SCM_SVN Proposal

From: Date: Fri, 16 Apr 2004 12:26:51 +0000
Subject: Re: Discussion of SCM_SVN Proposal
References: 1 2 3  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-27772@lists.php.net to get a copy of this message
Martin Jansen <mj@php.net> wrote: > On Thu Apr 15, 2004 at 11:4146PM +0200, Bertrand Mansion wrote: > > <mj@php.net> wrote : > > > Merging your code into Horde's codebase sounds like *the* way to go for > > > me. Having two version control packages with nearly exactly the same > > > features would be a pity. > > > > I don't understand why Clay should adapt his work to Horde when Horde is not > > in PEAR ? Could you let me know the idea behind that. > > If I remember correctly someone from the Horde team (Chuck?) said that > they are willing to "contribute" all the code to PEAR that is located in > their framework/ directory in CVS. Thus merging code with existing > Horde code does definitively not mean that there is no chance to release > it in PEAR. Sounds pretty much like that complaint Alexey quoted [1] at the start of the infamous easter thread: lastcraft wrote: > To make matters worse unscrupulous owners can claim that a package actually > falls under their own remit and they were going to release something anyway, > again causing rejection. This is M$ style preannouncement. I have been > a victim of this and I saw two other instances in three months. The only > hope is usually to submit a nearby package and sneak something useful in > under the banner. I don't think this kind of preanouncement business ("Hord said they would release everything"...). Yeah right. It's not done yet. If Clay would like to merge his package in, I think that would be a Good Thing. But I think he's got some valid points as to why he wants to go it on his own. On the other hand, Horde has a lot of pretty stable code. And it would be a shame to tell them we aren't interested. And where possible, I think it is very good to offer the possibility to people who propose packages with functionality that exists in Horde. 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. When reading Chuck's letter, it looks like Horde packages will only be included in PEAR if they can simply be released in both places. In other words, if Horde code can be simply released using PEAR. Nothing against that: I fully understand the problems involved when distributing a huge framework.. So... we face a few choices: - Accept Horde code 1:1 (collaborating to pearify and develop the code) - Adopt Horde code and let it have a life of it's own on PEAR (not so good) - Accept packages written by authors who don't want to deal with a framework's complications Some people may be very comfortable working on Horde, but not all want to. And if Horde has not already contributed one of their packages, we certainly should be open to accepting a package that duplicates their functionality. 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. 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? ;-) Klaus [1] http://marc.theaimsgroup.com/?l=pear-dev&m=108151882101537&w=2 [2] http://marc.theaimsgroup.com/?l=pear-dev&m=108208923009205&w=2

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