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

[Michael M Slusarz]

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.

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

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

michael

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