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

[Michael M Slusarz]

Quoting Ben Klang <ben at alkaloid.net>:

> On Jan 13, 2010, at 12:33 PM, Michael M Slusarz wrote: > If you mean  
> the fact that there would not be a default index.php at the base of  
> the webroot, e.g. http://www.example.com/index.php(since horde would  
> be installed in http://www.example.com/horde/), I think this is  
> completely irrelevant.  It is my strongly held belief that there is  
> no reason why we should make the git repo a "drop-in" installation  
> of horde.  If someone does wants to run using the git repo  
> (realistically, this will be a handful of people - and those people  
> will mostly be horde devs), they either have to accept that the apps  
> won't live underneath horde or they will have to manually symlink  
> the directories.  Again, not a big deal.
>
> I disagree with this statement.  While I don't necessarily feel that  
> a git clone should work 100% out-of-the-box, it should be close.  By  
> making the repository close to a workable Horde install we encourage  
> casual developers and minimize our own work on new installs.  Right  
> now there is a fairly high barrier to begin working on Horde, even  
> for someone like me who is intimately familiar with the process.  I  
> can only imagine what it would be like for someone who may want to  
> fix a bug but has only ever installed Horde from the tarballs. That  
> being said, there are naturally some concessions that we will need  
> to make to the development and packaging processes that will  
> conflict with Horde working fresh from a git checkout.  But in my  
> opinion, the closer we can align those needs, the better.

  And this repository limitation is precisely the issue (there was a  
thread on this a week or two ago) - if horde files are stored in the  
base of the repo, it becomes impossible to package horde separately  
later.  So our only reasonable options are:

1. Move 'horde/' to the base of the repo.  Write an exceedingly  
complex packaging script (that would constantly need to be maintained)  
to package horde for releases.
2. The current situation - apps live in separate directories and their  
locations should be specified in horde/config/registry.php.  Packaging  
horde vs. other applications requires no additional code.  I  
personally don't see the barrier in this approach since any admin,  
whether installing from git or tarballs, MUST edit registry.php before  
they can have a working Horde installation.  So we are not asking devs  
to do anything an end-user doesn't already have to do.

Re the bugfixing comment: I don't think we are going to be asking  
people to checkout git simply to provide bugfixing.  Creating  
patch/diff files will always remain perfectly acceptable.  Obviously,  
if someone is providing large changes it would be much preferrably if  
their patches were more integrated into the git process.  But now with  
a single unified repository, improved documentation, and possibly  
further tweaking of the install_dev script, I think installing a git  
repo is not a tremendous barrier anymore (or, at least, it's probably  
300% easier than it was just a few weeks ago).

michael

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