[dev] Horde 4 Kickoff - Git migration and layout

[Chuck Hagenbuch]

Horde developer community-

We're very close to kicking off real work on Horde 4. We have some  
ambitious plans, but I think we're also better suited to do a great  
release relatively quickly than we have been ever before.

The purpose of this thread is to discuss the new version control  
layout. We have decided to move to Git for version control, with only  
new code that is Horde 4-ready (still a somewhat fuzzy line) being  
added to it. We will keep the existing CVS repository for all Horde  
3.x releases, and for historical purposes. This avoids a complicated  
conversion and lets us make something of a fresh start from 10 years  
of repository cruft.

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.

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.

Anyone have an improvement on this structure?

-chuck