[dev] [commits] Horde-Hatchery branch master updated. d3fcd5cdd11ada51d44c03fccd529ba9beed543d

[Michael M Slusarz]

Jumping in late here...

Quoting Chuck Hagenbuch <chuck at horde.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von Michael Rubinsky <mrubinsk at horde.org>:
>>
>>> Quoting Jan Schneider <jan at horde.org>:
>>>
>>>> Zitat von Chuck Hagenbuch <chuck at horde.org>:
>>>>
>>>>> Quoting Michael Rubinsky <mrubinsk at horde.org>:
>>>>>
>>>>>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>>>>>
>>>>>>> The branch "master" has been updated.
>>>>>>> The following is a summary of the commits.
>>>>>>>
>>>>>>> from: da4c5687690883de5668a2ce8bb7b279a815b6d1
>>>>>>>
>>>>>>> 35c0f39 Move imp to horde-git
>>>>>>
>>>>>> Should we maybe rename the apps that have moved out of hatchery  
>>>>>> instead of removing them, at least until we can use Chora to  
>>>>>> browse history of deleted files?  I get nervous when we can't  
>>>>>> browse history...
>>>>>
>>>>> What about tagging or branching the apps we want to move, adding  
>>>>> horde-hatchery as a remote to horde, and merging the branch in?  
>>>>> That should pull everything for those apps into the main repo.
>>>>>
>>>>> If we want to revisit having multiple repos, I'm also open to  
>>>>> that at this point. Git seems to scale just fine; honestly at  
>>>>> this point I would probably lean towards having one repo for  
>>>>> apps, one for the base package (whatever that ends up looking  
>>>>> like), and one for the framework - plus the supporting ones like  
>>>>> hordeweb.
>>>>
>>>> That distinction doesn't make more sense to me than the  
>>>> distinction we currently have. I'm teared because I agree that a  
>>>> single repo for all apps  would work as well as the current  
>>>> solution with two repos. But checking out a single application is  
>>>> a PITA in both cases.
>>>
>>> I think it makes sense to have a single repo for the apps and a  
>>> seperate repo for the framework. Though I'd probably vote for  
>>> putting the base package in the same repo with the apps. As far as  
>>> single apps being a PITA, I agree, but for people that really only  
>>> want the bleeding edge source for one or two apps, we have the  
>>> snapshots.
>>
>> If we go down this route, I agree that having the base horde app  
>> with the other apps makes more sense. A separate repository for all  
>> framework packages on the top level has its merits too, especially  
>> if we want to encourage using them as individual components,  
>> separately from the whole framework.
>
> This is sounding good to me.

I'm under the belief that we should have the following repo structures:

* horde-git

   **ALL** code (except for horde-hatchery)

* horde-hatchery

   hatchery apps should be limited to code that is not guaranteed to  
be released in the H4 cycle and/or does not have a maintainer.  Core  
apps, whether they are H4 ready or not, should NOT be considered  
hatchery code.

* horde-support
* horde-web

I've never been comfortable with keeping our core apps in a hatchery  
repo.  It's a hassle to import history, and I'm still not convinced  
this can be done correctly (adding horde-hatchery as a remote and  
pulling in the code isn't going to work properly, AFAICT).  At a  
minimum, if a commit spanned several applications and you later only  
import 1 of those applications, how does this commit get split?

Most important, both the horde core and framework need to live in the  
same repo.  When fixing bugs in an application, often the fix is  
actually in a framework lib, or a horde core component, or a combo of  
all three locations.  This commit message should be a single  
standalone item so we can point to a single commit message as solving  
a single bug report.

I've discussed the issue with Mike R. on IRC, but I think that due to  
technical limitations the idea of being able to check out code from  
git and directly serve it via the web is dead.  Instead, you have to  
make one of two choices:

1. If your source checkout lives in a non web-accessible location  
(probably a good idea from a security standpoint), or you want to  
serve applications below the horde base, the framework/bin/install_dev  
script is available to do this.  It has the disadvantage of requiring  
it to be rerun if the base horde structure changes at all (e.g. a  
scriptname changes), but that shouldn't happen all that often.

2. If you want to directly serve a source repo, you have to be  
resigned to the fact that applications won't live under 'horde'  
anymore.  But configuring this setup is easy enough - you just need to  
alter the locations in horde/config/registry.php.

michael

-- 
___________________________________
Michael Slusarz [slusarz at horde.org]