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

[Jan Schneider]

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.
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. We can add one to the base folder of  
horde-git, and also to the groupware bundles, but how are we going to  
provide one when we we distribute the modules separately, whether as a  
pear package or a tarball?
Maybe we could make the horde tarball containing such a index.php and  
the horde/ directory only, at the top level. This may be hard to  
package with pear though, because with pear you can't package files  
that are a directory level *above* package.xml. I'm not sure if the  
same restrictions apply to pyrus.

Jan.

-- 
Do you need professional PHP or Horde consulting?
http://horde.org/consulting/