Date: prev next · Thread: first prev next last
2010 Archives by date, by thread · List index


Hi guys,

        Soo - I'm trying to understand and summarize where we are, and the
basic problems so we can make a good decision; here are some of them
that I see:

        A. Config migration is not 100% reliable, sometimes it gives you
           a broken config; if you remove your config - but the
           migration is automatic - you get no way to fix it.
                A2. Thus if we do this automatically, it can give the
                    impression that OO.o is 'just broken' / 'does not
                    work at all' - where in fact, we just somehow
                    corrupted an old settings directory.

        B. No config migration gives a problematic user experience
           whereby you loose your settings (or macros, or ...) between
           versions.

        So - here is my suggestion ;-) hopefully it annoys everybody, and it is
two-fold.

        1. we trawl for broken configuration settings in the code,
           and work to harden the code against bad configurations so
           it at least does not crash.
                + perhaps we could add an EasyHack to do some fuzzing
                  of the new XML config stuff as a start.

        2. we continue to do automatic config migration since this is
           a commonly desired use-case
        *but*
           as we migrate the settings the first time, we write into the
           (original - ie. the old version)'s directory a stamp file
           that says "these have been imported"
        *and*
           if the same version is run again with the new settings
           directory removed (ie. someting went wrong); we prompt the
           user on the second time:
                "do you want to (re-)import settings from ABC install"

        How does that sound as a compromise ? that way - hopefully we test the
migration code some more (although I agree this piece is hard to QA),
and we avoid annoying our users with dialogs on updates.

        However - if the user does a migration and discovers their LibreOffice
is really broken: they are -no worse off- than they would have been
before had they selected the 'migrate' option: ie. they need to go and
remove their settings directory. Next time they run - they will get
prompted.

        How does that sound ? or am I missing some requirements /
problems ? :-)

        Thanks,

                Michael.

-- 
 michael.meeks@novell.com  <><, Pseudo Engineer, itinerant idiot



Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.