[dev] Horde 5?

[Michael J Rubinsky]

Quoting Gunnar Wrobel <wrobel at horde.org>:

> Zitat von Vilius ?umskas <vilius at lnk.lt>:
>
>> Sveiki,
>>
>> Wednesday, February 29, 2012, 5:14:21 AM, you wrote:
>>
>>> Quoting Michael J Rubinsky <mrubinsk at horde.org>:
>>
>>>>> Actually I did so myself: I did integrate several Horde 4
>>>>> components with the Zend 1 framework. This works just fine. But of
>>>>> course you loose the version control context if you do so. Which is
>>>>> a pity in the long run.
>>>>>
>>>>>> It's the latter that we are concerned about here. Sure, we can
>>>>>> benefit from attracting more developers that are willing to donate
>>>>>> time to our project, but I don't think that requiring them to
>>>>>> clone a monolithic repository is asking too much.
>>>>>
>>>>> Try to bridge Horde with Zend framework 2 and Symfony 2 in the
>>>>> context of a larger coding project. Pulling a monolihic repository
>>>>> will not be an option. Working based on PEAR will mean that no
>>>>> patches will be contributed back. Or at least it will be harder.
>>>>
>>>> I still think that external consumers should be using PEAR.
>>>> Otherwise, why are we publishing them? Why would a monolithic
>>>> repository not be an option? How would that be different from having
>>>> to use some custom-to-horde toolchain in order to manage the
>>>> multiple git repositories that would be necessary to use some of our
>>>> components? I'm not saying you are wrong, I just don't understand
>>>> the reasoning here. Either way, there would have to be some magic
>>>> involved on the external developer's side.
>>
>>> For developers, now, the easiest way to check out code is to click
>>> "clone" on github. If I'm interested in a specific library, but I have
>>> to clone a giant repo, that's a barrier. I think ultimately, if we
>>> want to bring in developers, they'll find our other repositories if
>>> our code is good.
>>
>> That's  another  good  point  why  I  think  Horde  should  NOT  split
>> repositories.  As I said before, only few Horde libraries can actually
>> live  on  their  own.
>
> It is not important if they can live totally on their own or if they  
> have dependencies. The important fact is that if you need one of the  
> libraries you have a tool that allows you to automatically have  
> these dependencies at your fingertips as well.
>
>> Developer still needs to *know* all dependencies
>> somehow  and  clone  all  of  them  on github.
>
> As mentioned before this is *not* the case. We would obviously need  
> a tool that is able to deal with the dependencies in an automated  
> fashion. We would not be alone in this - other PHP communities do  
> the same: see
> http://packagist.org/about-composer

Sure, but Chuck's point is that splitting the repository would lend  
itself to people being able to just click "clone" on github and get a  
working checkout. That is not the case. Of course, it's not really the  
case at the moment either, though with the monolithic repo, at least  
all the tools to do so are already included. Split them, and the  
developer won't be able to say "Hey, there's an Imap library, Cool -  
let me clone it." He would have to figure out that he will also need  
to either clone all of the library's dependencies, or would need to  
know which repo to clone to get the tools to help him clone the  
dependencies. Of course, this could be improved with documentation,  
but that's not the point.


>> Think Horde_Autoloader,
>> Horde_Translation, etc. Without these libraries most of the checkedout
>> code    would   not  be very useful.  Or  does github supports 3rd  
>> party scripts
>> for such cases?
>>
>> I'm   now   starting  to  think  that  maybe,  just  maybe,  those  few
>> libraries   like   ActiveSync   and  Imap_Client  could  live in both
>> main  current  Horde  repository  and  their own separate ones. In the
>> separate  repository they could even have different release timeframes
>> and different BC policy than that in Horde.

> No, no, no :) I will rather go with a monolithic repository than  
> duplicating the same code in two repos.

+1000

-- 
mike

The Horde Project (www.horde.org)
mrubinsk at horde.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6096 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.horde.org/archives/dev/attachments/20120229/fb531940/attachment.bin>