[dev] default backends

Michael M Slusarz slusarz at horde.org
Tue Feb 15 17:40:55 UTC 2011


Quoting Jan Schneider <jan at horde.org>:

> Zitat von Vilius ?umskas <vilius at lnk.lt>:
>
>> Sveiki,
>>
>> Monday, February 14, 2011, 9:58:33 PM, you wrote:
>>
>>> Quoting Michael M Slusarz <slusarz at horde.org>:
>>
>>> - Why are we forcing changes to be in the *.local.php files anyway?
>>> This only makes sense if installing from git.  Most users will be
>>> directly editing the default files and this isn't a bad thing.  If we
>>> are concerned about changing/adding default values when upgrading, I
>>> don't believe this has really been a problem in the past.
>>
>>> Forcing changes to *.local.php instead of *.php just makes things that
>>> much more complicated.  I can't really think of another project that
>>> requires people to do this.  And it sort of defeats the whole purpose
>>> of storing the default "config" files in config/ in the first place.
>>> These new default files are instead hardcoded values and if users
>>> really aren't supposed to be touching them, they should be nowhere
>>> near the config/ directory.
>>
>> As an ex-admin I agree here with Michael completely. Usually what I do
>> when upgrading, is:
>>
>> 1. Backup whole Horde tree.
>> 2. cvs/git update it.
>> 3.  diff the new config files with backup config files for changes and
>> adjust new files accordingly.
>
> Thanks for this example that clearly shows why the old way was not  
> perfect and the new way is much better. After these changes, what  
> you to is:
> 1. Update the Horde tree.

This is not an accurate statement though - upgrading is not that  
simple.  There seems to be two assumptions you are making with this  
new config layout:

1. Horde should work by default in a new install.
2. Horde should work by default after updating.

I agree with #1.  Especially since a use case for a new user is to  
test-drive the software before deciding to use it, at which point they  
can do a more thorough install.

I totally disagree with #2.  In fact, one can argue that this is  
tremendously dangerous behavior.  It is quite possible that a default  
configuration option that is changed/added in a file is exactly  
opposite of what the admin wants, or what the admin was doing  
previously.  You are assuming that we, as Horde developers, will not  
make changes that will change previous behavior, but there is no way  
we can guarantee that.

As an admin, once I configure a system I expect my configuration to  
remain.  If a future version of the software breaks things, I accept  
that issue and will read/learn about the change and then manually  
change my configuration.  But if a future version of the software  
changes some critical setting, or even some non-critical setting,  
without me knowing about it, that is unacceptable to me (it is  
completely irrelevant if Horde's developers feel that the change is  
not significant).

michael

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




More information about the dev mailing list