Re: proposed patch: Bug 69609 - registrymodification.xcu in presets folder not implemented in newly created profiles.

On 12/11/2014 08:26 PM, Justin Luth wrote:
> By far, the best way to manage default settings is to write a
> configuration extension.  However, that is a HUGE, daunting step for
> your average sysadmin to take.  Documentation is sparse, debugging
> ability is non-existent, and intimate knowledge of XML in general and
> LibreOffice configuration in particular is required.   The barrier to
> entry is extremely high.  (I wrote it off as too difficult initially, a
> co-worker implemented it successfully 'by luck', and even after that I
> still failed to successfully modify our extension to add another change
> and gave up after a few hours.  I finally got it right the last time I
> tried.)
>
> A popular, simpler alternative is to copy a pre-configured profile
> over-top of the existing one in the user's home directory, but that kind
> of scripting is annoying and unreliable (or using an /etc/skel or
> Default User profile for brand-new users - but that doesn't catch
> existing users).
>
> This bug fix tries to find the middle ground approach. The barrier to
> entry in this case is extremely minimal.  An administrator only needs to
> know about the existence of the .../presets folder.  Then they can
> simply copy a "known good" profile into that location.  They don't need
> to identify the specific XML entries for the settings they want to
> change, and they don't need to mess with individual's profiles or
> scripting.  (The big downside compared to a config extension is that
> changes can't be made after a profile already exists, but perhaps you
> could get away with just deleting individual's profiles, and then they
> start with a fresh one automatically.)

I'm somewhat undecided.  On the one hand, I see the demand to make 
things simple, and the proposed patch's approach does look sound 
technically.

On the other hand, we already have a well-established way to do this 
with extensions.  The presets folder and registrymodifications.xcu have 
never been advertised as modification vectors.  "Officially" introducing 
this additional way of making modifications would mean more places where 
we need to take care of backwards-compatibility going forward.

An alternative would be to make it easier for the target audience to 
achieve their goals with extensions.  That could include better 
documentation and examples.  What were the problems you encountered when 
trying it (what was your co-workers "by luck" thing, and what was the 
problem adding an additional change to the existing extension)?