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

Jan Schneider jan at horde.org
Wed Jan 13 23:17:59 UTC 2010


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

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

I think we all agree (and I don't recall anyone suggesting this), that  
we don't want this. It doesn't make any sense to have the horde module  
files right in the base directory of the git repository.

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

Not perfectly true, because we still need to bundle the framework with  
the horde module. But for creating tarballs I envision using the pear  
installer anyway, so that we can drop most of the make-release.php  
script.

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

No, this was never necessary. registry.php always worked  
out-of-the-box (like *any* configuration file), and it's not an option  
to change that.
If it's going to be necessary for some reason to change it for a git  
checkout, that would be acceptable. But should avoid that too.

> 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]
>
> -- 
> Horde developers mailing list - Join the hunt: http://horde.org/bounties/
> Frequently Asked Questions: http://horde.org/faq/
> To unsubscribe, mail: dev-unsubscribe at lists.horde.org
>



Jan.

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



More information about the dev mailing list