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

[Michael Rubinsky]

Quoting Jan Schneider <jan at horde.org>:

> Zitat von Jan Schneider <jan at horde.org>:
>
>> Zitat von Chuck Hagenbuch <chuck at horde.org>:
>>
>>> Quoting Jan Schneider <jan at horde.org>:
>>>
>>>>> 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.
>>>>
>>>> That's a good point, and it's actually also a reason to not have  
>>>> a separate hatchery at all. If we only had one single repository  
>>>> for all application and framework code, we don't have any  
>>>> problems with commits spanning two repositories. And there  
>>>> shouldn't be a problem with merging hatchery to horde-git either.
>>>> Did I really say that? :) I still would prefer having one repo  
>>>> per application, but I'm giving in that this really isn't  
>>>> feasible with Git atm.
>>>
>>> I am leaning heavily towards a single repository also, based on  
>>> both our experience and also on my experience with git at work. We  
>>> can use branches much more than we currently do to keep things  
>>> that aren't ready for production out of the main view, for  
>>> refactoring, etc.
>>>
>>>> I see the main reasons for having all horde apps under the horde/  
>>>> directory being the groupware bundles and maintainability. We  
>>>> can't provide groupware tarballs that extract to multiple  
>>>> directories and files in the current directory, so we need a  
>>>> common parent directory anyway.
>>>
>>> Couldn't that common parent directory be named "groupware", and  
>>> contain both a horde/ directory along with directories for all of  
>>> the included apps?
>>
>> That should work, with the current style of packaging anyway. I'm  
>> not sure yet how to create the bundles when the applications are  
>> pear-installable but time will tell.
>
> Let's give this discussion more speed, because now that we don't  
> have hatchery anymore, if we decided to run horde side-by-side with  
> with the apps, we can drop the install_dev script again, and use a  
> horde-git checkout as the webroot, symlinking the framework packages  
> like we used to.

I think this all comes down to what we want the new structure to be,  
out of the box, for our actual releases. If we want this to be the new  
way to do things, then this would be a good way to setup our dev  
environment since this would require editing the registry file to  
reflect this. Of course, editing registry.php is something that devs  
could do locally, but why go through that if it's not really necessary  
and doesn't really buy us much? I honestly don't see the advantage of  
serving horde directly from a checkout, especially now that we have a  
nice automated script to link everything...but maybe I'm missing  
something here.


> When I thought about this, I found another problem with this  
> approach though. If the apps are not installed inside horde/, we  
> don't have a default index.php anymore.

I think this is only an issue if we want horde to be serve-able  
directly from the the webserver root by default, which I don't really  
think is what we want.

Thanks,
mike

--
The Horde Project (www.horde.org)
mrubinsk at horde.org

"Time just hates me. That's why it made me an adult." - Josh Joplin