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

[Jan Schneider]

Zitat von Michael M Slusarz <slusarz at horde.org>:

> Quoting Jan Schneider <jan at horde.org>:
>
>> Zitat von Michael M Slusarz <slusarz at horde.org>:
>>
>>> Jumping in late here...
>>>
>>> Quoting Chuck Hagenbuch <chuck 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.
>
> 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've been playing around with this, and here's what I've come up  
> with to combine horde-git and horde-hatchery:
>
> 1. Go to horde-git:master. Make sure it is updated.
> 2. Do 'git checkout -b tmp 5d259f069ca8c31700d5431a595d2e3b5d961ea9'  
>  This creates a temporary branch and sets HEAD to right before IMP  
> was imported.
> 3. Do 'git fetch <path to horde-hatchery> master:hatchery'  <path to  
> horde-hatchery> can be the filepath to the hatchery repo on the  
> local machine.  This pulls in all of hatchery's history to horde-git.
> 4. Do 'git merge <path to horde-hatchery>'  There will be at least  
> one conflict that needs to be resolved (.gitignore).
> 5. Do 'git merge master'.  This should merge all changes done to  
> horde-git after 12/23/2009 (when IMP was added).  There will be at  
> least two conflicts that need to be resolved  
> (.gitattributes/.gitignore)
> 6. Now 'tmp' contains the full, combined history of horde-git and  
> horde-hatchery.

Great, (with a Patrick Stewart voice) make it so ;-) Though we might  
want to do this after we agreed whether we want a single repository  
for all framework and application code.

>>> 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.
>>
>> There's also the option to introduce package.xml files for  
>> applications rather now than later. It's the mid-term goal anyway  
>> to install Horde apps through PEAR/Pyrus. That would also help with  
>> upgrading, dependencies, etc.
>> If we did this, we could also resurrect horde-fw-symlink for developers.
>
> This sounds like a worthy goal.
>
>>> 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.
>>
>> Is it really that easy? Unfortunately there all still those  
>> define('HORDE_BASE') calls on the code.
>
> This should not be an issue.  If an application does not live under  
> the horde/ directory, HORDE_BASE needs to be defined in  
> config/horde.local.php.  But that's it.

Makes sense.

>> 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. And for administrators it's helpful to have a  
>> single horde directory to backup, move around and rename for  
>> testing, upgrading, staging etc.
>
> That's perfectly fine.  We can package the groupware and/or apps  
> however we want to.
>
>> OTOH separate directories for horde and the apps better map to the  
>> repository layout, simplify scripts like make-release.php and  
>> translation.php (though maybe not, since we still need to merge  
>> horde and application translations) and is more compatible with  
>> distribution packages.
>>
>> Any ideas how to solve the cons of one solution or the other? Are  
>> there more pros and cons that I am missing? Any other opinions  
>> about this? I think we should decide this pretty quick.
>
> I need to think about this a bit more.  Does PEAR/Pyrus provide any  
> help in this regard (e.g. once horde is installed, can PEAR/Pyrus  
> automatically determine/generate the necessary file path  
> configuration)?

PEAR has support for installation scripts, so you can actually do  
whatever you want. For this purpose, a simple replacement task would  
do it though.

Jan.

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