[dev] default backends

[Chuck Hagenbuch]

Quoting Michael M Slusarz <slusarz at horde.org>:

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

I can accept that this is philosophical, but I disagree - I would  
phrase your #2 as "Horde should not break after updating". Given the  
chance of an upgrade breaking things, or needing to review the  
configs, I'd choose having to review the configs.

I think this change is not either universally good or bad - it makes  
it easier for a casual admin (or an automatic process) to get Horde  
running and keep it updated. If people want to argue security I'd say  
that the idea that a config change will pose a security problem is a).  
abstract until proven otherwise, and b). offset by the people who  
don't update to patched versions now because of how hard it is.

This is focused on growing the base of people who can use Horde. I  
don't think it makes things appreciably worse for current admins who  
want to review the new configs before pushing them live, but I can  
certainly accept that for those people it doesn't make things better.

-chuck