[dev] Horde 4 Kickoff - Git migration and layout

Jan Schneider jan at horde.org
Mon Oct 20 20:59:25 UTC 2008


Zitat von Chuck Hagenbuch <chuck at horde.org>:

> My proposal is that we will have two git repositories: A horde  
> repository, for the official Horde code, and a hatchery repository,  
> for new applications, misc. projects, sidelines, etc - things that  
> are currently in the incubator.

How about stuff like hordeweb, presentations etc? I'm inclined to move  
them into the incubator/hatchery too, but I'm not sure. We would need  
a different name for it then.

> This way the main repository won't be cluttered with half-baked  
> ideas, but we can easily pull from the hatchery into the main  
> repository when something is being promoted, and by having a  
> "hatching ground", we don't create a barrier to entry for the  
> repository that discourages us from accepting new projects.
>
> The layout of the hatchery would be like the current incubator - one  
> top-level directory per-project. The layout of the main horde  
> repository would be like current CVS, minus the incubator, and  
> without the requirement for a top-level horde/ directory in  
> production. It is likely that Horde 4 will be more divorced from the  
> webroot, so I don't anticipate this ending up as a problem.
>
> It could be an open question how to handle the framework packages in  
> this structure. We could have individual directories for them,  
> possibly under a separate repository, or we could keep the current  
> framework/ module. If we keep the current module, we also can decide  
> to keep the separation between packages, or to put all of them in a  
> single horde-framework/ vendor-style directory, with one lib/  
> directory, one test/ directory, etc. That is appealing for  
> simplicity, but also would make it less obvious that packages are  
> separately developed and released. My default is to keep the current  
> framework/ module.

It's definitely nice for source users to have everything in the lib/  
directory, so they can check it out and run it. But the git repo is  
for developers, we have made good experience with the framework cvs  
module, and it would feel like going back to Horde 2 if we return to  
everything in lib/. Especially with focusing more on package based  
release models, a clean, separated framework/ structure seems the  
better solution to me.

Jan.

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



More information about the dev mailing list