[Libreoffice-qa] minutes of ESC call ...

[Stephan Bergmann]

On 11/27/2012 11:31 PM, Cor Nouws wrote:
> Petr Mladek wrote (27-11-12 17:54)
>> We listen :-) Well, the testing can be done even with Dev builds. I
>> installed the daily build from
>> http://dev-builds.libreoffice.org/daily/Linux-x86_64_11-Release-Configuration/master/current/
>>
>> and did the following steps:
>>
>> 1. started the official libreoffice3.6, modified some settings, and
>> stopped it
>> 2. removed ~/.config/libreoffice/3/MIGRATED
>> 3. removed ~/.config/lodev/4
>> 4. started lodev4.0
>>
>> Result: Most of the setting changes were migrated.
>
> That is clear.
> Can one of you please tell me if there is a different result when one
> does what you did and between manually copying the user profile to the
> new versions' user directory?

You mean, "rm -rf ~/.config/lodev/4 && mkdir -p ~/.config/lodev && cp -a 
~/.config/libreoffice/3 ~/.config/lodev/4"?  This can be problematic for 
various reasons:

* LO contains code to only selectively copy parts of an existing user 
profile.  One example where that is used is to drop per-user installed 
instances of the Presenter Screen and PDF Import extensions (where it 
was possible to have them installed per-user even though they were 
already bundled), as those changed from (bundled) extensions to core 
code parts in LO 4, and having them installed in both forms can lead to 
trouble.

* Those parts that LO does not migrate at all might confuse it if they 
appear nevertheless in a new profile (where LO would no longer write 
them, say).  One example is that I still plan to move the location of a 
flag file from user/extensions/bundled/buildid to 
user/extensions/buildid for LO 4.  In this case it would be harmless if 
an extra user/extensions/buildid would show up by the naive copying, but 
you get the idea.

>> IMHO, the question is if we really need to spend resources on special
>> dialog or special support. Note that we do not migrate configuration
>> between minor releases. So this testing is needed only once every few
>> years.
>
> On the other hand, also between minor release there may be differences
> that interfere with the user-profile.
> Therefore testing it with a new and with the existing user profile make
> sense, IMO.

Indeed.  One more reason why I think it is better to have QA people know 
the underlying mechanisms so they can make educated decisions how to set 
up their tests scenarios, than to try and have an automated mechanism 
for LOdev builds.

Stephan