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

[Jan Schneider]

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

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

I think it's Git's job to figure that out. Or do you mean that you  
tried it and it didn't work? Then this should be solved with the next  
paragraph.

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

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

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

Jan.

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