[dev] Horde 5?

[Chuck Hagenbuch]

Quoting Michael J Rubinsky <mrubinsk at horde.org>:

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

IMO this is overstating things a bit. There's no reason I can't start  
with PEAR packages, and then check out individual repos when I want to  
poke at the code.

We need tooling either way.

I wonder if the thing to do is to pick one or two packages -  
Horde_ActiveSync, Horde_Imap_Client - that are very much useful  
outside of Horde, and experiment with splitting them out?

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

Agree, though we could use git submodules to mitigate some of this.  
But I think ultimately these libraries should live only in their own  
repos, and we'd need to commit to working with them.

If it goes well, we could either split out more packages, or we could  
decide that only things that have confirmed external interest should  
be split out - maybe even rename the "framework" dir to Horde_Core",  
and treat it as all things that aren't specifically in use outside  
Horde.

-chuck