Hi Stephan,
Stephan Bergmann wrote (28-11-12 10:06)
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:
thanks for the explanation (and warning for my personal use ;-) )
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.
Still, we may not expect from all people doing tests, that they will (be
able/willing to spend time to) understand/learn that.
[Jumping to an earlier mail]
Stephan Bergmann wrote (24-11-12 11:40)
Whether a given installation should try to migrate from certain existing
user profiles, should start with a fresh user profile of its own, should
reuse some existing user profile, etc., certainly varies depending on
what you want to do/test with that installation.
ok... but as we have very clear from the above, there is a difference
between LOdevs for a minor/micro and those for a major release.
Given that testing migration from existing user profiles generally
(there is the other scenario beside migration ... see further below)
requires manual activity anyway (to remove potentially existing MIGRATED
flag files from existing user profiles), I wonder whether it would not
make most sense to drop LOdev's special handling of user profiles
Special in the sense that is uses a special path?
(Sorry, I missed that)
and instead educate people on how to manually set up an installation's
user profile behavior to suit their specific needs:
* If the installation should use a private user profile of its own,
adapt the UserInstallation URL in the bootstrap ini-file to point to
some private location.
* If the installation should test migration of existing old profiles,
remove any existing MIGRATED flag files from old profiles.
And in the case of a minor/micro release, another scenario is the re-use
of the current user profile.
And isn't this what is the point in the discussion, to provide an easy
way (i.e UI) in those LOdevs to import the existing profile for testing
minor/micro releases?
I agree that at this point we have to consider the gain (more testers
can easily try LODevs with existing user data) against the costs.
up their tests scenarios, than to try and have an automated mechanism
for LOdev builds.
(Side note: I expect that most do testing without automated mechanisms.)
Cheers,
Cor
--
- Cor
- http://nl.libreoffice.org
- www.librelex.org
_______________________________________________
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: http://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/
