You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Oliver-Rainer Wittmann <or...@googlemail.com> on 2013/05/28 17:10:16 UTC
[AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help
needed
Hi,
I would like to activate/introduce code which migrates certain user
profile data from AOO 3.4.x and OOo 3.x installations during the
reactivated FirstStartWizard when the user starts the first time an
installed AOO 4.0.
I have submitted two issues for this task:
- 122398 for the reactivation of the FirstStartWizard [1]
- 122397 for the code and configuration changes to migrate an AOO
3.4.x/OOo 3.x user profile [2]
In the last days I had a look at the user profile migration code and its
configuration. I figured out how it works in general.
Further investigation is needed to figure out, if and how the existing
service to 'migrate' installed extensions works. I am currently not
sure, if the automatic user profile migration should try to install
extensions from a former version. My current preference is not to
migrate extension from a former version.
I need support and help with the migration of the user profile:
(A) To figure out and test the user profile migration 'real-life' user
profiles or 'early-alpha-testers' would be welcome.
Thus, send my your AOO 3.4.x or OOo 3.x user profile in a compressed
form (.zip file or .tar.gz file or ...) or let me know, if you want to
try my builds.
(B) The first page of the FirstStartWizard is a general welcome
containing the following en-US strings.
String "This wizard will guide you through the license agreement, the
transfer of user data from %OLD_VERSION and the registration of
%PRODUCTNAME.", if a user profile for a migration is found, and string
"This wizard will guide you through the registration of %PRODUCTNAME."
otherwise.
Since at least OOo 3.2 no license agreement was shown --> no text for a
license agreement is needed on the welcome page.
Since AOO 3.4 we do not have a registration --> no text for a
registration has to be shown.
Thus, I am asking for new string proposals for the welcome page of the
FirstStartWizard.
I have attached screenshots of the currently deactivated FirstStartWizard.
[1] https://issues.apache.org/ooo/show_bug.cgi?id=122398
[2] https://issues.apache.org/ooo/show_bug.cgi?id=122397
Thanks in advance,
Oliver.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Guy Waterval <wa...@gmail.com>.
Hi Oliver,
Hi all,
2013/5/28 Oliver-Rainer Wittmann <or...@googlemail.com>
[...]
I am currently not sure, if the automatic user profile migration should try
> to install extensions from a former version. My current preference is not
> to migrate extension from a former version.
>
I think it's better so.
A+
--
gw
>
>
>
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 18.06.2013 17:20, Oliver-Rainer Wittmann wrote:
> Hi,
>
> On 18.06.2013 10:58, Oliver-Rainer Wittmann wrote:
>> Hi
>>
>> On 28.05.2013 17:10, Oliver-Rainer Wittmann wrote:
>>> Hi,
>>>
>>> I would like to activate/introduce code which migrates certain user
>>> profile data from AOO 3.4.x and OOo 3.x installations during the
>>> reactivated FirstStartWizard when the user starts the first time an
>>> installed AOO 4.0.
>>> I have submitted two issues for this task:
>>> - 122398 for the reactivation of the FirstStartWizard [1]
>>> - 122397 for the code and configuration changes to migrate an AOO
>>> 3.4.x/OOo 3.x user profile [2]
>>>
>>
>> I have solved both tasks inclusive the migration of user-installed
>> extensions.
>>
>
> Unfortunately, my change causes build breaker on Mac OS and Linux.
>
> Root cause:
> My try to export a certain function from library deploymentgui.uno
> (module desktop) in order to use it in other libraries of module desktop
> failed under Mac OS and Linux.
>
> I am working on it.
>
I asked Andre for help and he solved the problem - many kudos for Andre.
Best regards, Oliver.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 18.06.2013 10:58, Oliver-Rainer Wittmann wrote:
> Hi
>
> On 28.05.2013 17:10, Oliver-Rainer Wittmann wrote:
>> Hi,
>>
>> I would like to activate/introduce code which migrates certain user
>> profile data from AOO 3.4.x and OOo 3.x installations during the
>> reactivated FirstStartWizard when the user starts the first time an
>> installed AOO 4.0.
>> I have submitted two issues for this task:
>> - 122398 for the reactivation of the FirstStartWizard [1]
>> - 122397 for the code and configuration changes to migrate an AOO
>> 3.4.x/OOo 3.x user profile [2]
>>
>
> I have solved both tasks inclusive the migration of user-installed
> extensions.
>
Unfortunately, my change causes build breaker on Mac OS and Linux.
Root cause:
My try to export a certain function from library deploymentgui.uno
(module desktop) in order to use it in other libraries of module desktop
failed under Mac OS and Linux.
I am working on it.
Best regards, Oliver.
> As the translation deadline has passed I have made no string changes.
>
> Please provide feedback from your tests once a snapshot build or a
> buildbot build including these changes is available.
>
> Best regards, Oliver.
>
>> In the last days I had a look at the user profile migration code and its
>> configuration. I figured out how it works in general.
>>
>> Further investigation is needed to figure out, if and how the existing
>> service to 'migrate' installed extensions works. I am currently not
>> sure, if the automatic user profile migration should try to install
>> extensions from a former version. My current preference is not to
>> migrate extension from a former version.
>>
>>
>> I need support and help with the migration of the user profile:
>>
>> (A) To figure out and test the user profile migration 'real-life' user
>> profiles or 'early-alpha-testers' would be welcome.
>> Thus, send my your AOO 3.4.x or OOo 3.x user profile in a compressed
>> form (.zip file or .tar.gz file or ...) or let me know, if you want to
>> try my builds.
>>
>> (B) The first page of the FirstStartWizard is a general welcome
>> containing the following en-US strings.
>> String "This wizard will guide you through the license agreement, the
>> transfer of user data from %OLD_VERSION and the registration of
>> %PRODUCTNAME.", if a user profile for a migration is found, and string
>> "This wizard will guide you through the registration of %PRODUCTNAME."
>> otherwise.
>> Since at least OOo 3.2 no license agreement was shown --> no text for a
>> license agreement is needed on the welcome page.
>> Since AOO 3.4 we do not have a registration --> no text for a
>> registration has to be shown.
>> Thus, I am asking for new string proposals for the welcome page of the
>> FirstStartWizard.
>> I have attached screenshots of the currently deactivated
>> FirstStartWizard.
>>
>> [1] https://issues.apache.org/ooo/show_bug.cgi?id=122398
>> [2] https://issues.apache.org/ooo/show_bug.cgi?id=122397
>>
>>
>> Thanks in advance,
>> Oliver.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi
On 28.05.2013 17:10, Oliver-Rainer Wittmann wrote:
> Hi,
>
> I would like to activate/introduce code which migrates certain user
> profile data from AOO 3.4.x and OOo 3.x installations during the
> reactivated FirstStartWizard when the user starts the first time an
> installed AOO 4.0.
> I have submitted two issues for this task:
> - 122398 for the reactivation of the FirstStartWizard [1]
> - 122397 for the code and configuration changes to migrate an AOO
> 3.4.x/OOo 3.x user profile [2]
>
I have solved both tasks inclusive the migration of user-installed
extensions.
As the translation deadline has passed I have made no string changes.
Please provide feedback from your tests once a snapshot build or a
buildbot build including these changes is available.
Best regards, Oliver.
> In the last days I had a look at the user profile migration code and its
> configuration. I figured out how it works in general.
>
> Further investigation is needed to figure out, if and how the existing
> service to 'migrate' installed extensions works. I am currently not
> sure, if the automatic user profile migration should try to install
> extensions from a former version. My current preference is not to
> migrate extension from a former version.
>
>
> I need support and help with the migration of the user profile:
>
> (A) To figure out and test the user profile migration 'real-life' user
> profiles or 'early-alpha-testers' would be welcome.
> Thus, send my your AOO 3.4.x or OOo 3.x user profile in a compressed
> form (.zip file or .tar.gz file or ...) or let me know, if you want to
> try my builds.
>
> (B) The first page of the FirstStartWizard is a general welcome
> containing the following en-US strings.
> String "This wizard will guide you through the license agreement, the
> transfer of user data from %OLD_VERSION and the registration of
> %PRODUCTNAME.", if a user profile for a migration is found, and string
> "This wizard will guide you through the registration of %PRODUCTNAME."
> otherwise.
> Since at least OOo 3.2 no license agreement was shown --> no text for a
> license agreement is needed on the welcome page.
> Since AOO 3.4 we do not have a registration --> no text for a
> registration has to be shown.
> Thus, I am asking for new string proposals for the welcome page of the
> FirstStartWizard.
> I have attached screenshots of the currently deactivated FirstStartWizard.
>
> [1] https://issues.apache.org/ooo/show_bug.cgi?id=122398
> [2] https://issues.apache.org/ooo/show_bug.cgi?id=122397
>
>
> Thanks in advance,
> Oliver.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 6/5/13 3:32 PM, Andreas Säger wrote:
> Am 05.06.2013 14:50, Jürgen Schmidt wrote:
>> On 6/5/13 2:00 PM, Andreas Säger wrote:
>>> If the developers obviously have no clue how to get things right, if
>>> even the project lead seems to be completely clueless about the way his
>>> product works ...
>>
>> The developers try to improve the program over time and fix design
>> issues in a major version.
>>
>> Which leader, Apache projects have no single leader. I am at least no
>> leader of this project, I am just one developer who try bring things
>> forward.
>>
>
> If your clunky mail system would work, you could see which one I mean.
and my comment apply to Rob as well, we have no leader here only active
community members. And he asked of course valid questions that are not
yet solved or answered because of many other things that needed to be
addressed as well.
Juergen
>
>>
>>>
>>>> http://www.mail-archive.com/dev@openoffice.apache.org/msg07883.html
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: api-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
For additional commands, e-mail: api-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Andreas Säger <vi...@t-online.de>.
Am 05.06.2013 14:50, Jürgen Schmidt wrote:
> On 6/5/13 2:00 PM, Andreas Säger wrote:
>> If the developers obviously have no clue how to get things right, if
>> even the project lead seems to be completely clueless about the way his
>> product works ...
>
> The developers try to improve the program over time and fix design
> issues in a major version.
>
> Which leader, Apache projects have no single leader. I am at least no
> leader of this project, I am just one developer who try bring things
> forward.
>
If your clunky mail system would work, you could see which one I mean.
>
>>
>>> http://www.mail-archive.com/dev@openoffice.apache.org/msg07883.html
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
For additional commands, e-mail: api-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 6/5/13 2:00 PM, Andreas Säger wrote:
> If the developers obviously have no clue how to get things right, if
> even the project lead seems to be completely clueless about the way his
> product works ...
The developers try to improve the program over time and fix design
issues in a major version.
Which leader, Apache projects have no single leader. I am at least no
leader of this project, I am just one developer who try bring things
forward.
Juergen
>
>> http://www.mail-archive.com/dev@openoffice.apache.org/msg07883.html
>
> ... how could I contribute anything useful?
>
> I do not even understand my own extension anymore that I wrote 6 years
> ago. I do understand my own code but not the complicated XML
> configuration. The only thing I know for sure is that most of this
> extension used to run with any version from 1.4.x until 3.x.
>
> How could I test anything if I do not have any access to version 4? Am I
> supposed to compile it from source code or what?
>
> Sorry guys. I can happily do my work version 3.4.1 for the rest of my
> life. ODF seems to be a dead horse anyway so I'm not afraid of file
> format changes in the future.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: api-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
For additional commands, e-mail: api-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi Andreas,
On 05.06.2013 14:00, Andreas Säger wrote:
> If the developers obviously have no clue how to get things right, if
> even the project lead seems to be completely clueless about the way his
> product works ...
>
>> http://www.mail-archive.com/dev@openoffice.apache.org/msg07883.html
>
> ... how could I contribute anything useful?
- By giving constructive feedback
- By asking questions
- By helping with translation
- By helping with testing
- By helping with documentation
- By helping with marketing and promotion
- By setting up a test environment, installing old version OOo 3.x or
AOO 3.4.x, upgrading to AOO 4.0 and reporting success or failure
- By taking responsibility for certain management tasks
- ...
>
> I do not even understand my own extension anymore that I wrote 6 years
> ago. I do understand my own code but not the complicated XML
> configuration. The only thing I know for sure is that most of this
> extension used to run with any version from 1.4.x until 3.x.
>
> How could I test anything if I do not have any access to version 4? Am I
> supposed to compile it from source code or what?
By taking the stuff the community is providing - build bot results and
developer snapshots. These are installation sets that anybody of the
community can install easily.
Building it from source is also a good option.
Best regards, Oliver.
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
For additional commands, e-mail: api-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Andreas Säger <vi...@t-online.de>.
Am 10.06.2013 21:24, Andreas Säger wrote:
> Am 05.06.2013 14:31, Regina Henschel wrote:
>> Find a previous snapshot at
>> http://ci.apache.org/projects/openoffice/install/ under winsnap or linsnap.
>>
>> Kind regards
>> Regina
>>
>
> Apache_OpenOffice_4.0.0_Linux_x86-64_install-deb_en-US.tar.gz fails to
> install while destroying my existing AOO 3.4.1
> Same problem with
> Apache_OpenOffice_4.0.0_Linux_x86-64_install-deb_en-US.tar.gz_2013-06-10_04:12:05_1491332.tar.gz
>
Solution:
http://forum.openoffice.org/en/forum/viewtopic.php?f=74&t=50119
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
For additional commands, e-mail: api-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Andreas Säger <vi...@t-online.de>.
Am 05.06.2013 14:31, Regina Henschel wrote:
> Find a previous snapshot at
> http://ci.apache.org/projects/openoffice/install/ under winsnap or linsnap.
>
> Kind regards
> Regina
>
Apache_OpenOffice_4.0.0_Linux_x86-64_install-deb_en-US.tar.gz fails to
install while destroying my existing AOO 3.4.1
Same problem with
Apache_OpenOffice_4.0.0_Linux_x86-64_install-deb_en-US.tar.gz_2013-06-10_04:12:05_1491332.tar.gz
> sudo dpkg -i *.deb
> [sudo] password for andreas:
> Vormals nicht ausgewähltes Paket openoffice wird gewählt.
> dpkg: Entfernen von openoffice.org3 zugunsten von openoffice wird in Betracht gezogen ...
> dpkg: Nein, fortfahren mit Entfernen von openoffice.org3 nicht möglich (--auto-deconfigure wird helfen):
> openoffice.org3-impress hängt von openoffice.org3 ab
> openoffice.org3 soll entfernt werden.
> dpkg: Betreffend openoffice_4.0.0-2_amd64.deb, welches openoffice enthält:
> openoffice kollidiert mit openoffice.org3
> openoffice.org3 (Version 3.4.1-1) ist vorhanden und installiert.
> dpkg: Fehler beim Bearbeiten von openoffice_4.0.0-2_amd64.deb (--install):
> Kollidierende Pakete - openoffice wird nicht installiert
> Vormals nicht ausgewähltes Paket openoffice-base wird gewählt.
> dpkg: Entfernen von ooobasis3.4-base zugunsten von openoffice-base wird in Betracht gezogen ...
> dpkg: Nein, fortfahren mit Entfernen von ooobasis3.4-base nicht möglich (--auto-deconfigure wird helfen):
> openoffice.org3-base hängt von ooobasis3.4-base ab
> ooobasis3.4-base soll entfernt werden.
> dpkg: Betreffend openoffice-base_4.0.0-2_amd64.deb, welches openoffice-base enthält:
> openoffice-base kollidiert mit ooobasis3.4-base
> ooobasis3.4-base (Version 3.4.1-1) ist vorhanden und installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-base_4.0.0-2_amd64.deb (--install):
> Kollidierende Pakete - openoffice-base wird nicht installiert
> Vormals nicht ausgewähltes Paket openoffice-brand-base wird gewählt.
> dpkg: Entfernen von openoffice.org3-base zugunsten von openoffice-brand-base wird in Betracht gezogen ...
> dpkg: Ja, openoffice.org3-base wird zugunsten von openoffice-brand-base entfernt.
> (Lese Datenbank ... 323621 Dateien und Verzeichnisse sind derzeit installiert.)
> Entpacken von openoffice-brand-base (aus openoffice-brand-base_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-brand-calc wird gewählt.
> dpkg: Entfernen von openoffice.org3-calc zugunsten von openoffice-brand-calc wird in Betracht gezogen ...
> dpkg: Ja, openoffice.org3-calc wird zugunsten von openoffice-brand-calc entfernt.
> Entpacken von openoffice-brand-calc (aus openoffice-brand-calc_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-brand-draw wird gewählt.
> dpkg: Entfernen von openoffice.org3-draw zugunsten von openoffice-brand-draw wird in Betracht gezogen ...
> dpkg: Ja, openoffice.org3-draw wird zugunsten von openoffice-brand-draw entfernt.
> Entpacken von openoffice-brand-draw (aus openoffice-brand-draw_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-brand-en-us wird gewählt.
> Entpacken von openoffice-brand-en-us (aus openoffice-brand-en-us_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-brand-impress wird gewählt.
> dpkg: Entfernen von openoffice.org3-impress zugunsten von openoffice-brand-impress wird in Betracht gezogen ...
> dpkg: Ja, openoffice.org3-impress wird zugunsten von openoffice-brand-impress entfernt.
> Entpacken von openoffice-brand-impress (aus openoffice-brand-impress_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-brand-math wird gewählt.
> dpkg: Entfernen von openoffice.org3-math zugunsten von openoffice-brand-math wird in Betracht gezogen ...
> dpkg: Ja, openoffice.org3-math wird zugunsten von openoffice-brand-math entfernt.
> Entpacken von openoffice-brand-math (aus openoffice-brand-math_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-brand-writer wird gewählt.
> dpkg: Entfernen von openoffice.org3-writer zugunsten von openoffice-brand-writer wird in Betracht gezogen ...
> dpkg: Ja, openoffice.org3-writer wird zugunsten von openoffice-brand-writer entfernt.
> Entpacken von openoffice-brand-writer (aus openoffice-brand-writer_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-calc wird gewählt.
> dpkg: Entfernen von ooobasis3.4-calc zugunsten von openoffice-calc wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-calc wird zugunsten von openoffice-calc entfernt.
> Entpacken von openoffice-calc (aus openoffice-calc_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-core01 wird gewählt.
> dpkg: Entfernen von ooobasis3.4-core01 zugunsten von openoffice-core01 wird in Betracht gezogen ...
> dpkg: Nein, fortfahren mit Entfernen von ooobasis3.4-core01 nicht möglich (--auto-deconfigure wird helfen):
> ooobasis3.4-gnome-integration hängt von ooobasis3.4-core01 ab
> ooobasis3.4-core01 soll entfernt werden.
> dpkg: Betreffend openoffice-core01_4.0.0-2_amd64.deb, welches openoffice-core01 enthält:
> openoffice-core01 kollidiert mit ooobasis3.4-core01
> ooobasis3.4-core01 (Version 3.4.1-1) ist vorhanden und installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-core01_4.0.0-2_amd64.deb (--install):
> Kollidierende Pakete - openoffice-core01 wird nicht installiert
> Vormals nicht ausgewähltes Paket openoffice-core02 wird gewählt.
> dpkg: Entfernen von ooobasis3.4-core02 zugunsten von openoffice-core02 wird in Betracht gezogen ...
> dpkg: Nein, fortfahren mit Entfernen von ooobasis3.4-core02 nicht möglich (--auto-deconfigure wird helfen):
> openoffice.org3 hängt von ooobasis3.4-core02 ab
> ooobasis3.4-core02 soll entfernt werden.
> dpkg: Betreffend openoffice-core02_4.0.0-2_amd64.deb, welches openoffice-core02 enthält:
> openoffice-core02 kollidiert mit ooobasis3.4-core02
> ooobasis3.4-core02 (Version 3.4.1-1) ist vorhanden und installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-core02_4.0.0-2_amd64.deb (--install):
> Kollidierende Pakete - openoffice-core02 wird nicht installiert
> Vormals nicht ausgewähltes Paket openoffice-core03 wird gewählt.
> dpkg: Entfernen von ooobasis3.4-core03 zugunsten von openoffice-core03 wird in Betracht gezogen ...
> dpkg: Nein, fortfahren mit Entfernen von ooobasis3.4-core03 nicht möglich (--auto-deconfigure wird helfen):
> openoffice.org3 hängt von ooobasis3.4-core03 ab
> ooobasis3.4-core03 soll entfernt werden.
> dpkg: Betreffend openoffice-core03_4.0.0-2_amd64.deb, welches openoffice-core03 enthält:
> openoffice-core03 kollidiert mit ooobasis3.4-core03
> ooobasis3.4-core03 (Version 3.4.1-1) ist vorhanden und installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-core03_4.0.0-2_amd64.deb (--install):
> Kollidierende Pakete - openoffice-core03 wird nicht installiert
> Vormals nicht ausgewähltes Paket openoffice-core04 wird gewählt.
> dpkg: Entfernen von ooobasis3.4-core04 zugunsten von openoffice-core04 wird in Betracht gezogen ...
> dpkg: Nein, fortfahren mit Entfernen von ooobasis3.4-core04 nicht möglich (--auto-deconfigure wird helfen):
> openoffice.org3 hängt von ooobasis3.4-core04 ab
> ooobasis3.4-core04 soll entfernt werden.
> dpkg: Betreffend openoffice-core04_4.0.0-2_amd64.deb, welches openoffice-core04 enthält:
> openoffice-core04 kollidiert mit ooobasis3.4-core04
> ooobasis3.4-core04 (Version 3.4.1-1) ist vorhanden und installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-core04_4.0.0-2_amd64.deb (--install):
> Kollidierende Pakete - openoffice-core04 wird nicht installiert
> Vormals nicht ausgewähltes Paket openoffice-core05 wird gewählt.
> dpkg: Entfernen von ooobasis3.4-core05 zugunsten von openoffice-core05 wird in Betracht gezogen ...
> dpkg: Nein, fortfahren mit Entfernen von ooobasis3.4-core05 nicht möglich (--auto-deconfigure wird helfen):
> openoffice.org3 hängt von ooobasis3.4-core05 ab
> ooobasis3.4-core05 soll entfernt werden.
> dpkg: Betreffend openoffice-core05_4.0.0-2_amd64.deb, welches openoffice-core05 enthält:
> openoffice-core05 kollidiert mit ooobasis3.4-core05
> ooobasis3.4-core05 (Version 3.4.1-1) ist vorhanden und installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-core05_4.0.0-2_amd64.deb (--install):
> Kollidierende Pakete - openoffice-core05 wird nicht installiert
> Vormals nicht ausgewähltes Paket openoffice-core06 wird gewählt.
> dpkg: Entfernen von ooobasis3.4-core06 zugunsten von openoffice-core06 wird in Betracht gezogen ...
> dpkg: Nein, fortfahren mit Entfernen von ooobasis3.4-core06 nicht möglich (--auto-deconfigure wird helfen):
> openoffice.org3 hängt von ooobasis3.4-core06 ab
> ooobasis3.4-core06 soll entfernt werden.
> dpkg: Betreffend openoffice-core06_4.0.0-2_amd64.deb, welches openoffice-core06 enthält:
> openoffice-core06 kollidiert mit ooobasis3.4-core06
> ooobasis3.4-core06 (Version 3.4.1-1) ist vorhanden und installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-core06_4.0.0-2_amd64.deb (--install):
> Kollidierende Pakete - openoffice-core06 wird nicht installiert
> Vormals nicht ausgewähltes Paket openoffice-core07 wird gewählt.
> dpkg: Entfernen von ooobasis3.4-core07 zugunsten von openoffice-core07 wird in Betracht gezogen ...
> dpkg: Nein, fortfahren mit Entfernen von ooobasis3.4-core07 nicht möglich (--auto-deconfigure wird helfen):
> openoffice.org3 hängt von ooobasis3.4-core07 ab
> ooobasis3.4-core07 soll entfernt werden.
> dpkg: Betreffend openoffice-core07_4.0.0-2_amd64.deb, welches openoffice-core07 enthält:
> openoffice-core07 kollidiert mit ooobasis3.4-core07
> ooobasis3.4-core07 (Version 3.4.1-1) ist vorhanden und installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-core07_4.0.0-2_amd64.deb (--install):
> Kollidierende Pakete - openoffice-core07 wird nicht installiert
> Vormals nicht ausgewähltes Paket openoffice-draw wird gewählt.
> dpkg: Entfernen von ooobasis3.4-draw zugunsten von openoffice-draw wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-draw wird zugunsten von openoffice-draw entfernt.
> Entpacken von openoffice-draw (aus openoffice-draw_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-en-us wird gewählt.
> Entpacken von openoffice-en-us (aus openoffice-en-us_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-en-us-base wird gewählt.
> Entpacken von openoffice-en-us-base (aus openoffice-en-us-base_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-en-us-calc wird gewählt.
> Entpacken von openoffice-en-us-calc (aus openoffice-en-us-calc_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-en-us-draw wird gewählt.
> Entpacken von openoffice-en-us-draw (aus openoffice-en-us-draw_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-en-us-help wird gewählt.
> Entpacken von openoffice-en-us-help (aus openoffice-en-us-help_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-en-us-impress wird gewählt.
> Entpacken von openoffice-en-us-impress (aus openoffice-en-us-impress_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-en-us-math wird gewählt.
> Entpacken von openoffice-en-us-math (aus openoffice-en-us-math_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-en-us-res wird gewählt.
> Entpacken von openoffice-en-us-res (aus openoffice-en-us-res_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-en-us-writer wird gewählt.
> Entpacken von openoffice-en-us-writer (aus openoffice-en-us-writer_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-gnome-integration wird gewählt.
> dpkg: Entfernen von ooobasis3.4-gnome-integration zugunsten von openoffice-gnome-integration wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-gnome-integration wird zugunsten von openoffice-gnome-integration entfernt.
> Entpacken von openoffice-gnome-integration (aus openoffice-gnome-integration_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-graphicfilter wird gewählt.
> dpkg: Entfernen von ooobasis3.4-graphicfilter zugunsten von openoffice-graphicfilter wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-graphicfilter wird zugunsten von openoffice-graphicfilter entfernt.
> Entpacken von openoffice-graphicfilter (aus openoffice-graphicfilter_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-images wird gewählt.
> dpkg: Entfernen von ooobasis3.4-images zugunsten von openoffice-images wird in Betracht gezogen ...
> dpkg: Nein, fortfahren mit Entfernen von ooobasis3.4-images nicht möglich (--auto-deconfigure wird helfen):
> openoffice.org3 hängt von ooobasis3.4-images ab
> ooobasis3.4-images soll entfernt werden.
> dpkg: Betreffend openoffice-images_4.0.0-2_amd64.deb, welches openoffice-images enthält:
> openoffice-images kollidiert mit ooobasis3.4-images
> ooobasis3.4-images (Version 3.4.1-1) ist vorhanden und installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-images_4.0.0-2_amd64.deb (--install):
> Kollidierende Pakete - openoffice-images wird nicht installiert
> Vormals nicht ausgewähltes Paket openoffice-impress wird gewählt.
> dpkg: Entfernen von ooobasis3.4-impress zugunsten von openoffice-impress wird in Betracht gezogen ...
> dpkg: Nein, fortfahren mit Entfernen von ooobasis3.4-impress nicht möglich (--auto-deconfigure wird helfen):
> ooobasis3.4-ogltrans hängt von ooobasis3.4-impress ab
> ooobasis3.4-impress soll entfernt werden.
> dpkg: Betreffend openoffice-impress_4.0.0-2_amd64.deb, welches openoffice-impress enthält:
> openoffice-impress kollidiert mit ooobasis3.4-impress
> ooobasis3.4-impress (Version 3.4.1-1) ist vorhanden und installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-impress_4.0.0-2_amd64.deb (--install):
> Kollidierende Pakete - openoffice-impress wird nicht installiert
> Vormals nicht ausgewähltes Paket openoffice-javafilter wird gewählt.
> dpkg: Entfernen von ooobasis3.4-javafilter zugunsten von openoffice-javafilter wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-javafilter wird zugunsten von openoffice-javafilter entfernt.
> Entpacken von openoffice-javafilter (aus openoffice-javafilter_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-math wird gewählt.
> dpkg: Entfernen von ooobasis3.4-math zugunsten von openoffice-math wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-math wird zugunsten von openoffice-math entfernt.
> Entpacken von openoffice-math (aus openoffice-math_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-ogltrans wird gewählt.
> dpkg: Entfernen von ooobasis3.4-ogltrans zugunsten von openoffice-ogltrans wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-ogltrans wird zugunsten von openoffice-ogltrans entfernt.
> Entpacken von openoffice-ogltrans (aus openoffice-ogltrans_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-onlineupdate wird gewählt.
> dpkg: Entfernen von ooobasis3.4-onlineupdate zugunsten von openoffice-onlineupdate wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-onlineupdate wird zugunsten von openoffice-onlineupdate entfernt.
> Entpacken von openoffice-onlineupdate (aus openoffice-onlineupdate_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-ooofonts wird gewählt.
> dpkg: Entfernen von ooobasis3.4-ooofonts zugunsten von openoffice-ooofonts wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-ooofonts wird zugunsten von openoffice-ooofonts entfernt.
> Entpacken von openoffice-ooofonts (aus openoffice-ooofonts_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-ooolinguistic wird gewählt.
> dpkg: Entfernen von ooobasis3.4-ooolinguistic zugunsten von openoffice-ooolinguistic wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-ooolinguistic wird zugunsten von openoffice-ooolinguistic entfernt.
> Entpacken von openoffice-ooolinguistic (aus openoffice-ooolinguistic_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-pyuno wird gewählt.
> dpkg: Entfernen von ooobasis3.4-pyuno zugunsten von openoffice-pyuno wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-pyuno wird zugunsten von openoffice-pyuno entfernt.
> Entpacken von openoffice-pyuno (aus openoffice-pyuno_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-ure wird gewählt.
> dpkg: Entfernen von openoffice.org-ure zugunsten von openoffice-ure wird in Betracht gezogen ...
> dpkg: Nein, fortfahren mit Entfernen von openoffice.org-ure nicht möglich (--auto-deconfigure wird helfen):
> ooobasis3.4-core01 hängt von openoffice.org-ure ab
> openoffice.org-ure soll entfernt werden.
> dpkg: Betreffend openoffice-ure_4.0.0-2_amd64.deb, welches openoffice-ure enthält:
> openoffice-ure kollidiert mit openoffice.org-ure
> openoffice.org-ure (Version 3.4.1-1) ist vorhanden und installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-ure_4.0.0-2_amd64.deb (--install):
> Kollidierende Pakete - openoffice-ure wird nicht installiert
> Vormals nicht ausgewähltes Paket openoffice-writer wird gewählt.
> dpkg: Entfernen von ooobasis3.4-writer zugunsten von openoffice-writer wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-writer wird zugunsten von openoffice-writer entfernt.
> Entpacken von openoffice-writer (aus openoffice-writer_4.0.0-2_amd64.deb) ...
> Vormals nicht ausgewähltes Paket openoffice-xsltfilter wird gewählt.
> dpkg: Entfernen von ooobasis3.4-xsltfilter zugunsten von openoffice-xsltfilter wird in Betracht gezogen ...
> dpkg: Ja, ooobasis3.4-xsltfilter wird zugunsten von openoffice-xsltfilter entfernt.
> Entpacken von openoffice-xsltfilter (aus openoffice-xsltfilter_4.0.0-2_amd64.deb) ...
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-brand-base:
> openoffice-brand-base hängt ab von openoffice; aber:
> Paket openoffice ist nicht installiert.
> openoffice-brand-base hängt ab von openoffice-base; aber:
> Paket openoffice-base ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-brand-base (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-brand-calc:
> openoffice-brand-calc hängt ab von openoffice; aber:
> Paket openoffice ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-brand-calc (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-brand-draw:
> openoffice-brand-draw hängt ab von openoffice; aber:
> Paket openoffice ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-brand-draw (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-brand-en-us:
> openoffice-brand-en-us hängt ab von openoffice; aber:
> Paket openoffice ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-brand-en-us (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-brand-impress:
> openoffice-brand-impress hängt ab von openoffice; aber:
> Paket openoffice ist nicht installiert.
> openoffice-brand-impress hängt ab von openoffice-impress; aber:
> Paket openoffice-impress ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-brand-impress (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-brand-math:
> openoffice-brand-math hängt ab von openoffice; aber:
> Paket openoffice ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-brand-math (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-brand-writer:
> openoffice-brand-writer hängt ab von openoffice; aber:
> Paket openoffice ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-brand-writer (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-calc:
> openoffice-calc hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-calc (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-draw:
> openoffice-draw hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-draw (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-en-us:
> openoffice-en-us hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-en-us (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-en-us-base:
> openoffice-en-us-base hängt ab von openoffice-en-us; aber:
> Paket openoffice-en-us ist noch nicht konfiguriert.
> Paket openoffice-en-us, das openoffice-en-us bereitstellt, ist noch nicht konfiguriert.
> dpkg: Fehler beim Bearbeiten von openoffice-en-us-base (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-en-us-calc:
> openoffice-en-us-calc hängt ab von openoffice-en-us; aber:
> Paket openoffice-en-us ist noch nicht konfiguriert.
> Paket openoffice-en-us, das openoffice-en-us bereitstellt, ist noch nicht konfiguriert.
> dpkg: Fehler beim Bearbeiten von openoffice-en-us-calc (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-en-us-draw:
> openoffice-en-us-draw hängt ab von openoffice-en-us; aber:
> Paket openoffice-en-us ist noch nicht konfiguriert.
> Paket openoffice-en-us, das openoffice-en-us bereitstellt, ist noch nicht konfiguriert.
> dpkg: Fehler beim Bearbeiten von openoffice-en-us-draw (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-en-us-help:
> openoffice-en-us-help hängt ab von openoffice-en-us; aber:
> Paket openoffice-en-us ist noch nicht konfiguriert.
> Paket openoffice-en-us, das openoffice-en-us bereitstellt, ist noch nicht konfiguriert.
> dpkg: Fehler beim Bearbeiten von openoffice-en-us-help (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-en-us-impress:
> openoffice-en-us-impress hängt ab von openoffice-en-us; aber:
> Paket openoffice-en-us ist noch nicht konfiguriert.
> Paket openoffice-en-us, das openoffice-en-us bereitstellt, ist noch nicht konfiguriert.
> dpkg: Fehler beim Bearbeiten von openoffice-en-us-impress (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-en-us-math:
> openoffice-en-us-math hängt ab von openoffice-en-us; aber:
> Paket openoffice-en-us ist noch nicht konfiguriert.
> Paket openoffice-en-us, das openoffice-en-us bereitstellt, ist noch nicht konfiguriert.
> dpkg: Fehler beim Bearbeiten von openoffice-en-us-math (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-en-us-res:
> openoffice-en-us-res hängt ab von openoffice-en-us; aber:
> Paket openoffice-en-us ist noch nicht konfiguriert.
> Paket openoffice-en-us, das openoffice-en-us bereitstellt, ist noch nicht konfiguriert.
> dpkg: Fehler beim Bearbeiten von openoffice-en-us-res (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-en-us-writer:
> openoffice-en-us-writer hängt ab von openoffice-en-us; aber:
> Paket openoffice-en-us ist noch nicht konfiguriert.
> Paket openoffice-en-us, das openoffice-en-us bereitstellt, ist noch nicht konfiguriert.
> dpkg: Fehler beim Bearbeiten von openoffice-en-us-writer (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-gnome-integration:
> openoffice-gnome-integration hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-gnome-integration (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-graphicfilter:
> openoffice-graphicfilter hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-graphicfilter (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-javafilter:
> openoffice-javafilter hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-javafilter (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-math:
> openoffice-math hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-math (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-ogltrans:
> openoffice-ogltrans hängt ab von openoffice-impress; aber:
> Paket openoffice-impress ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-ogltrans (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-onlineupdate:
> openoffice-onlineupdate hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-onlineupdate (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-ooofonts:
> openoffice-ooofonts hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-ooofonts (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-ooolinguistic:
> openoffice-ooolinguistic hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-ooolinguistic (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-pyuno:
> openoffice-pyuno hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-pyuno (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-writer:
> openoffice-writer hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-writer (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> dpkg: Abhängigkeitsprobleme verhindern Konfiguration von openoffice-xsltfilter:
> openoffice-xsltfilter hängt ab von openoffice-core01; aber:
> Paket openoffice-core01 ist nicht installiert.
> dpkg: Fehler beim Bearbeiten von openoffice-xsltfilter (--install):
> Abhängigkeitsprobleme - verbleibt unkonfiguriert
> Trigger für menu werden verarbeitet ...
> Fehler traten auf beim Bearbeiten von:
> openoffice_4.0.0-2_amd64.deb
> openoffice-base_4.0.0-2_amd64.deb
> openoffice-core01_4.0.0-2_amd64.deb
> openoffice-core02_4.0.0-2_amd64.deb
> openoffice-core03_4.0.0-2_amd64.deb
> openoffice-core04_4.0.0-2_amd64.deb
> openoffice-core05_4.0.0-2_amd64.deb
> openoffice-core06_4.0.0-2_amd64.deb
> openoffice-core07_4.0.0-2_amd64.deb
> openoffice-images_4.0.0-2_amd64.deb
> openoffice-impress_4.0.0-2_amd64.deb
> openoffice-ure_4.0.0-2_amd64.deb
> openoffice-brand-base
> openoffice-brand-calc
> openoffice-brand-draw
> openoffice-brand-en-us
> openoffice-brand-impress
> openoffice-brand-math
> openoffice-brand-writer
> openoffice-calc
> openoffice-draw
> openoffice-en-us
> openoffice-en-us-base
> openoffice-en-us-calc
> openoffice-en-us-draw
> openoffice-en-us-help
> openoffice-en-us-impress
> openoffice-en-us-math
> openoffice-en-us-res
> openoffice-en-us-writer
> openoffice-gnome-integration
> openoffice-graphicfilter
> openoffice-javafilter
> openoffice-math
> openoffice-ogltrans
> openoffice-onlineupdate
> openoffice-ooofonts
> openoffice-ooolinguistic
> openoffice-pyuno
> openoffice-writer
> openoffice-xsltfilter
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
For additional commands, e-mail: api-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Andreas Säger <vi...@t-online.de>.
Am 05.06.2013 14:31, Regina Henschel wrote:
> Hi Andreas,
> Find current snapshot on
> https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds
>
>
> It is not yet totally filled, because building is ongoing.
>
> Find a previous snapshot at
> http://ci.apache.org/projects/openoffice/install/ under winsnap or linsnap.
>
> Kind regards
> Regina
>
Thank you very much. That place is very well hidden from the public.
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
For additional commands, e-mail: api-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Regina Henschel <rb...@t-online.de>.
Hi Andreas,
Andreas Säger schrieb:
> If the developers obviously have no clue how to get things right, if
> even the project lead seems to be completely clueless about the way his
> product works ...
>
>> http://www.mail-archive.com/dev@openoffice.apache.org/msg07883.html
>
> ... how could I contribute anything useful?
>
> I do not even understand my own extension anymore that I wrote 6 years
> ago. I do understand my own code but not the complicated XML
> configuration. The only thing I know for sure is that most of this
> extension used to run with any version from 1.4.x until 3.x.
>
> How could I test anything if I do not have any access to version 4? Am I
> supposed to compile it from source code or what?
Find current snapshot on
https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds
It is not yet totally filled, because building is ongoing.
Find a previous snapshot at
http://ci.apache.org/projects/openoffice/install/ under winsnap or linsnap.
Kind regards
Regina
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
For additional commands, e-mail: api-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Andreas Säger <vi...@t-online.de>.
If the developers obviously have no clue how to get things right, if
even the project lead seems to be completely clueless about the way his
product works ...
> http://www.mail-archive.com/dev@openoffice.apache.org/msg07883.html
... how could I contribute anything useful?
I do not even understand my own extension anymore that I wrote 6 years
ago. I do understand my own code but not the complicated XML
configuration. The only thing I know for sure is that most of this
extension used to run with any version from 1.4.x until 3.x.
How could I test anything if I do not have any access to version 4? Am I
supposed to compile it from source code or what?
Sorry guys. I can happily do my work version 3.4.1 for the rest of my
life. ODF seems to be a dead horse anyway so I'm not afraid of file
format changes in the future.
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
For additional commands, e-mail: api-help@openoffice.apache.org
RE: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Posted by Hans Zybura <hz...@zybura.com>.
Hi,
I'm sorry, I don't have the time to follow every post on the dev and api mailings lists. Being an add-in and extension developer for Microsoft Office and OpenOffice and having a well working add-in/extension for both in place, I normally only need to scan the lists once a week or so for relevant topics. The whole of my AOO extension activities, including support for users of our extension based product, is planned to take about 3% of my working time, in accordance to how much said extension contributes to my sales numbers and income. That's how my working life is organized.
When I happen to read this:
> >> small wrap-up at the top: - nobody prefers to migrate extensions from
> >> AOO 3.4.x resp. OOo 3.x
in conjunction with the obviously outdated and rather crude information about release planning here:
https://cwiki.apache.org/OOOUSERS/aoo-40-release-planning.html
it seems totally clear to me that nothing can change your "nobody prefers to migrate extensions" in time.
I will be delighted if I'm proved to be wrong, in which case I will gladly test the migration of our extension, and - if needed - open a bug report on bugzilla and help with resolving issues.
You know, from my point of view, the whole thread, starting only 5 days *after* the proposed date of RC1, left me speechless for a while, when I detected it. It had never occurred to me that in a project of this dimension one could even think about a new major release without careful and timely consideration of migration processes. The way this is handled looks very much like chaos to me, and I tend to no longer trust in AOO to be a serious, long-term, and reliable project. If this really is the Apache way of project management, it is nothing I want to get used to.
As a side note: my Windows and MacOS users don't "migrate", they wouldn't understand this geeky word. They are able to install a new software version, which is sort of a nuisance in itself for most of them. Afterwards, they expect to see everything in place like before. For most of the programs I use, I'm just such an end user myself. I expect those programs to install/update and then look and feel mostly like before or maybe a bit better, if I'm lucky. The last thing I want to be *told* is what I have to *do* for a proper "migration".
I realize that my stern remarks go partly to the wrong person. For this I apologize.
Regards, Hans
> From: Oliver-Rainer Wittmann [mailto:orwittmann@googlemail.com]
> Sent: Wednesday, June 05, 2013 12:05 PM
> Hi Hans Zybura,
>
> On 04.06.2013 19:26, Hans Zybura wrote:
> > Hi, comments inline...
> >
> > Crosspost to the api mailing list for a reason.
> >
> > Regards, Hans Zybura
> >
> >> -----Original Message----- From: Oliver-Rainer Wittmann
> >> [mailto:orwittmann@googlemail.com] Sent: Monday, June 03, 2013
> >> 10:47 AM To: dev@openoffice.apache.org Subject: Re: [AOO 4.0]:
> >> migration of AOO 3.4.x/OOo 3.x user profile data - help needed
> >>
> >> Hi,
> >>
> >
> > A couple of month ago there was a heated dispute about introducing
> > incompatible changes for extensions in the addons.xcu (for negligible
> > benefit). One of the arguments meant to silence the critics was:
> > Well, it's no problem because we have an update mechanism for
> > extensions. I expressed doubts if the update mechanism would work.
> > Now it turns out I was wrong. I shouldn't have worried about the
> > update mechanism. Without migration, users will have to find and
> > reinstall all of their extensions anyway "by hand".
> >
>
> May be I should have said:
> "Until now, nobody prefers to migrate extensions from AOO 3.4.x resp.
> OOo 3.x".
>
> > The current update mechanism for extensions simply looks for a newer
> > version of the extension by use of a link provided by the extension
> > developer himself. We did that for our extension, but didn't have to
> > make use of it until now.
> >
> > OO developers decided not to take into account compatibility issues
> > caused by introducing incompatible changes in addons.xcu. OK, so we
> > have to deal with it. To prevent any trouble for our customers, we
> > could very likely have provided an automatic update, so that an end
> > user wouldn't have noticed any problem at all after a successful
> > migration.
> >
> > Now OO developers are about to make it impossible for extension
> > developers to simply provide an automatic update before or after the
> > migration to AOO 4.0. Without migrating extensions, there is no
> > automatic update path anymore.
> >
> > Great user experience! Great experience for extension developers and
> > support folks!
> >
> > I remember much talk about the "eco system of AOO" on this mailing
> > list. Is this what the talk was about?
> >
>
> I tried to get involved certain people on this topic.
> I had send my intial post to dev@o.a.o and users@o.a.o. Sorry, that I did not
> include api@o.a.o as I assumed that extension developers are looking at
> dev@o.a.o.
>
> The intention of this thread was not to present facts regarding the
> development. It is meant to show on what I would like to work on for AOO
> 4.0 regarding the migration of the user profile and to get feedback on it.
> (BTW, I had already started a discussion thread in January 2013 regarding the
> migration of the user profile - see thread "[IMPORTANT,
> DISCUSS]: no migration/use of former user profile with AOO 4.0".)
>
> I used terms like "I would like to ...", "My current preference is ..."
> and "I need support and help ..." - I am not presenting facts.
> I explicitly ask for help for these tasks.
> I got no response and no feedback from users@o.a.o. I was disappointed
> about it, because it means that nobody from users@o.a.o seems to be
> interested to help/support me. From dev@o.a.o I only got feedback about
> the risks of a user profile migration and that nobody prefers a migration of
> the extensions.
>
> I have taken your feedback as not constructive criticsm. Your feedback
> sounds like that I decided that extensions will not be migrated. That is not
> the case.
> Earlier in January I already started a similar discussion - see above mentioned
> thread. Here, no strong preferences regarding the migration of extensions
> were given.
> In this thread I expressed my willingness to work on the migration of the user
> profile (which also contains the user installed extensions), otherwise nothing
> will be migrated as stated in January. As this is not a one-person show I asked
> for help and support. The only feedback I got was that a migration might be
> risky and no one has preference to migrate extensions.
> Then I got your feedback which more or less killed my motivation to work on
> the migration of the user profile.
>
> May be you are volunteering to support me as you seem to be interested in
> a working migration of the user profile?
>
>
> Best regards, (a disappointed) Oliver.
>
>
> >>
> >> more comments inline.
> >>
> >> On 02.06.2013 13:17, Andrea Pescetti wrote:
> >>> On 29/05/2013 Oliver-Rainer Wittmann wrote:
> >>>> On 28.05.2013 18:23, Rob Weir wrote:
> >>>>> Do we need to worry about the "messy" profiles that occurred
> >>>>> from OOo 3.3.0 upgrades to AOO 3.4.0? That was when we saw
> >>>>> spell checking breaking, missing dictionaries, and crashes.
> >>>>> One of the nice things about a "clean start" with AOO 4.0 was
> >>>>> that we avoid these kinds of problems.
> >>>> From my point of view AOO 3.4.x users which had problems due to
> >>>> a "messy" profile and had solved these problems, can migrate
> >>>> their profile to AOO 4.0. AOO 3.4.x users which does not had
> >>>> solved their problems are able to suppress the migration of
> >>>> their existing profile - see the corresponding FirstStartWizard
> >>>> page for the user profile
> >> migration.
> >>>
> >>> I agree with Rob here that, since we had only a few widely
> >>> reported bugs in OpenOffice 3.4.1 and one of them depended on the
> >>> profile migration, we should be rather conservative.
> >>>
> >>> I agree it's better not to migrate extensions, since some of
> >>> them might not work in OpenOffice 4 and their description.xml
> >>> file in most cases will only state that they need "OpenOffice 3.0
> >>> or later".
> >>>
> >>>> Yes, an easy reset of the user profile would be great.
> >>>
> >>> This would be a very welcome improvement. Maybe technically this
> >>> could invalidate the current profile and ask the user to restart
> >>> OpenOffice, which would start on a clean profile. This would
> >>> offer a good user experience (not optimal, since the optimal one
> >>> would be triggered by a reinstallation too), and the right moment
> >>> for the cleanup would be just after the code that checks if
> >>> FirstStartWizard must be run and just before the profile is
> >>> loaded and locked (which means that the "invalidate" bit must be
> >>> set in a way that does not require profile access but probably a
> >>> simple filesystem access... OK, I'll stop here!).
> >>>
> >>>> Thus, I assume that the risk of a defect or a regression is low
> >>>> when solving issue 122398 and 122397 for AOO 4.0, except the
> >>>> issue which would be "copied" from a "messy" user profile.
> >>>
> >>> This is a case to consider. So I would suggest to set the
> >>> default answer to "Don't migrate" for extra safety, especially if
> >>> we don't have an easy profile reset mechanism in place.
> >>
> >> I agree. But it will cause translation effort - see screenshot of
> >> FirstStartWizard migration page [1] String "...If you do not want
> >> to reuse any settings in %PRODUCTNAME %PRODUCTVERSION, unmark
> the
> >> check box." will be change to "...If you do want to reuse settings
> >> in %PRODUCTNAME %PRODUCTVERSION, mark the check box."
> >>
> >>>
> >>>> Thus, send my your AOO 3.4.x or OOo 3.x user profile in a
> >>>> compressed form (.zip file or .tar.gz file or ...) or let me
> >>>> know, if you want to try my builds.
> >>>
> >>> If you had a build available, it would be easier for the QA
> >>> volunteers to test.
> >>>
> >>
> >> Yes, that would be the best.
> >>
> >> I will make the changes on trunk. Then the buildbot builds and the
> >> snapshot builds can be tested. As all changes will contain the ID
> >> of the corresponding issue in the submit summary, it will be easy
> >> to revert these changes.
> >>
> >> [1] https://issues.apache.org/ooo/attachment.cgi?id=80738
> >>
> >>
> >> Best regards, Oliver.
> >>
> >> ---------------------------------------------------------------------
> >>
> >>
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >
> >
> > ---------------------------------------------------------------------
> >
> >
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: api-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Posted by Hans Zybura <hz...@zybura.com>.
Hi,
I'm sorry, I don't have the time to follow every post on the dev and api mailings lists. Being an add-in and extension developer for Microsoft Office and OpenOffice and having a well working add-in/extension for both in place, I normally only need to scan the lists once a week or so for relevant topics. The whole of my AOO extension activities, including support for users of our extension based product, is planned to take about 3% of my working time, in accordance to how much said extension contributes to my sales numbers and income. That's how my working life is organized.
When I happen to read this:
> >> small wrap-up at the top: - nobody prefers to migrate extensions from
> >> AOO 3.4.x resp. OOo 3.x
in conjunction with the obviously outdated and rather crude information about release planning here:
https://cwiki.apache.org/OOOUSERS/aoo-40-release-planning.html
it seems totally clear to me that nothing can change your "nobody prefers to migrate extensions" in time.
I will be delighted if I'm proved to be wrong, in which case I will gladly test the migration of our extension, and - if needed - open a bug report on bugzilla and help with resolving issues.
You know, from my point of view, the whole thread, starting only 5 days *after* the proposed date of RC1, left me speechless for a while, when I detected it. It had never occurred to me that in a project of this dimension one could even think about a new major release without careful and timely consideration of migration processes. The way this is handled looks very much like chaos to me, and I tend to no longer trust in AOO to be a serious, long-term, and reliable project. If this really is the Apache way of project management, it is nothing I want to get used to.
As a side note: my Windows and MacOS users don't "migrate", they wouldn't understand this geeky word. They are able to install a new software version, which is sort of a nuisance in itself for most of them. Afterwards, they expect to see everything in place like before. For most of the programs I use, I'm just such an end user myself. I expect those programs to install/update and then look and feel mostly like before or maybe a bit better, if I'm lucky. The last thing I want to be *told* is what I have to *do* for a proper "migration".
I realize that my stern remarks go partly to the wrong person. For this I apologize.
Regards, Hans
> From: Oliver-Rainer Wittmann [mailto:orwittmann@googlemail.com]
> Sent: Wednesday, June 05, 2013 12:05 PM
> Hi Hans Zybura,
>
> On 04.06.2013 19:26, Hans Zybura wrote:
> > Hi, comments inline...
> >
> > Crosspost to the api mailing list for a reason.
> >
> > Regards, Hans Zybura
> >
> >> -----Original Message----- From: Oliver-Rainer Wittmann
> >> [mailto:orwittmann@googlemail.com] Sent: Monday, June 03, 2013
> >> 10:47 AM To: dev@openoffice.apache.org Subject: Re: [AOO 4.0]:
> >> migration of AOO 3.4.x/OOo 3.x user profile data - help needed
> >>
> >> Hi,
> >>
> >
> > A couple of month ago there was a heated dispute about introducing
> > incompatible changes for extensions in the addons.xcu (for negligible
> > benefit). One of the arguments meant to silence the critics was:
> > Well, it's no problem because we have an update mechanism for
> > extensions. I expressed doubts if the update mechanism would work.
> > Now it turns out I was wrong. I shouldn't have worried about the
> > update mechanism. Without migration, users will have to find and
> > reinstall all of their extensions anyway "by hand".
> >
>
> May be I should have said:
> "Until now, nobody prefers to migrate extensions from AOO 3.4.x resp.
> OOo 3.x".
>
> > The current update mechanism for extensions simply looks for a newer
> > version of the extension by use of a link provided by the extension
> > developer himself. We did that for our extension, but didn't have to
> > make use of it until now.
> >
> > OO developers decided not to take into account compatibility issues
> > caused by introducing incompatible changes in addons.xcu. OK, so we
> > have to deal with it. To prevent any trouble for our customers, we
> > could very likely have provided an automatic update, so that an end
> > user wouldn't have noticed any problem at all after a successful
> > migration.
> >
> > Now OO developers are about to make it impossible for extension
> > developers to simply provide an automatic update before or after the
> > migration to AOO 4.0. Without migrating extensions, there is no
> > automatic update path anymore.
> >
> > Great user experience! Great experience for extension developers and
> > support folks!
> >
> > I remember much talk about the "eco system of AOO" on this mailing
> > list. Is this what the talk was about?
> >
>
> I tried to get involved certain people on this topic.
> I had send my intial post to dev@o.a.o and users@o.a.o. Sorry, that I did not
> include api@o.a.o as I assumed that extension developers are looking at
> dev@o.a.o.
>
> The intention of this thread was not to present facts regarding the
> development. It is meant to show on what I would like to work on for AOO
> 4.0 regarding the migration of the user profile and to get feedback on it.
> (BTW, I had already started a discussion thread in January 2013 regarding the
> migration of the user profile - see thread "[IMPORTANT,
> DISCUSS]: no migration/use of former user profile with AOO 4.0".)
>
> I used terms like "I would like to ...", "My current preference is ..."
> and "I need support and help ..." - I am not presenting facts.
> I explicitly ask for help for these tasks.
> I got no response and no feedback from users@o.a.o. I was disappointed
> about it, because it means that nobody from users@o.a.o seems to be
> interested to help/support me. From dev@o.a.o I only got feedback about
> the risks of a user profile migration and that nobody prefers a migration of
> the extensions.
>
> I have taken your feedback as not constructive criticsm. Your feedback
> sounds like that I decided that extensions will not be migrated. That is not
> the case.
> Earlier in January I already started a similar discussion - see above mentioned
> thread. Here, no strong preferences regarding the migration of extensions
> were given.
> In this thread I expressed my willingness to work on the migration of the user
> profile (which also contains the user installed extensions), otherwise nothing
> will be migrated as stated in January. As this is not a one-person show I asked
> for help and support. The only feedback I got was that a migration might be
> risky and no one has preference to migrate extensions.
> Then I got your feedback which more or less killed my motivation to work on
> the migration of the user profile.
>
> May be you are volunteering to support me as you seem to be interested in
> a working migration of the user profile?
>
>
> Best regards, (a disappointed) Oliver.
>
>
> >>
> >> more comments inline.
> >>
> >> On 02.06.2013 13:17, Andrea Pescetti wrote:
> >>> On 29/05/2013 Oliver-Rainer Wittmann wrote:
> >>>> On 28.05.2013 18:23, Rob Weir wrote:
> >>>>> Do we need to worry about the "messy" profiles that occurred
> >>>>> from OOo 3.3.0 upgrades to AOO 3.4.0? That was when we saw
> >>>>> spell checking breaking, missing dictionaries, and crashes.
> >>>>> One of the nice things about a "clean start" with AOO 4.0 was
> >>>>> that we avoid these kinds of problems.
> >>>> From my point of view AOO 3.4.x users which had problems due to
> >>>> a "messy" profile and had solved these problems, can migrate
> >>>> their profile to AOO 4.0. AOO 3.4.x users which does not had
> >>>> solved their problems are able to suppress the migration of
> >>>> their existing profile - see the corresponding FirstStartWizard
> >>>> page for the user profile
> >> migration.
> >>>
> >>> I agree with Rob here that, since we had only a few widely
> >>> reported bugs in OpenOffice 3.4.1 and one of them depended on the
> >>> profile migration, we should be rather conservative.
> >>>
> >>> I agree it's better not to migrate extensions, since some of
> >>> them might not work in OpenOffice 4 and their description.xml
> >>> file in most cases will only state that they need "OpenOffice 3.0
> >>> or later".
> >>>
> >>>> Yes, an easy reset of the user profile would be great.
> >>>
> >>> This would be a very welcome improvement. Maybe technically this
> >>> could invalidate the current profile and ask the user to restart
> >>> OpenOffice, which would start on a clean profile. This would
> >>> offer a good user experience (not optimal, since the optimal one
> >>> would be triggered by a reinstallation too), and the right moment
> >>> for the cleanup would be just after the code that checks if
> >>> FirstStartWizard must be run and just before the profile is
> >>> loaded and locked (which means that the "invalidate" bit must be
> >>> set in a way that does not require profile access but probably a
> >>> simple filesystem access... OK, I'll stop here!).
> >>>
> >>>> Thus, I assume that the risk of a defect or a regression is low
> >>>> when solving issue 122398 and 122397 for AOO 4.0, except the
> >>>> issue which would be "copied" from a "messy" user profile.
> >>>
> >>> This is a case to consider. So I would suggest to set the
> >>> default answer to "Don't migrate" for extra safety, especially if
> >>> we don't have an easy profile reset mechanism in place.
> >>
> >> I agree. But it will cause translation effort - see screenshot of
> >> FirstStartWizard migration page [1] String "...If you do not want
> >> to reuse any settings in %PRODUCTNAME %PRODUCTVERSION, unmark
> the
> >> check box." will be change to "...If you do want to reuse settings
> >> in %PRODUCTNAME %PRODUCTVERSION, mark the check box."
> >>
> >>>
> >>>> Thus, send my your AOO 3.4.x or OOo 3.x user profile in a
> >>>> compressed form (.zip file or .tar.gz file or ...) or let me
> >>>> know, if you want to try my builds.
> >>>
> >>> If you had a build available, it would be easier for the QA
> >>> volunteers to test.
> >>>
> >>
> >> Yes, that would be the best.
> >>
> >> I will make the changes on trunk. Then the buildbot builds and the
> >> snapshot builds can be tested. As all changes will contain the ID
> >> of the corresponding issue in the submit summary, it will be easy
> >> to revert these changes.
> >>
> >> [1] https://issues.apache.org/ooo/attachment.cgi?id=80738
> >>
> >>
> >> Best regards, Oliver.
> >>
> >> ---------------------------------------------------------------------
> >>
> >>
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> >> For additional commands, e-mail: dev-help@openoffice.apache.org
> >
> >
> > ---------------------------------------------------------------------
> >
> >
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: api-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
For additional commands, e-mail: api-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi Hans Zybura,
On 04.06.2013 19:26, Hans Zybura wrote:
> Hi, comments inline...
>
> Crosspost to the api mailing list for a reason.
>
> Regards, Hans Zybura
>
>> -----Original Message----- From: Oliver-Rainer Wittmann
>> [mailto:orwittmann@googlemail.com] Sent: Monday, June 03, 2013
>> 10:47 AM To: dev@openoffice.apache.org Subject: Re: [AOO 4.0]:
>> migration of AOO 3.4.x/OOo 3.x user profile data - help needed
>>
>> Hi,
>>
>> small wrap-up at the top: - nobody prefers to migrate extensions
>> from AOO 3.4.x resp. OOo 3.x
>
> A couple of month ago there was a heated dispute about introducing
> incompatible changes for extensions in the addons.xcu (for negligible
> benefit). One of the arguments meant to silence the critics was:
> Well, it's no problem because we have an update mechanism for
> extensions. I expressed doubts if the update mechanism would work.
> Now it turns out I was wrong. I shouldn't have worried about the
> update mechanism. Without migration, users will have to find and
> reinstall all of their extensions anyway "by hand".
>
May be I should have said:
"Until now, nobody prefers to migrate extensions from AOO 3.4.x resp.
OOo 3.x".
> The current update mechanism for extensions simply looks for a newer
> version of the extension by use of a link provided by the extension
> developer himself. We did that for our extension, but didn't have to
> make use of it until now.
>
> OO developers decided not to take into account compatibility issues
> caused by introducing incompatible changes in addons.xcu. OK, so we
> have to deal with it. To prevent any trouble for our customers, we
> could very likely have provided an automatic update, so that an end
> user wouldn't have noticed any problem at all after a successful
> migration.
>
> Now OO developers are about to make it impossible for extension
> developers to simply provide an automatic update before or after the
> migration to AOO 4.0. Without migrating extensions, there is no
> automatic update path anymore.
>
> Great user experience! Great experience for extension developers and
> support folks!
>
> I remember much talk about the "eco system of AOO" on this mailing
> list. Is this what the talk was about?
>
I tried to get involved certain people on this topic.
I had send my intial post to dev@o.a.o and users@o.a.o. Sorry, that I
did not include api@o.a.o as I assumed that extension developers are
looking at dev@o.a.o.
The intention of this thread was not to present facts regarding the
development. It is meant to show on what I would like to work on for AOO
4.0 regarding the migration of the user profile and to get feedback on
it. (BTW, I had already started a discussion thread in January 2013
regarding the migration of the user profile - see thread "[IMPORTANT,
DISCUSS]: no migration/use of former user profile with AOO 4.0".)
I used terms like "I would like to ...", "My current preference is ..."
and "I need support and help ..." - I am not presenting facts.
I explicitly ask for help for these tasks.
I got no response and no feedback from users@o.a.o. I was disappointed
about it, because it means that nobody from users@o.a.o seems to be
interested to help/support me. From dev@o.a.o I only got feedback about
the risks of a user profile migration and that nobody prefers a
migration of the extensions.
I have taken your feedback as not constructive criticsm. Your feedback
sounds like that I decided that extensions will not be migrated. That is
not the case.
Earlier in January I already started a similar discussion - see above
mentioned thread. Here, no strong preferences regarding the migration of
extensions were given.
In this thread I expressed my willingness to work on the migration of
the user profile (which also contains the user installed extensions),
otherwise nothing will be migrated as stated in January. As this is not
a one-person show I asked for help and support. The only feedback I got
was that a migration might be risky and no one has preference to migrate
extensions.
Then I got your feedback which more or less killed my motivation to work
on the migration of the user profile.
May be you are volunteering to support me as you seem to be interested
in a working migration of the user profile?
Best regards, (a disappointed) Oliver.
>>
>> more comments inline.
>>
>> On 02.06.2013 13:17, Andrea Pescetti wrote:
>>> On 29/05/2013 Oliver-Rainer Wittmann wrote:
>>>> On 28.05.2013 18:23, Rob Weir wrote:
>>>>> Do we need to worry about the "messy" profiles that occurred
>>>>> from OOo 3.3.0 upgrades to AOO 3.4.0? That was when we saw
>>>>> spell checking breaking, missing dictionaries, and crashes.
>>>>> One of the nice things about a "clean start" with AOO 4.0 was
>>>>> that we avoid these kinds of problems.
>>>> From my point of view AOO 3.4.x users which had problems due to
>>>> a "messy" profile and had solved these problems, can migrate
>>>> their profile to AOO 4.0. AOO 3.4.x users which does not had
>>>> solved their problems are able to suppress the migration of
>>>> their existing profile - see the corresponding FirstStartWizard
>>>> page for the user profile
>> migration.
>>>
>>> I agree with Rob here that, since we had only a few widely
>>> reported bugs in OpenOffice 3.4.1 and one of them depended on the
>>> profile migration, we should be rather conservative.
>>>
>>> I agree it's better not to migrate extensions, since some of
>>> them might not work in OpenOffice 4 and their description.xml
>>> file in most cases will only state that they need "OpenOffice 3.0
>>> or later".
>>>
>>>> Yes, an easy reset of the user profile would be great.
>>>
>>> This would be a very welcome improvement. Maybe technically this
>>> could invalidate the current profile and ask the user to restart
>>> OpenOffice, which would start on a clean profile. This would
>>> offer a good user experience (not optimal, since the optimal one
>>> would be triggered by a reinstallation too), and the right moment
>>> for the cleanup would be just after the code that checks if
>>> FirstStartWizard must be run and just before the profile is
>>> loaded and locked (which means that the "invalidate" bit must be
>>> set in a way that does not require profile access but probably a
>>> simple filesystem access... OK, I'll stop here!).
>>>
>>>> Thus, I assume that the risk of a defect or a regression is low
>>>> when solving issue 122398 and 122397 for AOO 4.0, except the
>>>> issue which would be "copied" from a "messy" user profile.
>>>
>>> This is a case to consider. So I would suggest to set the
>>> default answer to "Don't migrate" for extra safety, especially if
>>> we don't have an easy profile reset mechanism in place.
>>
>> I agree. But it will cause translation effort - see screenshot of
>> FirstStartWizard migration page [1] String "...If you do not want
>> to reuse any settings in %PRODUCTNAME %PRODUCTVERSION, unmark the
>> check box." will be change to "...If you do want to reuse settings
>> in %PRODUCTNAME %PRODUCTVERSION, mark the check box."
>>
>>>
>>>> Thus, send my your AOO 3.4.x or OOo 3.x user profile in a
>>>> compressed form (.zip file or .tar.gz file or ...) or let me
>>>> know, if you want to try my builds.
>>>
>>> If you had a build available, it would be easier for the QA
>>> volunteers to test.
>>>
>>
>> Yes, that would be the best.
>>
>> I will make the changes on trunk. Then the buildbot builds and the
>> snapshot builds can be tested. As all changes will contain the ID
>> of the corresponding issue in the submit summary, it will be easy
>> to revert these changes.
>>
>> [1] https://issues.apache.org/ooo/attachment.cgi?id=80738
>>
>>
>> Best regards, Oliver.
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi
On 18.06.2013 22:06, Rory O'Farrell wrote:
> On Tue, 18 Jun 2013 21:54:52 +0200 Andrea Pescetti
> <pe...@apache.org> wrote:
>
>> Ariel Constenla-Haile wrote:
>>> On Tue, Jun 18, 2013 at 5:21 AM, Oliver-Rainer Wittmann wrote:
>>>> Do you have one or two C++ extension at hand (except former
>>>> Presenter Screen and former Presenation Minizer) for testing?
>>> The PDF Import extension:
>>> http://extensions.openoffice.org/en/project/pdfimport MySQL
>>> Connector:
>>> http://extensions.openoffice.org/en/project/mysql_connector My
>>> version of this last one:
>>> http://code.google.com/a/apache-extras.org/p/aoo-my-sdbc/
>>
>> This deserves some discussion: these two extensions are very
>> popular so it would be better to find a solution to this before
>> users ask for support in scores.
>>
>> If I understand correctly, we have now have two problems with
>> these extensions: 1) License: both extensions have GPL (or similar)
>> dependencies, so they cannot be formally released by this Apache
>> project. 2) Compatibility: the STLport change makes the latest
>> versions incompatible with OpenOffice 4.0.
>>
>> Can the problem be solved by simply rebuilding the two extensions
>> in the new framework? If it isn't too hard, it's better to upload
>> an "unofficial" version (meaning: released by individual
>> developers, but not officially by the project) to the Extensions
>> site than dealing with feature limitations and support requests.
>>
>> For the time being, I updated
>> http://wiki.openoffice.org/wiki/Extensions/Extensions_and_Apache_OpenOffice_4.0
>>with this information.
>>
>> Regards, Andrea.
>>
> For me, the absence of the Presenter Console would be a major barrier
> to canverting my presentation laptops to AOO 4.0. I hope a way, even
> if not an official release, can be found to make this available more
> or less concurrently with the AOO 4.0 release.
>
> If Presentation Minimizer is being rewritten, some thought should be
> given towards adapting the code to provide a similar optimisation and
> reduction process for Writer documents; users often insert
> illustrations of considerably too higgh a resolution and size into
> Writer. A minimise process for this application wuld be useful.
>
>
The Presenter Screen and the Presentation Minimizer have been integrated
into OpenOffice as 'native' functions - Thanks to Ariel.
Thus, the corresponding functionality is available in AOO 4.0.
Best regards, Oliver.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Rory O'Farrell <of...@iol.ie>.
On Wed, 19 Jun 2013 08:18:28 +0200
Andrea Pescetti <pe...@apache.org> wrote:
> Rory O'Farrell wrote:
> > On Tue, 18 Jun 2013 21:54:52 +0200 Andrea Pescetti wrote:
> >> Ariel Constenla-Haile wrote:
> >>> On Tue, Jun 18, 2013 at 5:21 AM, Oliver-Rainer Wittmann wrote:
> >>>> Do you have one or two C++ extension at hand (except former Presenter Screen
> >>>> and former Presenation Minizer) for testing?
> >>> The PDF Import extension: http://extensions.openoffice.org/en/project/pdfimport
> >>> MySQL Connector: http://extensions.openoffice.org/en/project/mysql_connector
> >>> My version of this last one:
> >>> http://code.google.com/a/apache-extras.org/p/aoo-my-sdbc/
> >> This deserves some discussion: these two extensions are very popular so
> >> it would be better to find a solution to this before users ask for
> >> support in scores.
> > For me, the absence of the Presenter Console would be a major barrier
>
> The "two extensions" I was referring to are: PDF Import and MySQL Connector.
>
> Presenter Console and Presentation Minimizer, as Oliver wrote, are
> staying: they won't be packaged as extensions since they will be
> directly integrated in OpenOffice. So their functionality will be
> available in 4.0 with no changes and no need to update any extensions.
>
> Regards,
> Andrea.
>
Thank you, Andrea; I obviously misunderstood the situation, for which I apologise. It is excellent news that the two Presenter extensions will be integrated into OpenOffice 4.0; Presenter Console, once demonstrated to a non OpenOffice User, often becomes a major factor in converting him to OpenOffice.
--
Rory O'Farrell <of...@iol.ie>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Andrea Pescetti <pe...@apache.org>.
Rory O'Farrell wrote:
> On Tue, 18 Jun 2013 21:54:52 +0200 Andrea Pescetti wrote:
>> Ariel Constenla-Haile wrote:
>>> On Tue, Jun 18, 2013 at 5:21 AM, Oliver-Rainer Wittmann wrote:
>>>> Do you have one or two C++ extension at hand (except former Presenter Screen
>>>> and former Presenation Minizer) for testing?
>>> The PDF Import extension: http://extensions.openoffice.org/en/project/pdfimport
>>> MySQL Connector: http://extensions.openoffice.org/en/project/mysql_connector
>>> My version of this last one:
>>> http://code.google.com/a/apache-extras.org/p/aoo-my-sdbc/
>> This deserves some discussion: these two extensions are very popular so
>> it would be better to find a solution to this before users ask for
>> support in scores.
> For me, the absence of the Presenter Console would be a major barrier
The "two extensions" I was referring to are: PDF Import and MySQL Connector.
Presenter Console and Presentation Minimizer, as Oliver wrote, are
staying: they won't be packaged as extensions since they will be
directly integrated in OpenOffice. So their functionality will be
available in 4.0 with no changes and no need to update any extensions.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Rory O'Farrell <of...@iol.ie>.
On Tue, 18 Jun 2013 21:54:52 +0200
Andrea Pescetti <pe...@apache.org> wrote:
> Ariel Constenla-Haile wrote:
> > On Tue, Jun 18, 2013 at 5:21 AM, Oliver-Rainer Wittmann wrote:
> >> Do you have one or two C++ extension at hand (except former Presenter Screen
> >> and former Presenation Minizer) for testing?
> > The PDF Import extension: http://extensions.openoffice.org/en/project/pdfimport
> > MySQL Connector: http://extensions.openoffice.org/en/project/mysql_connector
> > My version of this last one:
> > http://code.google.com/a/apache-extras.org/p/aoo-my-sdbc/
>
> This deserves some discussion: these two extensions are very popular so
> it would be better to find a solution to this before users ask for
> support in scores.
>
> If I understand correctly, we have now have two problems with these
> extensions:
> 1) License: both extensions have GPL (or similar) dependencies, so they
> cannot be formally released by this Apache project.
> 2) Compatibility: the STLport change makes the latest versions
> incompatible with OpenOffice 4.0.
>
> Can the problem be solved by simply rebuilding the two extensions in the
> new framework? If it isn't too hard, it's better to upload an
> "unofficial" version (meaning: released by individual developers, but
> not officially by the project) to the Extensions site than dealing with
> feature limitations and support requests.
>
> For the time being, I updated
> http://wiki.openoffice.org/wiki/Extensions/Extensions_and_Apache_OpenOffice_4.0
> with this information.
>
> Regards,
> Andrea.
>
For me, the absence of the Presenter Console would be a major barrier to canverting my presentation laptops to AOO 4.0. I hope a way, even if not an official release, can be found to make this available more or less concurrently with the AOO 4.0 release.
If Presentation Minimizer is being rewritten, some thought should be given towards adapting the code to provide a similar optimisation and reduction process for Writer documents; users often insert illustrations of considerably too higgh a resolution and size into Writer. A minimise process for this application wuld be useful.
--
Rory O'Farrell <of...@iol.ie>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Andrea Pescetti <pe...@apache.org>.
Ariel Constenla-Haile wrote:
> On Tue, Jun 18, 2013 at 5:21 AM, Oliver-Rainer Wittmann wrote:
>> Do you have one or two C++ extension at hand (except former Presenter Screen
>> and former Presenation Minizer) for testing?
> The PDF Import extension: http://extensions.openoffice.org/en/project/pdfimport
> MySQL Connector: http://extensions.openoffice.org/en/project/mysql_connector
> My version of this last one:
> http://code.google.com/a/apache-extras.org/p/aoo-my-sdbc/
This deserves some discussion: these two extensions are very popular so
it would be better to find a solution to this before users ask for
support in scores.
If I understand correctly, we have now have two problems with these
extensions:
1) License: both extensions have GPL (or similar) dependencies, so they
cannot be formally released by this Apache project.
2) Compatibility: the STLport change makes the latest versions
incompatible with OpenOffice 4.0.
Can the problem be solved by simply rebuilding the two extensions in the
new framework? If it isn't too hard, it's better to upload an
"unofficial" version (meaning: released by individual developers, but
not officially by the project) to the Extensions site than dealing with
feature limitations and support requests.
For the time being, I updated
http://wiki.openoffice.org/wiki/Extensions/Extensions_and_Apache_OpenOffice_4.0
with this information.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Tue, Jun 18, 2013 at 5:21 AM, Oliver-Rainer Wittmann
<or...@googlemail.com> wrote:
>>> On the blacklist will be the Presenter Screen and the Presentation
>>> Minimizer as they are now integrated into OpenOffice.
>>
>>
>> These wouldn't work anyway; after the STLport change, former C++
>> extensions do not work on Windows and Linux 32 bit (I guess also in
>> MacOS, as this affects 32 bit archs, where stlport was used). If there
>> is a way to tell the migration service not to migrate C++ (excepting Linux
>> 64 bit), it might be good to turn this option on.
>>
>>
>
> I do not know of such an option.
> Do you know how this can be found out by observing the extension?
>
> Do you have one or two C++ extension at hand (except former Presenter Screen
> and former Presenation Minizer) for testing?
The PDF Import extension: http://extensions.openoffice.org/en/project/pdfimport
MySQL Connector: http://extensions.openoffice.org/en/project/mysql_connector
My version of this last one:
http://code.google.com/a/apache-extras.org/p/aoo-my-sdbc/
Regards
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 18.06.2013 10:05, Ariel Constenla-Haile wrote:
> On Tue, Jun 18, 2013 at 09:51:46AM +0200, Oliver-Rainer Wittmann wrote:
>> On the blacklist will be the Presenter Screen and the Presentation
>> Minimizer as they are now integrated into OpenOffice.
>
> These wouldn't work anyway; after the STLport change, former C++
> extensions do not work on Windows and Linux 32 bit (I guess also in
> MacOS, as this affects 32 bit archs, where stlport was used). If there
> is a way to tell the migration service not to migrate C++ (excepting Linux
> 64 bit), it might be good to turn this option on.
>
>
I do not know of such an option.
Do you know how this can be found out by observing the extension?
Do you have one or two C++ extension at hand (except former Presenter
Screen and former Presenation Minizer) for testing?
Thanks in advance,
Oliver.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Ariel Constenla-Haile <ar...@apache.org>.
On Tue, Jun 18, 2013 at 09:51:46AM +0200, Oliver-Rainer Wittmann wrote:
> On the blacklist will be the Presenter Screen and the Presentation
> Minimizer as they are now integrated into OpenOffice.
These wouldn't work anyway; after the STLport change, former C++
extensions do not work on Windows and Linux 32 bit (I guess also in
MacOS, as this affects 32 bit archs, where stlport was used). If there
is a way to tell the migration service not to migrate C++ (excepting Linux
64 bit), it might be good to turn this option on.
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 6/4/13 11:28 PM, Hagar Delest wrote:
> Le 04/06/2013 22:47, Juergen Schmidt a écrit :
>> Well I am getting tired to repeat this again and again. Nobody should
>> expect that others do what's necessary, Just do it yourself -> it's a
>> community project.
> That's the problem. It seems there are different levels of understanding
> for the "community".
>
> You tend to think that there is a huge community backing AOO and ready
> to jump into the code and other areas.
don't think that I am so stupid but we have enough things to do where
people without development skills can help and can do something.
And please don't generalize this, we talked with extension developers.
There are of course different groups of extension developers, with
different skill levels.
For me it's a difference if somebody who don't have the skills but shows
interest and ask the right questions or if somebody complain and request
that things get be done.
> I think that the reality is quite different: there is a huge base of
> users. But only users; wanting the application to work without having to
> put the hands inside.
I hope we always have a bigger user base than active community members.
Otherwise it would be a bad ratio but I agree that we could benefit fro
more volunteers in all areas.
>
>
> Let's face it: there are very few with dev skills; so you can't tell
> "just do it". What if we can't do it? Just shut up?
> If we shut up, nobody else will care about the users.
Nobody say that anybody should shut up.
We talk here about one specific case and not in general. Really anybody
interested could have started on the communication part.
Juergen
>
> Hagar
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Hagar Delest <ha...@laposte.net>.
Le 14/06/2013 12:14, Hans Zybura a écrit :
> Or see it this way: For an extension author like me, AOO is functioning
> similar to another layer of an operating system. So please ask yourself in
> analogy: Would any of the AOO developers want to define for AOO 4.0 a
> Maxversion like <don't run on Windows 9>? I don't think so. And whatever
> the reasons may be, the same reasons apply in the reasoning of an extension
> developers.
Good analogy indeed!
With Firefox extensions, I had to set the max version to 99 to avoid having them deactivated at each upgrade (required the tweaking of the configuration files of each extension). I think that they changed the behavior so that they are by default re-used at upgrade now, they have listened to their users.
A max version is too much troubles. What version to set? The current one? The next major one? We don't know what will be the changes in the future so how to determine the max version?
Hagar
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 6/15/13 10:21 AM, Andrea Pescetti wrote:
> On 14/06/2013 Hans Zybura wrote:
>> Therefore I'd like to recommend some additions
>
> Thank you, integrated in
>
> http://wiki.openoffice.org/wiki/Extensions/Extensions_and_Apache_OpenOffice_4.0
>
>
>> One last time I want to comment on Jürgen Schmidt's recommendation to
>> define
>> a Maxversion.
>
> Indicating a "max" version will ensure that the extension is only run on
> OpenOffice version it has been tested on. But I've changed (back) the
> wording to "Typical" and "Recommended", which is quite accurate, since
> I've never seen the "max" version being used in practice. If one prefers
> to do like Hagar and not set a "max" version, this can probably be
> addressed (but I cannot check now) by editing the Release page on the
> extensions.openoffice.org site and simply adding that it is compatible
> with version 4.0.
Extension developers can do of course whatever they want. My
recommendation is to test an extension against the next coming version
(whatever it is, major or minor) and release a new micro update of the
extension with an updated max version. This can be done as part of a QA
process and it will ensure that the extensions will work and it will
avoid problems.
If you sell your extension it is up to you to distribute it, you can
give micro extensions for free.
Many extension will work without a max version dependency but we have
seen problems here in the past and that is the reason why I recommend
the max version now.
Juergen
>
> Regards,
> Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Andrea Pescetti <pe...@apache.org>.
On 14/06/2013 Hans Zybura wrote:
> Therefore I'd like to recommend some additions
Thank you, integrated in
http://wiki.openoffice.org/wiki/Extensions/Extensions_and_Apache_OpenOffice_4.0
> One last time I want to comment on Jürgen Schmidt's recommendation to define
> a Maxversion.
Indicating a "max" version will ensure that the extension is only run on
OpenOffice version it has been tested on. But I've changed (back) the
wording to "Typical" and "Recommended", which is quite accurate, since
I've never seen the "max" version being used in practice. If one prefers
to do like Hagar and not set a "max" version, this can probably be
addressed (but I cannot check now) by editing the Release page on the
extensions.openoffice.org site and simply adding that it is compatible
with version 4.0.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Posted by Hans Zybura <hz...@zybura.com>.
Andrea, first I'd like to thank you for starting this web-page!
OO Developers tend to have a somewhat limited view of the large variety of
scenarios, how , why, and by whom extensions are created and maintained.
Please note that the extension repository, although it is certainly a great
source of extensions, is by far not the only one, even not the most
important one. E.g. commercial extensions are mostly not downloadable via
the extension repository, but the publishers may be advertising their
solution there. But the vast amount of extensions existing will not even be
publicly visible/available, because they are created for companies small and
large, or privately for a friend/oneself.
Therefore I'd like to recommend some additions (sorry for my limited
English):
<start>
For commercial extensions, please contact the publisher for support. In case
an extension is not publicly available, but only used privately or in your
company/institution, please ask either the author of your extension or a
person responsible in your company/institution for help.
Please note: If a certain extension is crucial for your personal or
professional workflow, you should not install AOO 4.0 before having made
sure that this extension will work on AOO 4.0 or that an update of the
extension is available.
</end>
One last time I want to comment on Jürgen Schmidt's recommendation to define
a Maxversion. Maybe there are special cases, where this is feasible, e.g. in
a (not to small) company where you are able to guarantee availability of
support at any time. In some very special cases (from my POV) it may even be
vital to do that. So defining a Maxversion may be seen as an important
option at hand.
That does not say that it has to be recommended as best practice or even
mandatory. The word "deprecated" seems to imply the latter. A commercial
solution simply cannot afford to define a Maxversion, because users would
understand this to be a predetermined breaking point for making more money
only. Customers are very suspicious in this regard because of the ever
shortening life cycle of technical hardware products nowadays.
Or see it this way: For an extension author like me, AOO is functioning
similar to another layer of an operating system. So please ask yourself in
analogy: Would any of the AOO developers want to define for AOO 4.0 a
Maxversion like <don't run on Windows 9>? I don't think so. And whatever
the reasons may be, the same reasons apply in the reasoning of an extension
developers.
Kind regards, Hans
> -----Original Message-----
> From: Andrea Pescetti [mailto:pescetti@apache.org]
> Sent: Thursday, June 13, 2013 11:45 PM
> To: dev@openoffice.apache.org
> Subject: Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
> help needed
>
> On 05/06/2013 Hagar Delest wrote:
> > There has been a lot of posts in that discussion, even some proposals
> > but we are approaching the 4.0 release and I've not seen a single
> > warning for the extensions authors about the changes needed or any
> > proposal to warn users.
>
> I've started a wiki page at
>
> http://wiki.openoffice.org/wiki/Extensions/Extensions_and_Apache_Open
> Office_4.0
>
> It's still incomplete, and I hope that developers with knowledge may step
in
> and fill in the gaps.
>
> It is meant to be a resource that we will want to advertise in the release
> notes and make available to users when they seek support, so please have a
> look, and feel free to improve and complete it.
>
> Regards,
> Andrea.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 6/18/13 2:17 PM, Oliver-Rainer Wittmann wrote:
> Hi,
>
> On 18.06.2013 13:36, Rob Weir wrote:
>> On Tue, Jun 18, 2013 at 3:51 AM, Oliver-Rainer Wittmann
>> <or...@googlemail.com> wrote:
>>> Hi,
>>>
>>>
>>> On 18.06.2013 09:26, Andrea Pescetti wrote:
>>>>
>>>> On 17/06/2013 Oliver-Rainer Wittmann wrote:
>>>>>
>>>>> I want to let you know that I am currently working on the migration of
>>>>> AOO 3.4.x/OOo 3.x user profiles to AOO 4.0. I am also including the
>>>>> migration of extensions.
>>>>> I am currently not planning to adjust any of the mentioned strings
>>>>> as I
>>>>> think it is too late for its translation.
>>>>
>>>>
>>>> Is this safe? In a typical scenario, then, a user would have some
>>>> extensions installed and he would see them imported in 4.0 without
>>>> being
>>>> warned about possible compatibility problems. Most of the extensions do
>>>> not have a maxversion indication, so OpenOffice 4.0 will try and
>>>> install
>>>> them anyway, but some might be broken. And then the user is left alone
>>>> in updating his extensions (which in theory he should be prompted to do
>>>> after installation, assuming this mechanism is restored), but he
>>>> wouldn't have a way to go back before it's too late.
>>>>
>>>
>>> I had a close look at the functionality to 'migrate the extensions
>>> from a
>>> former user profile' and from my point of view we should give it a try.
>>>
>>> The function did the following:
>>> It looks for the extensions which are installed for the user. These are
>>> found in the former user profile. No shared-installed, bundled or
>>> pre-registered extensions are considered. The found user-installed
>>> extensions which are not on the blacklist are installed with the same
>>> mechanism which is used when the users triggers in the installation.
>>> I am activating an user interaction in case that an extension is already
>>> installed - the same user interaction which is used when the user
>>> triggers
>>> the installation of an already installed extension.
>>>
>>> On the blacklist will be the Presenter Screen and the Presentation
>>> Minimizer
>>> as they are now integrated into OpenOffice.
>>>
>>
>> Is the blacklist a static list? Or is it something that can be
>> retried/updated from the website?
>>
>
> The blacklist is part of our source code. These are corresponding
> entries in a XCU file - namely
> main/officecfg/registry/data/org/openoffice/Setup.xcu
> Have a look at my commit - revision 1494066 [1]. Search for
> 'ExcludedExtensions'
>
> [1] http://svn.apache.org/r1494066
>
>> If we can make the blacklist be "live" in a document that we can
>> update, this is like maintaining our own max version field for the
>> cases where the extension author neglected to do so.
>>
>
> Such a feature is possible.
> It could be corresponding XML feed which OpenOffice could be accessed
> via the Internet - like the XML feed for the update service.
before we implement further features in the context of the extension
manager I would like to propose a complete review of the current design.
That means analyze what we have today and we want to provide reliable
tomorrow and rework the code according the new requirements. This means
mainly a simplification of the current implementation to make it more
better maintainable, more robust and easier to understand.
The first feature that I would drop is the live deployment that is a
nice feature but not worth the complexity that it brings in the code. A
clean office restart after the installation should be no problem.
We need also a better and cleaner way to handle and deploy bundled
extensions like dictionaries etc. I would like to avoid the installation
in the user home directory...
Many more things come into my mind.
The blacklist was of course not intended to be used to manage a big list
of extensions.
Juergen
>
> Best regards, Oliver.
>
>> -Rob
>>
>>
>>>
>>>
>>>>> If my tests work fine, I will check-in the changes this week. If we
>>>>> will
>>>>> include these changes into our AOO 4.0 release, I will help to update
>>>>> the above wiki page.
>>>>
>>>>
>>>> Let's keep them documented and see. Remember that we learned so far
>>>> that
>>>> a random user will manage to reinstall but not to do anything more
>>>> elaborated, so if uninstallation/installation does not bring up a "Do
>>>> you want to reset your profile?" dialog we still have a usability
>>>> problem (which of course is not a regression, it's been there forever).
>>>>
>>>
>>> Agreed.
>>>
>>>
>>> Best regards, Oliver.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>>
>>
>>
>>
>> --
>> Opinions expressed in this communication reflect the author's
>> individual personal view, not necessarily that of an amorphous
>> collective. The above statements do not reflect an official position
>> of any organization, corporation, religion (organized or disorganized)
>> or national football association. The contents of said note are not
>> guaranteed to have been spell checked, grammar checked or reviewed for
>> metrical infelicities. The contents of this post may not be suitable
>> for those whose native language is not logic. Caution should be
>> exercised when operating heavy machinery when reading this note, or
>> even when not reading it. Seriously, heavy machinery is dangerous.
>> Be careful.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 18.06.2013 13:36, Rob Weir wrote:
> On Tue, Jun 18, 2013 at 3:51 AM, Oliver-Rainer Wittmann
> <or...@googlemail.com> wrote:
>> Hi,
>>
>>
>> On 18.06.2013 09:26, Andrea Pescetti wrote:
>>>
>>> On 17/06/2013 Oliver-Rainer Wittmann wrote:
>>>>
>>>> I want to let you know that I am currently working on the migration of
>>>> AOO 3.4.x/OOo 3.x user profiles to AOO 4.0. I am also including the
>>>> migration of extensions.
>>>> I am currently not planning to adjust any of the mentioned strings as I
>>>> think it is too late for its translation.
>>>
>>>
>>> Is this safe? In a typical scenario, then, a user would have some
>>> extensions installed and he would see them imported in 4.0 without being
>>> warned about possible compatibility problems. Most of the extensions do
>>> not have a maxversion indication, so OpenOffice 4.0 will try and install
>>> them anyway, but some might be broken. And then the user is left alone
>>> in updating his extensions (which in theory he should be prompted to do
>>> after installation, assuming this mechanism is restored), but he
>>> wouldn't have a way to go back before it's too late.
>>>
>>
>> I had a close look at the functionality to 'migrate the extensions from a
>> former user profile' and from my point of view we should give it a try.
>>
>> The function did the following:
>> It looks for the extensions which are installed for the user. These are
>> found in the former user profile. No shared-installed, bundled or
>> pre-registered extensions are considered. The found user-installed
>> extensions which are not on the blacklist are installed with the same
>> mechanism which is used when the users triggers in the installation.
>> I am activating an user interaction in case that an extension is already
>> installed - the same user interaction which is used when the user triggers
>> the installation of an already installed extension.
>>
>> On the blacklist will be the Presenter Screen and the Presentation Minimizer
>> as they are now integrated into OpenOffice.
>>
>
> Is the blacklist a static list? Or is it something that can be
> retried/updated from the website?
>
The blacklist is part of our source code. These are corresponding
entries in a XCU file - namely
main/officecfg/registry/data/org/openoffice/Setup.xcu
Have a look at my commit - revision 1494066 [1]. Search for
'ExcludedExtensions'
[1] http://svn.apache.org/r1494066
> If we can make the blacklist be "live" in a document that we can
> update, this is like maintaining our own max version field for the
> cases where the extension author neglected to do so.
>
Such a feature is possible.
It could be corresponding XML feed which OpenOffice could be accessed
via the Internet - like the XML feed for the update service.
Best regards, Oliver.
> -Rob
>
>
>>
>>
>>>> If my tests work fine, I will check-in the changes this week. If we will
>>>> include these changes into our AOO 4.0 release, I will help to update
>>>> the above wiki page.
>>>
>>>
>>> Let's keep them documented and see. Remember that we learned so far that
>>> a random user will manage to reinstall but not to do anything more
>>> elaborated, so if uninstallation/installation does not bring up a "Do
>>> you want to reset your profile?" dialog we still have a usability
>>> problem (which of course is not a regression, it's been there forever).
>>>
>>
>> Agreed.
>>
>>
>> Best regards, Oliver.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
>
>
> --
> Opinions expressed in this communication reflect the author's
> individual personal view, not necessarily that of an amorphous
> collective. The above statements do not reflect an official position
> of any organization, corporation, religion (organized or disorganized)
> or national football association. The contents of said note are not
> guaranteed to have been spell checked, grammar checked or reviewed for
> metrical infelicities. The contents of this post may not be suitable
> for those whose native language is not logic. Caution should be
> exercised when operating heavy machinery when reading this note, or
> even when not reading it. Seriously, heavy machinery is dangerous.
> Be careful.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Rob Weir <ro...@apache.org>.
On Tue, Jun 18, 2013 at 3:51 AM, Oliver-Rainer Wittmann
<or...@googlemail.com> wrote:
> Hi,
>
>
> On 18.06.2013 09:26, Andrea Pescetti wrote:
>>
>> On 17/06/2013 Oliver-Rainer Wittmann wrote:
>>>
>>> I want to let you know that I am currently working on the migration of
>>> AOO 3.4.x/OOo 3.x user profiles to AOO 4.0. I am also including the
>>> migration of extensions.
>>> I am currently not planning to adjust any of the mentioned strings as I
>>> think it is too late for its translation.
>>
>>
>> Is this safe? In a typical scenario, then, a user would have some
>> extensions installed and he would see them imported in 4.0 without being
>> warned about possible compatibility problems. Most of the extensions do
>> not have a maxversion indication, so OpenOffice 4.0 will try and install
>> them anyway, but some might be broken. And then the user is left alone
>> in updating his extensions (which in theory he should be prompted to do
>> after installation, assuming this mechanism is restored), but he
>> wouldn't have a way to go back before it's too late.
>>
>
> I had a close look at the functionality to 'migrate the extensions from a
> former user profile' and from my point of view we should give it a try.
>
> The function did the following:
> It looks for the extensions which are installed for the user. These are
> found in the former user profile. No shared-installed, bundled or
> pre-registered extensions are considered. The found user-installed
> extensions which are not on the blacklist are installed with the same
> mechanism which is used when the users triggers in the installation.
> I am activating an user interaction in case that an extension is already
> installed - the same user interaction which is used when the user triggers
> the installation of an already installed extension.
>
> On the blacklist will be the Presenter Screen and the Presentation Minimizer
> as they are now integrated into OpenOffice.
>
Is the blacklist a static list? Or is it something that can be
retried/updated from the website?
If we can make the blacklist be "live" in a document that we can
update, this is like maintaining our own max version field for the
cases where the extension author neglected to do so.
-Rob
>
>
>>> If my tests work fine, I will check-in the changes this week. If we will
>>> include these changes into our AOO 4.0 release, I will help to update
>>> the above wiki page.
>>
>>
>> Let's keep them documented and see. Remember that we learned so far that
>> a random user will manage to reinstall but not to do anything more
>> elaborated, so if uninstallation/installation does not bring up a "Do
>> you want to reset your profile?" dialog we still have a usability
>> problem (which of course is not a regression, it's been there forever).
>>
>
> Agreed.
>
>
> Best regards, Oliver.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
--
Opinions expressed in this communication reflect the author's
individual personal view, not necessarily that of an amorphous
collective. The above statements do not reflect an official position
of any organization, corporation, religion (organized or disorganized)
or national football association. The contents of said note are not
guaranteed to have been spell checked, grammar checked or reviewed for
metrical infelicities. The contents of this post may not be suitable
for those whose native language is not logic. Caution should be
exercised when operating heavy machinery when reading this note, or
even when not reading it. Seriously, heavy machinery is dangerous.
Be careful.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 18.06.2013 09:26, Andrea Pescetti wrote:
> On 17/06/2013 Oliver-Rainer Wittmann wrote:
>> I want to let you know that I am currently working on the migration of
>> AOO 3.4.x/OOo 3.x user profiles to AOO 4.0. I am also including the
>> migration of extensions.
>> I am currently not planning to adjust any of the mentioned strings as I
>> think it is too late for its translation.
>
> Is this safe? In a typical scenario, then, a user would have some
> extensions installed and he would see them imported in 4.0 without being
> warned about possible compatibility problems. Most of the extensions do
> not have a maxversion indication, so OpenOffice 4.0 will try and install
> them anyway, but some might be broken. And then the user is left alone
> in updating his extensions (which in theory he should be prompted to do
> after installation, assuming this mechanism is restored), but he
> wouldn't have a way to go back before it's too late.
>
I had a close look at the functionality to 'migrate the extensions from
a former user profile' and from my point of view we should give it a try.
The function did the following:
It looks for the extensions which are installed for the user. These are
found in the former user profile. No shared-installed, bundled or
pre-registered extensions are considered. The found user-installed
extensions which are not on the blacklist are installed with the same
mechanism which is used when the users triggers in the installation.
I am activating an user interaction in case that an extension is already
installed - the same user interaction which is used when the user
triggers the installation of an already installed extension.
On the blacklist will be the Presenter Screen and the Presentation
Minimizer as they are now integrated into OpenOffice.
>> If my tests work fine, I will check-in the changes this week. If we will
>> include these changes into our AOO 4.0 release, I will help to update
>> the above wiki page.
>
> Let's keep them documented and see. Remember that we learned so far that
> a random user will manage to reinstall but not to do anything more
> elaborated, so if uninstallation/installation does not bring up a "Do
> you want to reset your profile?" dialog we still have a usability
> problem (which of course is not a regression, it's been there forever).
>
Agreed.
Best regards, Oliver.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Hagar Delest <ha...@laposte.net>.
Le 18/06/2013 09:26, Andrea Pescetti a écrit :
> On 17/06/2013 Oliver-Rainer Wittmann wrote:
>> I want to let you know that I am currently working on the migration of
>> AOO 3.4.x/OOo 3.x user profiles to AOO 4.0. I am also including the
>> migration of extensions.
>> I am currently not planning to adjust any of the mentioned strings as I
>> think it is too late for its translation.
>
> Is this safe? In a typical scenario, then, a user would have some extensions installed and he would see them imported in 4.0 without being warned about possible compatibility problems. Most of the extensions do not have a maxversion indication, so OpenOffice 4.0 will try and install them anyway, but some might be broken. And then the user is left alone in updating his extensions (which in theory he should be prompted to do after installation, assuming this mechanism is restored), but he wouldn't have a way to go back before it's too late.
Even if it's not that safe, since the new user profile will not overwrite the former (it's a major upgrade), the only risk is that it doesn't work and to reset completely the new profile (but the former one is untouched and is kept available).
So we should at least try and hope that very few are broken.
Thanks Oliver for your work on the profile migration, it would be a great feature for a smooth upgrade.
Hagar
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Andrea Pescetti <pe...@apache.org>.
On 17/06/2013 Oliver-Rainer Wittmann wrote:
> I want to let you know that I am currently working on the migration of
> AOO 3.4.x/OOo 3.x user profiles to AOO 4.0. I am also including the
> migration of extensions.
> I am currently not planning to adjust any of the mentioned strings as I
> think it is too late for its translation.
Is this safe? In a typical scenario, then, a user would have some
extensions installed and he would see them imported in 4.0 without being
warned about possible compatibility problems. Most of the extensions do
not have a maxversion indication, so OpenOffice 4.0 will try and install
them anyway, but some might be broken. And then the user is left alone
in updating his extensions (which in theory he should be prompted to do
after installation, assuming this mechanism is restored), but he
wouldn't have a way to go back before it's too late.
> If my tests work fine, I will check-in the changes this week. If we will
> include these changes into our AOO 4.0 release, I will help to update
> the above wiki page.
Let's keep them documented and see. Remember that we learned so far that
a random user will manage to reinstall but not to do anything more
elaborated, so if uninstallation/installation does not bring up a "Do
you want to reset your profile?" dialog we still have a usability
problem (which of course is not a regression, it's been there forever).
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 13.06.2013 23:44, Andrea Pescetti wrote:
> On 05/06/2013 Hagar Delest wrote:
>> There has been a lot of posts in that discussion, even some proposals
>> but we are approaching the 4.0 release and I've not seen a single
>> warning for the extensions authors about the changes needed or any
>> proposal to warn users.
>
> I've started a wiki page at
>
> http://wiki.openoffice.org/wiki/Extensions/Extensions_and_Apache_OpenOffice_4.0
>
>
> It's still incomplete, and I hope that developers with knowledge may
> step in and fill in the gaps.
>
> It is meant to be a resource that we will want to advertise in the
> release notes and make available to users when they seek support, so
> please have a look, and feel free to improve and complete it.
>
I want to let you know that I am currently working on the migration of
AOO 3.4.x/OOo 3.x user profiles to AOO 4.0. I am also including the
migration of extensions.
I am currently not planning to adjust any of the mentioned strings as I
think it is too late for its translation.
If my tests work fine, I will check-in the changes this week. If we will
include these changes into our AOO 4.0 release, I will help to update
the above wiki page.
Best regards, Oliver.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Andrea Pescetti <pe...@apache.org>.
On 05/06/2013 Hagar Delest wrote:
> There has been a lot of posts in that discussion, even some proposals
> but we are approaching the 4.0 release and I've not seen a single
> warning for the extensions authors about the changes needed or any
> proposal to warn users.
I've started a wiki page at
http://wiki.openoffice.org/wiki/Extensions/Extensions_and_Apache_OpenOffice_4.0
It's still incomplete, and I hope that developers with knowledge may
step in and fill in the gaps.
It is meant to be a resource that we will want to advertise in the
release notes and make available to users when they seek support, so
please have a look, and feel free to improve and complete it.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Hagar Delest <ha...@laposte.net>.
Le 05/06/2013 15:25, Andre Fischer a écrit :
> I think that you are mixing up your arguments.
You may be right.
> - This thread seems to be a 'discussion' between developers---extensions developers and core developers---not between users and developers.
I know. I stepped in because of a reply that I see very often and that should be used rather carefully IMHO.
> - You imply that there are only two options: complain and then program an improvement or just shut up. But there are others. For example if you don't like the background color of a button then you don't have to be a programmer to propose another color. Constructive criticism can have many forms. Writing source code is just one of them.
There was a thread about the problem some time ago. I even was the one who launched it (after being criticized because I'd raised the problem in another topic, which was however related). There has been a lot of posts in that discussion, even some proposals but we are approaching the 4.0 release and I've not seen a single warning for the extensions authors about the changes needed or any proposal to warn users. I used "shut up" because the discussion went into limbos, nobody really cared. That's a way to dismiss one's comments and the underlying message is: "just do it or stop bothering us". And about this problem (extensions), I don't see what else can be done except coding, we are not talking about buttons color.
And again in this very discussion, the message is clear: don't complain, join the development team.
Perhaps you think it's just criticism but I think it's constructive criticism. That's more than 7 years that I visit the forums everyday and I know the users. I can easily guess what the level of frustration will be when users will notice that some of their extensions have been deactivated.
> So, if an extension developer criticizes a technical decision it seems reasonable to ask that developer to propose a better alternative. It does not have to be fully implemented but something a little more constructive than just a complaint would be nice. That, as far as I understand it, is one aspect of the Apache Way.
As said above, the topic has been raised 4 months ago. Alternative were proposed.
See: http://www.mail-archive.com/dev@openoffice.apache.org/msg04066.html
Hagar
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Andre Fischer <aw...@gmail.com>.
On 04.06.2013 23:28, Hagar Delest wrote:
> Le 04/06/2013 22:47, Juergen Schmidt a écrit :
>> Well I am getting tired to repeat this again and again. Nobody should
>> expect that others do what's necessary, Just do it yourself -> it's a
>> community project.
> That's the problem. It seems there are different levels of
> understanding for the "community".
>
> You tend to think that there is a huge community backing AOO and ready
> to jump into the code and other areas.
> I think that the reality is quite different: there is a huge base of
> users. But only users; wanting the application to work without having
> to put the hands inside.
>
>
> Let's face it: there are very few with dev skills; so you can't tell
> "just do it". What if we can't do it? Just shut up?
> If we shut up, nobody else will care about the users.
Hagar,
I think that you are mixing up your arguments.
- This thread seems to be a 'discussion' between developers---extensions
developers and core developers---not between users and developers.
- You imply that there are only two options: complain and then program
an improvement or just shut up. But there are others. For example if
you don't like the background color of a button then you don't have to
be a programmer to propose another color. Constructive criticism can
have many forms. Writing source code is just one of them.
So, if an extension developer criticizes a technical decision it seems
reasonable to ask that developer to propose a better alternative. It
does not have to be fully implemented but something a little more
constructive than just a complaint would be nice. That, as far as I
understand it, is one aspect of the Apache Way.
-Andre
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Hagar Delest <ha...@laposte.net>.
Le 04/06/2013 22:47, Juergen Schmidt a écrit :
> Well I am getting tired to repeat this again and again. Nobody should expect that others do what's necessary, Just do it yourself -> it's a community project.
That's the problem. It seems there are different levels of understanding for the "community".
You tend to think that there is a huge community backing AOO and ready to jump into the code and other areas.
I think that the reality is quite different: there is a huge base of users. But only users; wanting the application to work without having to put the hands inside.
Let's face it: there are very few with dev skills; so you can't tell "just do it". What if we can't do it? Just shut up?
If we shut up, nobody else will care about the users.
Hagar
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data
- help needed
Posted by Juergen Schmidt <jo...@gmail.com>.
Am Dienstag, 4. Juni 2013 um 22:00 schrieb Hagar Delest:
> Le 04/06/2013 20:27, Juergen Schmidt a écrit :
> > instead of complaining and requesting you could have joined the development and could have worked on one or more of your addressed issues. This is the way how open source works. The code is available and you can help to improve it.
>
>
> This is the standard reply of the devs community very often.
a reply to an extension developer
> Please remember that OpenOffice is a rather specific project with a user base made of basic users, not developers. This is not a toy for geeks who want to implement cool things. So if the users are really disappointed because they are not taken care of, they will just leave and go to LibreOffice for example.
>
>
you don't have to repeat this, I know it and we normally take all kind of feedback serious. It's simply that we have many things to do...
>
> Whatever the technical reason is, not taking into account the basic user aspect is dangerous. There were ideas about having a transition phase but nothing has really been made about that AFAIK.
some pro active collaboration of extension developers would be welcome. We don't simple ignore but we can't do everything.
>
>
>
>
> If voices like ours dare say so against the dev community, it's because we think that the users deserve a minimal care to keep them interested in the product. I doubt they would ever engage in such a discussion. So please don't forget about them, even if you don't hear their voices apart ours.
I agree and I expect the necessary collaboration from the extension developers. If they collaborate our users will be less affected.
>
> NB: has a communication been made to the extension authors asking them to update their extension with the detailed changes to be made?
> What is the idea for the moment? Hope that they will do that by themselves because they certainly monitor the dev mailing list?
>
>
I hope it will be addressed appropriately. I am not responsible for everything ;-)
The facts are known and if somebody things it is not addressed yet just start working on it and don't wait that somebody else does it.
Well I am getting tired to repeat this again and again. Nobody should expect that others do what's necessary, Just do it yourself -> it's a community project.
Juergen
>
> Hagar
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Andrea Pescetti <pe...@apache.org>.
Hagar Delest wrote:
> NB: has a communication been made to the extension authors asking them
> to update their extension with the detailed changes to be made?
> What is the idea for the moment? Hope that they will do that by
> themselves because they certainly monitor the dev mailing list?
This is very important and it shows that indeed there are tasks that can
only be done through cooperation.
Only a few people have clear ideas on what exactly is changing in
OpenOffice 4 regarding extensions: so, those with this knowledge, please
start a wiki page named "Upgrading your extensions for OpenOffice 4" or
something like that.
Then, once that page is started, other community members can take over,
point extensions authors to that page, we can ask to e-mail authors, we
can refer users to that page, some extension authors will comment and
improve the resource... but we need this to be started with something
that is more descriptive than a list of Bugzilla issues. Developers
needn't do everything, but the project needs them to start a
documentation effort that can then be managed by others.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Hagar Delest <ha...@laposte.net>.
Le 04/06/2013 20:27, Juergen Schmidt a écrit :
> instead of complaining and requesting you could have joined the development and could have worked on one or more of your addressed issues. This is the way how open source works. The code is available and you can help to improve it.
This is the standard reply of the devs community very often.
Please remember that OpenOffice is a rather specific project with a user base made of basic users, not developers. This is not a toy for geeks who want to implement cool things. So if the users are really disappointed because they are not taken care of, they will just leave and go to LibreOffice for example.
Whatever the technical reason is, not taking into account the basic user aspect is dangerous. There were ideas about having a transition phase but nothing has really been made about that AFAIK.
If voices like ours dare say so against the dev community, it's because we think that the users deserve a minimal care to keep them interested in the product. I doubt they would ever engage in such a discussion. So please don't forget about them, even if you don't hear their voices apart ours.
NB: has a communication been made to the extension authors asking them to update their extension with the detailed changes to be made?
What is the idea for the moment? Hope that they will do that by themselves because they certainly monitor the dev mailing list?
Hagar
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Posted by Hans Zybura <hz...@zybura.com>.
> From: Juergen Schmidt [mailto:jogischmidt@gmail.com]
> Sent: Tuesday, June 04, 2013 8:27 PM
> Am Dienstag, 4. Juni 2013 um 19:26 schrieb Hans Zybura:
> > Hi, comments inline...
> >
> > Crosspost to the api mailing list for a reason.
> >
> > Regards, Hans Zybura
> >
> > > From: Oliver-Rainer Wittmann [mailto:orwittmann@googlemail.com]
> > > Sent: Monday, June 03, 2013 10:47 AM
> > >
> > > Hi,
> > >
> > > small wrap-up at the top:
> > > - nobody prefers to migrate extensions from AOO 3.4.x resp. OOo 3.x
> > >
> >
> >
> > A couple of month ago there was a heated dispute about introducing
> incompatible changes for extensions in the addons.xcu (for negligible
> benefit). One of the arguments meant to silence the critics was: Well, it's no
> problem because we have an update mechanism for extensions. I expressed
> doubts if the update mechanism would work. Now it turns out I was wrong. I
> shouldn't have worried about the update mechanism. Without migration,
> users will have to find and reinstall all of their extensions anyway "by hand".
> >
> > The current update mechanism for extensions simply looks for a newer
> version of the extension by use of a link provided by the extension
> developer himself. We did that for our extension, but didn't have to make
> use of it until now.
> it is of course an open issue that the update mechanism for extensions from
> the repo doesn't work. We have to address this with our friends from
> sourgeforge.
I didn't speak about the repository. We don't rely on the repository, we are using our own server.
> >
> > OO developers decided not to take into account compatibility issues caused
> by introducing incompatible changes in addons.xcu. OK, so we have to deal
> with it. To prevent any trouble for our customers, we could very likely have
> provided an automatic update, so that an end user wouldn't have noticed
> any problem at all after a successful migration.
> the decision to do no migration of extension is based on the fact that we had
> problems with the user profile for AOO 3.4.x. We simply take this root to get
> a clean new profile for the future.
> >
> > Now OO developers are about to make it impossible for extension
> developers to simply provide an automatic update before or after the
> migration to AOO 4.0. Without migrating extensions, there is no automatic
> update path anymore.
> this is not optimal but a one time shot only
> >
> > Great user experience! Great experience for extension developers and
> support folks!
> no it isn't but sometimes unpopular decision are useful to move forward.
> And a major release is the chance for such changes.
> >
> >
> > I remember much talk about the "eco system of AOO" on this mailing list. Is
> this what the talk was about?
> instead of complaining and requesting you could have joined the
> development and could have worked on one or more of your addressed
> issues. This is the way how open source works. The code is available and you
> can help to improve it.
In my professional role as an extension developer I am perfectly able to deal with the consequences of your decisions, only that this doesn't make them any better.
I'm not complaining, I'm not requesting "that things get be done". Please stop using such a lame line of defense for your lack of leadership with respect to endorsing user friendliness. I'm just pointing out consequences for user experience and extension development. All I ever really did request was: Don't break things that work
Open source project or not, any kind of project needs leadership. Your position makes you a leader, but with respect to user friendliness you are not up to it.
Hans Zybura
>
> Juergen
> >
> > >
> > > more comments inline.
> > >
> > > On 02.06.2013 13:17, Andrea Pescetti wrote:
> > > > On 29/05/2013 Oliver-Rainer Wittmann wrote:
> > > > > On 28.05.2013 18:23, Rob Weir wrote:
> > > > > > Do we need to worry about the "messy" profiles that occurred
> > > > > > from OOo
> > > > > > 3.3.0 upgrades to AOO 3.4.0? That was when we saw spell
> > > > > > checking breaking, missing dictionaries, and crashes. One of
> > > > > > the nice things about a "clean start" with AOO 4.0 was that we
> > > > > > avoid these kinds of problems.
> > > > > >
> > > > >
> > > > > From my point of view AOO 3.4.x users which had problems due to
> > > > > a "messy" profile and had solved these problems, can migrate
> > > > > their profile to AOO 4.0. AOO 3.4.x users which does not had
> > > > > solved their problems are able to suppress the migration of
> > > > > their existing profile
> > > > > - see the corresponding FirstStartWizard page for the user
> > > > > profile
> > > > >
> > > >
> > > >
> > >
> > > migration.
> > > >
> > > > I agree with Rob here that, since we had only a few widely
> > > > reported bugs in OpenOffice 3.4.1 and one of them depended on the
> > > > profile migration, we should be rather conservative.
> > > >
> > > > I agree it's better not to migrate extensions, since some of them
> > > > might not work in OpenOffice 4 and their description.xml file in
> > > > most cases will only state that they need "OpenOffice 3.0 or later".
> > > >
> > > > > Yes, an easy reset of the user profile would be great.
> > > >
> > > > This would be a very welcome improvement. Maybe technically this
> > > > could invalidate the current profile and ask the user to restart
> > > > OpenOffice, which would start on a clean profile. This would offer
> > > > a good user experience (not optimal, since the optimal one would
> > > > be triggered by a reinstallation too), and the right moment for
> > > > the cleanup would be just after the code that checks if
> > > > FirstStartWizard must be run and just before the profile is loaded
> > > > and locked (which means that the "invalidate" bit must be set in a
> > > > way that does not require profile access but probably a simple
> filesystem access... OK, I'll stop here!).
> > > >
> > > > > Thus, I assume that the risk of a defect or a regression is low
> > > > > when solving issue 122398 and 122397 for AOO 4.0, except the
> > > > > issue which would be "copied" from a "messy" user profile.
> > > > >
> > > >
> > > >
> > > > This is a case to consider. So I would suggest to set the default
> > > > answer to "Don't migrate" for extra safety, especially if we don't
> > > > have an easy profile reset mechanism in place.
> > > >
> > >
> > >
> > > I agree.
> > > But it will cause translation effort - see screenshot of
> > > FirstStartWizard migration page [1] String "...If you do not want to
> > > reuse any settings in %PRODUCTNAME %PRODUCTVERSION, unmark the
> check
> > > box." will be change to "...If you do want to reuse settings in
> > > %PRODUCTNAME %PRODUCTVERSION, mark the check box."
> > >
> > > >
> > > > > Thus, send my your AOO 3.4.x or OOo 3.x user profile in a
> > > > > compressed form (.zip file or .tar.gz file or ...) or let me
> > > > > know, if you want to try my builds.
> > > > >
> > > >
> > > >
> > > > If you had a build available, it would be easier for the QA
> > > > volunteers to test.
> > > >
> > >
> > >
> > > Yes, that would be the best.
> > >
> > > I will make the changes on trunk. Then the buildbot builds and the
> > > snapshot builds can be tested.
> > > As all changes will contain the ID of the corresponding issue in the
> > > submit summary, it will be easy to revert these changes.
> > >
> > > [1] https://issues.apache.org/ooo/attachment.cgi?id=80738
> > >
> > >
> > > Best regards, Oliver.
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > > For additional commands, e-mail: dev-help@openoffice.apache.org
> > >
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data
- help needed
Posted by Juergen Schmidt <jo...@gmail.com>.
Am Dienstag, 4. Juni 2013 um 19:26 schrieb Hans Zybura:
> Hi, comments inline...
>
> Crosspost to the api mailing list for a reason.
>
> Regards, Hans Zybura
>
> > -----Original Message-----
> > From: Oliver-Rainer Wittmann [mailto:orwittmann@googlemail.com]
> > Sent: Monday, June 03, 2013 10:47 AM
> > To: dev@openoffice.apache.org
> > Subject: Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
> > help needed
> >
> > Hi,
> >
> > small wrap-up at the top:
> > - nobody prefers to migrate extensions from AOO 3.4.x resp. OOo 3.x
> >
>
>
> A couple of month ago there was a heated dispute about introducing incompatible changes for extensions in the addons.xcu (for negligible benefit). One of the arguments meant to silence the critics was: Well, it's no problem because we have an update mechanism for extensions. I expressed doubts if the update mechanism would work. Now it turns out I was wrong. I shouldn't have worried about the update mechanism. Without migration, users will have to find and reinstall all of their extensions anyway "by hand".
>
> The current update mechanism for extensions simply looks for a newer version of the extension by use of a link provided by the extension developer himself. We did that for our extension, but didn't have to make use of it until now.
it is of course an open issue that the update mechanism for extensions from the repo doesn't work. We have to address this with our friends from sourgeforge.
>
> OO developers decided not to take into account compatibility issues caused by introducing incompatible changes in addons.xcu. OK, so we have to deal with it. To prevent any trouble for our customers, we could very likely have provided an automatic update, so that an end user wouldn't have noticed any problem at all after a successful migration.
the decision to do no migration of extension is based on the fact that we had problems with the user profile for AOO 3.4.x. We simply take this root to get a clean new profile for the future.
>
> Now OO developers are about to make it impossible for extension developers to simply provide an automatic update before or after the migration to AOO 4.0. Without migrating extensions, there is no automatic update path anymore.
this is not optimal but a one time shot only
>
> Great user experience! Great experience for extension developers and support folks!
no it isn't but sometimes unpopular decision are useful to move forward. And a major release is the chance for such changes.
>
>
> I remember much talk about the "eco system of AOO" on this mailing list. Is this what the talk was about?
instead of complaining and requesting you could have joined the development and could have worked on one or more of your addressed issues. This is the way how open source works. The code is available and you can help to improve it.
Juergen
>
> >
> > more comments inline.
> >
> > On 02.06.2013 13:17, Andrea Pescetti wrote:
> > > On 29/05/2013 Oliver-Rainer Wittmann wrote:
> > > > On 28.05.2013 18:23, Rob Weir wrote:
> > > > > Do we need to worry about the "messy" profiles that occurred from
> > > > > OOo
> > > > > 3.3.0 upgrades to AOO 3.4.0? That was when we saw spell checking
> > > > > breaking, missing dictionaries, and crashes. One of the nice things
> > > > > about a "clean start" with AOO 4.0 was that we avoid these kinds of
> > > > > problems.
> > > > >
> > > >
> > > > From my point of view AOO 3.4.x users which had problems due to a
> > > > "messy" profile and had solved these problems, can migrate their
> > > > profile to AOO 4.0. AOO 3.4.x users which does not had solved their
> > > > problems are able to suppress the migration of their existing profile
> > > > - see the corresponding FirstStartWizard page for the user profile
> > > >
> > >
> > >
> >
> > migration.
> > >
> > > I agree with Rob here that, since we had only a few widely reported
> > > bugs in OpenOffice 3.4.1 and one of them depended on the profile
> > > migration, we should be rather conservative.
> > >
> > > I agree it's better not to migrate extensions, since some of them
> > > might not work in OpenOffice 4 and their description.xml file in most
> > > cases will only state that they need "OpenOffice 3.0 or later".
> > >
> > > > Yes, an easy reset of the user profile would be great.
> > >
> > > This would be a very welcome improvement. Maybe technically this could
> > > invalidate the current profile and ask the user to restart OpenOffice,
> > > which would start on a clean profile. This would offer a good user
> > > experience (not optimal, since the optimal one would be triggered by a
> > > reinstallation too), and the right moment for the cleanup would be
> > > just after the code that checks if FirstStartWizard must be run and
> > > just before the profile is loaded and locked (which means that the
> > > "invalidate" bit must be set in a way that does not require profile
> > > access but probably a simple filesystem access... OK, I'll stop here!).
> > >
> > > > Thus, I assume that the risk of a defect or a regression is low when
> > > > solving issue 122398 and 122397 for AOO 4.0, except the issue which
> > > > would be "copied" from a "messy" user profile.
> > > >
> > >
> > >
> > > This is a case to consider. So I would suggest to set the default
> > > answer to "Don't migrate" for extra safety, especially if we don't
> > > have an easy profile reset mechanism in place.
> > >
> >
> >
> > I agree.
> > But it will cause translation effort - see screenshot of FirstStartWizard
> > migration page [1] String "...If you do not want to reuse any settings in
> > %PRODUCTNAME %PRODUCTVERSION, unmark the check box." will be
> > change to "...If you do want to reuse settings in %PRODUCTNAME
> > %PRODUCTVERSION, mark the check box."
> >
> > >
> > > > Thus, send my your AOO 3.4.x or OOo 3.x user profile in a compressed
> > > > form (.zip file or .tar.gz file or ...) or let me know, if you want
> > > > to try my builds.
> > > >
> > >
> > >
> > > If you had a build available, it would be easier for the QA volunteers
> > > to test.
> > >
> >
> >
> > Yes, that would be the best.
> >
> > I will make the changes on trunk. Then the buildbot builds and the snapshot
> > builds can be tested.
> > As all changes will contain the ID of the corresponding issue in the submit
> > summary, it will be easy to revert these changes.
> >
> > [1] https://issues.apache.org/ooo/attachment.cgi?id=80738
> >
> >
> > Best regards, Oliver.
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> > For additional commands, e-mail: dev-help@openoffice.apache.org
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Roberto Galoppini <ro...@gmail.com>.
2013/6/4 Hans Zybura <hz...@zybura.com>:
> Hi, comments inline...
>
> Crosspost to the api mailing list for a reason.
>
> Regards, Hans Zybura
>
>> -----Original Message-----
>> From: Oliver-Rainer Wittmann [mailto:orwittmann@googlemail.com]
>> Sent: Monday, June 03, 2013 10:47 AM
>> To: dev@openoffice.apache.org
>> Subject: Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
>> help needed
>>
>> Hi,
>>
>> small wrap-up at the top:
>> - nobody prefers to migrate extensions from AOO 3.4.x resp. OOo 3.x
>
> A couple of month ago there was a heated dispute about introducing incompatible changes for extensions in the addons.xcu (for negligible benefit). One of the arguments meant to silence the critics was: Well, it's no problem because we have an update mechanism for extensions. I expressed doubts if the update mechanism would work. Now it turns out I was wrong. I shouldn't have worried about the update mechanism. Without migration, users will have to find and reinstall all of their extensions anyway "by hand".
>
> The current update mechanism for extensions simply looks for a newer version of the extension by use of a link provided by the extension developer himself. We did that for our extension, but didn't have to make use of it until now.
>
> OO developers decided not to take into account compatibility issues caused by introducing incompatible changes in addons.xcu. OK, so we have to deal with it. To prevent any trouble for our customers, we could very likely have provided an automatic update, so that an end user wouldn't have noticed any problem at all after a successful migration.
>
> Now OO developers are about to make it impossible for extension developers to simply provide an automatic update before or after the migration to AOO 4.0. Without migrating extensions, there is no automatic update path anymore.
AOOE beta-test site has already the update feature in place, we plan
to go live with the beta test sometimes next week, so that we'll have
a couple of weeks to test it extensively before AOO 4.0.
Hope this helps.
Roberto
> Great user experience! Great experience for extension developers and support folks!
>
> I remember much talk about the "eco system of AOO" on this mailing list. Is this what the talk was about?
>
>>
>> more comments inline.
>>
>> On 02.06.2013 13:17, Andrea Pescetti wrote:
>> > On 29/05/2013 Oliver-Rainer Wittmann wrote:
>> >> On 28.05.2013 18:23, Rob Weir wrote:
>> >>> Do we need to worry about the "messy" profiles that occurred from
>> >>> OOo
>> >>> 3.3.0 upgrades to AOO 3.4.0? That was when we saw spell checking
>> >>> breaking, missing dictionaries, and crashes. One of the nice things
>> >>> about a "clean start" with AOO 4.0 was that we avoid these kinds of
>> >>> problems.
>> >> From my point of view AOO 3.4.x users which had problems due to a
>> >> "messy" profile and had solved these problems, can migrate their
>> >> profile to AOO 4.0. AOO 3.4.x users which does not had solved their
>> >> problems are able to suppress the migration of their existing profile
>> >> - see the corresponding FirstStartWizard page for the user profile
>> migration.
>> >
>> > I agree with Rob here that, since we had only a few widely reported
>> > bugs in OpenOffice 3.4.1 and one of them depended on the profile
>> > migration, we should be rather conservative.
>> >
>> > I agree it's better not to migrate extensions, since some of them
>> > might not work in OpenOffice 4 and their description.xml file in most
>> > cases will only state that they need "OpenOffice 3.0 or later".
>> >
>> >> Yes, an easy reset of the user profile would be great.
>> >
>> > This would be a very welcome improvement. Maybe technically this could
>> > invalidate the current profile and ask the user to restart OpenOffice,
>> > which would start on a clean profile. This would offer a good user
>> > experience (not optimal, since the optimal one would be triggered by a
>> > reinstallation too), and the right moment for the cleanup would be
>> > just after the code that checks if FirstStartWizard must be run and
>> > just before the profile is loaded and locked (which means that the
>> > "invalidate" bit must be set in a way that does not require profile
>> > access but probably a simple filesystem access... OK, I'll stop here!).
>> >
>> >> Thus, I assume that the risk of a defect or a regression is low when
>> >> solving issue 122398 and 122397 for AOO 4.0, except the issue which
>> >> would be "copied" from a "messy" user profile.
>> >
>> > This is a case to consider. So I would suggest to set the default
>> > answer to "Don't migrate" for extra safety, especially if we don't
>> > have an easy profile reset mechanism in place.
>>
>> I agree.
>> But it will cause translation effort - see screenshot of FirstStartWizard
>> migration page [1] String "...If you do not want to reuse any settings in
>> %PRODUCTNAME %PRODUCTVERSION, unmark the check box." will be
>> change to "...If you do want to reuse settings in %PRODUCTNAME
>> %PRODUCTVERSION, mark the check box."
>>
>> >
>> >> Thus, send my your AOO 3.4.x or OOo 3.x user profile in a compressed
>> >> form (.zip file or .tar.gz file or ...) or let me know, if you want
>> >> to try my builds.
>> >
>> > If you had a build available, it would be easier for the QA volunteers
>> > to test.
>> >
>>
>> Yes, that would be the best.
>>
>> I will make the changes on trunk. Then the buildbot builds and the snapshot
>> builds can be tested.
>> As all changes will contain the ID of the corresponding issue in the submit
>> summary, it will be easy to revert these changes.
>>
>> [1] https://issues.apache.org/ooo/attachment.cgi?id=80738
>>
>>
>> Best regards, Oliver.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Roberto Galoppini <ro...@gmail.com>.
2013/6/4 Hans Zybura <hz...@zybura.com>:
> Hi, comments inline...
>
> Crosspost to the api mailing list for a reason.
>
> Regards, Hans Zybura
>
>> -----Original Message-----
>> From: Oliver-Rainer Wittmann [mailto:orwittmann@googlemail.com]
>> Sent: Monday, June 03, 2013 10:47 AM
>> To: dev@openoffice.apache.org
>> Subject: Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
>> help needed
>>
>> Hi,
>>
>> small wrap-up at the top:
>> - nobody prefers to migrate extensions from AOO 3.4.x resp. OOo 3.x
>
> A couple of month ago there was a heated dispute about introducing incompatible changes for extensions in the addons.xcu (for negligible benefit). One of the arguments meant to silence the critics was: Well, it's no problem because we have an update mechanism for extensions. I expressed doubts if the update mechanism would work. Now it turns out I was wrong. I shouldn't have worried about the update mechanism. Without migration, users will have to find and reinstall all of their extensions anyway "by hand".
>
> The current update mechanism for extensions simply looks for a newer version of the extension by use of a link provided by the extension developer himself. We did that for our extension, but didn't have to make use of it until now.
>
> OO developers decided not to take into account compatibility issues caused by introducing incompatible changes in addons.xcu. OK, so we have to deal with it. To prevent any trouble for our customers, we could very likely have provided an automatic update, so that an end user wouldn't have noticed any problem at all after a successful migration.
>
> Now OO developers are about to make it impossible for extension developers to simply provide an automatic update before or after the migration to AOO 4.0. Without migrating extensions, there is no automatic update path anymore.
AOOE beta-test site has already the update feature in place, we plan
to go live with the beta test sometimes next week, so that we'll have
a couple of weeks to test it extensively before AOO 4.0.
Hope this helps.
Roberto
> Great user experience! Great experience for extension developers and support folks!
>
> I remember much talk about the "eco system of AOO" on this mailing list. Is this what the talk was about?
>
>>
>> more comments inline.
>>
>> On 02.06.2013 13:17, Andrea Pescetti wrote:
>> > On 29/05/2013 Oliver-Rainer Wittmann wrote:
>> >> On 28.05.2013 18:23, Rob Weir wrote:
>> >>> Do we need to worry about the "messy" profiles that occurred from
>> >>> OOo
>> >>> 3.3.0 upgrades to AOO 3.4.0? That was when we saw spell checking
>> >>> breaking, missing dictionaries, and crashes. One of the nice things
>> >>> about a "clean start" with AOO 4.0 was that we avoid these kinds of
>> >>> problems.
>> >> From my point of view AOO 3.4.x users which had problems due to a
>> >> "messy" profile and had solved these problems, can migrate their
>> >> profile to AOO 4.0. AOO 3.4.x users which does not had solved their
>> >> problems are able to suppress the migration of their existing profile
>> >> - see the corresponding FirstStartWizard page for the user profile
>> migration.
>> >
>> > I agree with Rob here that, since we had only a few widely reported
>> > bugs in OpenOffice 3.4.1 and one of them depended on the profile
>> > migration, we should be rather conservative.
>> >
>> > I agree it's better not to migrate extensions, since some of them
>> > might not work in OpenOffice 4 and their description.xml file in most
>> > cases will only state that they need "OpenOffice 3.0 or later".
>> >
>> >> Yes, an easy reset of the user profile would be great.
>> >
>> > This would be a very welcome improvement. Maybe technically this could
>> > invalidate the current profile and ask the user to restart OpenOffice,
>> > which would start on a clean profile. This would offer a good user
>> > experience (not optimal, since the optimal one would be triggered by a
>> > reinstallation too), and the right moment for the cleanup would be
>> > just after the code that checks if FirstStartWizard must be run and
>> > just before the profile is loaded and locked (which means that the
>> > "invalidate" bit must be set in a way that does not require profile
>> > access but probably a simple filesystem access... OK, I'll stop here!).
>> >
>> >> Thus, I assume that the risk of a defect or a regression is low when
>> >> solving issue 122398 and 122397 for AOO 4.0, except the issue which
>> >> would be "copied" from a "messy" user profile.
>> >
>> > This is a case to consider. So I would suggest to set the default
>> > answer to "Don't migrate" for extra safety, especially if we don't
>> > have an easy profile reset mechanism in place.
>>
>> I agree.
>> But it will cause translation effort - see screenshot of FirstStartWizard
>> migration page [1] String "...If you do not want to reuse any settings in
>> %PRODUCTNAME %PRODUCTVERSION, unmark the check box." will be
>> change to "...If you do want to reuse settings in %PRODUCTNAME
>> %PRODUCTVERSION, mark the check box."
>>
>> >
>> >> Thus, send my your AOO 3.4.x or OOo 3.x user profile in a compressed
>> >> form (.zip file or .tar.gz file or ...) or let me know, if you want
>> >> to try my builds.
>> >
>> > If you had a build available, it would be easier for the QA volunteers
>> > to test.
>> >
>>
>> Yes, that would be the best.
>>
>> I will make the changes on trunk. Then the buildbot builds and the snapshot
>> builds can be tested.
>> As all changes will contain the ID of the corresponding issue in the submit
>> summary, it will be easy to revert these changes.
>>
>> [1] https://issues.apache.org/ooo/attachment.cgi?id=80738
>>
>>
>> Best regards, Oliver.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
For additional commands, e-mail: api-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi Hans Zybura,
On 04.06.2013 19:26, Hans Zybura wrote:
> Hi, comments inline...
>
> Crosspost to the api mailing list for a reason.
>
> Regards, Hans Zybura
>
>> -----Original Message----- From: Oliver-Rainer Wittmann
>> [mailto:orwittmann@googlemail.com] Sent: Monday, June 03, 2013
>> 10:47 AM To: dev@openoffice.apache.org Subject: Re: [AOO 4.0]:
>> migration of AOO 3.4.x/OOo 3.x user profile data - help needed
>>
>> Hi,
>>
>> small wrap-up at the top: - nobody prefers to migrate extensions
>> from AOO 3.4.x resp. OOo 3.x
>
> A couple of month ago there was a heated dispute about introducing
> incompatible changes for extensions in the addons.xcu (for negligible
> benefit). One of the arguments meant to silence the critics was:
> Well, it's no problem because we have an update mechanism for
> extensions. I expressed doubts if the update mechanism would work.
> Now it turns out I was wrong. I shouldn't have worried about the
> update mechanism. Without migration, users will have to find and
> reinstall all of their extensions anyway "by hand".
>
May be I should have said:
"Until now, nobody prefers to migrate extensions from AOO 3.4.x resp.
OOo 3.x".
> The current update mechanism for extensions simply looks for a newer
> version of the extension by use of a link provided by the extension
> developer himself. We did that for our extension, but didn't have to
> make use of it until now.
>
> OO developers decided not to take into account compatibility issues
> caused by introducing incompatible changes in addons.xcu. OK, so we
> have to deal with it. To prevent any trouble for our customers, we
> could very likely have provided an automatic update, so that an end
> user wouldn't have noticed any problem at all after a successful
> migration.
>
> Now OO developers are about to make it impossible for extension
> developers to simply provide an automatic update before or after the
> migration to AOO 4.0. Without migrating extensions, there is no
> automatic update path anymore.
>
> Great user experience! Great experience for extension developers and
> support folks!
>
> I remember much talk about the "eco system of AOO" on this mailing
> list. Is this what the talk was about?
>
I tried to get involved certain people on this topic.
I had send my intial post to dev@o.a.o and users@o.a.o. Sorry, that I
did not include api@o.a.o as I assumed that extension developers are
looking at dev@o.a.o.
The intention of this thread was not to present facts regarding the
development. It is meant to show on what I would like to work on for AOO
4.0 regarding the migration of the user profile and to get feedback on
it. (BTW, I had already started a discussion thread in January 2013
regarding the migration of the user profile - see thread "[IMPORTANT,
DISCUSS]: no migration/use of former user profile with AOO 4.0".)
I used terms like "I would like to ...", "My current preference is ..."
and "I need support and help ..." - I am not presenting facts.
I explicitly ask for help for these tasks.
I got no response and no feedback from users@o.a.o. I was disappointed
about it, because it means that nobody from users@o.a.o seems to be
interested to help/support me. From dev@o.a.o I only got feedback about
the risks of a user profile migration and that nobody prefers a
migration of the extensions.
I have taken your feedback as not constructive criticsm. Your feedback
sounds like that I decided that extensions will not be migrated. That is
not the case.
Earlier in January I already started a similar discussion - see above
mentioned thread. Here, no strong preferences regarding the migration of
extensions were given.
In this thread I expressed my willingness to work on the migration of
the user profile (which also contains the user installed extensions),
otherwise nothing will be migrated as stated in January. As this is not
a one-person show I asked for help and support. The only feedback I got
was that a migration might be risky and no one has preference to migrate
extensions.
Then I got your feedback which more or less killed my motivation to work
on the migration of the user profile.
May be you are volunteering to support me as you seem to be interested
in a working migration of the user profile?
Best regards, (a disappointed) Oliver.
>>
>> more comments inline.
>>
>> On 02.06.2013 13:17, Andrea Pescetti wrote:
>>> On 29/05/2013 Oliver-Rainer Wittmann wrote:
>>>> On 28.05.2013 18:23, Rob Weir wrote:
>>>>> Do we need to worry about the "messy" profiles that occurred
>>>>> from OOo 3.3.0 upgrades to AOO 3.4.0? That was when we saw
>>>>> spell checking breaking, missing dictionaries, and crashes.
>>>>> One of the nice things about a "clean start" with AOO 4.0 was
>>>>> that we avoid these kinds of problems.
>>>> From my point of view AOO 3.4.x users which had problems due to
>>>> a "messy" profile and had solved these problems, can migrate
>>>> their profile to AOO 4.0. AOO 3.4.x users which does not had
>>>> solved their problems are able to suppress the migration of
>>>> their existing profile - see the corresponding FirstStartWizard
>>>> page for the user profile
>> migration.
>>>
>>> I agree with Rob here that, since we had only a few widely
>>> reported bugs in OpenOffice 3.4.1 and one of them depended on the
>>> profile migration, we should be rather conservative.
>>>
>>> I agree it's better not to migrate extensions, since some of
>>> them might not work in OpenOffice 4 and their description.xml
>>> file in most cases will only state that they need "OpenOffice 3.0
>>> or later".
>>>
>>>> Yes, an easy reset of the user profile would be great.
>>>
>>> This would be a very welcome improvement. Maybe technically this
>>> could invalidate the current profile and ask the user to restart
>>> OpenOffice, which would start on a clean profile. This would
>>> offer a good user experience (not optimal, since the optimal one
>>> would be triggered by a reinstallation too), and the right moment
>>> for the cleanup would be just after the code that checks if
>>> FirstStartWizard must be run and just before the profile is
>>> loaded and locked (which means that the "invalidate" bit must be
>>> set in a way that does not require profile access but probably a
>>> simple filesystem access... OK, I'll stop here!).
>>>
>>>> Thus, I assume that the risk of a defect or a regression is low
>>>> when solving issue 122398 and 122397 for AOO 4.0, except the
>>>> issue which would be "copied" from a "messy" user profile.
>>>
>>> This is a case to consider. So I would suggest to set the
>>> default answer to "Don't migrate" for extra safety, especially if
>>> we don't have an easy profile reset mechanism in place.
>>
>> I agree. But it will cause translation effort - see screenshot of
>> FirstStartWizard migration page [1] String "...If you do not want
>> to reuse any settings in %PRODUCTNAME %PRODUCTVERSION, unmark the
>> check box." will be change to "...If you do want to reuse settings
>> in %PRODUCTNAME %PRODUCTVERSION, mark the check box."
>>
>>>
>>>> Thus, send my your AOO 3.4.x or OOo 3.x user profile in a
>>>> compressed form (.zip file or .tar.gz file or ...) or let me
>>>> know, if you want to try my builds.
>>>
>>> If you had a build available, it would be easier for the QA
>>> volunteers to test.
>>>
>>
>> Yes, that would be the best.
>>
>> I will make the changes on trunk. Then the buildbot builds and the
>> snapshot builds can be tested. As all changes will contain the ID
>> of the corresponding issue in the submit summary, it will be easy
>> to revert these changes.
>>
>> [1] https://issues.apache.org/ooo/attachment.cgi?id=80738
>>
>>
>> Best regards, Oliver.
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi Hans Zybura,
On 04.06.2013 19:26, Hans Zybura wrote:
> Hi, comments inline...
>
> Crosspost to the api mailing list for a reason.
>
> Regards, Hans Zybura
>
>> -----Original Message----- From: Oliver-Rainer Wittmann
>> [mailto:orwittmann@googlemail.com] Sent: Monday, June 03, 2013
>> 10:47 AM To: dev@openoffice.apache.org Subject: Re: [AOO 4.0]:
>> migration of AOO 3.4.x/OOo 3.x user profile data - help needed
>>
>> Hi,
>>
>> small wrap-up at the top: - nobody prefers to migrate extensions
>> from AOO 3.4.x resp. OOo 3.x
>
> A couple of month ago there was a heated dispute about introducing
> incompatible changes for extensions in the addons.xcu (for negligible
> benefit). One of the arguments meant to silence the critics was:
> Well, it's no problem because we have an update mechanism for
> extensions. I expressed doubts if the update mechanism would work.
> Now it turns out I was wrong. I shouldn't have worried about the
> update mechanism. Without migration, users will have to find and
> reinstall all of their extensions anyway "by hand".
>
May be I should have said:
"Until now, nobody prefers to migrate extensions from AOO 3.4.x resp.
OOo 3.x".
> The current update mechanism for extensions simply looks for a newer
> version of the extension by use of a link provided by the extension
> developer himself. We did that for our extension, but didn't have to
> make use of it until now.
>
> OO developers decided not to take into account compatibility issues
> caused by introducing incompatible changes in addons.xcu. OK, so we
> have to deal with it. To prevent any trouble for our customers, we
> could very likely have provided an automatic update, so that an end
> user wouldn't have noticed any problem at all after a successful
> migration.
>
> Now OO developers are about to make it impossible for extension
> developers to simply provide an automatic update before or after the
> migration to AOO 4.0. Without migrating extensions, there is no
> automatic update path anymore.
>
> Great user experience! Great experience for extension developers and
> support folks!
>
> I remember much talk about the "eco system of AOO" on this mailing
> list. Is this what the talk was about?
>
I tried to get involved certain people on this topic.
I had send my intial post to dev@o.a.o and users@o.a.o. Sorry, that I
did not include api@o.a.o as I assumed that extension developers are
looking at dev@o.a.o.
The intention of this thread was not to present facts regarding the
development. It is meant to show on what I would like to work on for AOO
4.0 regarding the migration of the user profile and to get feedback on
it. (BTW, I had already started a discussion thread in January 2013
regarding the migration of the user profile - see thread "[IMPORTANT,
DISCUSS]: no migration/use of former user profile with AOO 4.0".)
I used terms like "I would like to ...", "My current preference is ..."
and "I need support and help ..." - I am not presenting facts.
I explicitly ask for help for these tasks.
I got no response and no feedback from users@o.a.o. I was disappointed
about it, because it means that nobody from users@o.a.o seems to be
interested to help/support me. From dev@o.a.o I only got feedback about
the risks of a user profile migration and that nobody prefers a
migration of the extensions.
I have taken your feedback as not constructive criticsm. Your feedback
sounds like that I decided that extensions will not be migrated. That is
not the case.
Earlier in January I already started a similar discussion - see above
mentioned thread. Here, no strong preferences regarding the migration of
extensions were given.
In this thread I expressed my willingness to work on the migration of
the user profile (which also contains the user installed extensions),
otherwise nothing will be migrated as stated in January. As this is not
a one-person show I asked for help and support. The only feedback I got
was that a migration might be risky and no one has preference to migrate
extensions.
Then I got your feedback which more or less killed my motivation to work
on the migration of the user profile.
May be you are volunteering to support me as you seem to be interested
in a working migration of the user profile?
Best regards, (a disappointed) Oliver.
>>
>> more comments inline.
>>
>> On 02.06.2013 13:17, Andrea Pescetti wrote:
>>> On 29/05/2013 Oliver-Rainer Wittmann wrote:
>>>> On 28.05.2013 18:23, Rob Weir wrote:
>>>>> Do we need to worry about the "messy" profiles that occurred
>>>>> from OOo 3.3.0 upgrades to AOO 3.4.0? That was when we saw
>>>>> spell checking breaking, missing dictionaries, and crashes.
>>>>> One of the nice things about a "clean start" with AOO 4.0 was
>>>>> that we avoid these kinds of problems.
>>>> From my point of view AOO 3.4.x users which had problems due to
>>>> a "messy" profile and had solved these problems, can migrate
>>>> their profile to AOO 4.0. AOO 3.4.x users which does not had
>>>> solved their problems are able to suppress the migration of
>>>> their existing profile - see the corresponding FirstStartWizard
>>>> page for the user profile
>> migration.
>>>
>>> I agree with Rob here that, since we had only a few widely
>>> reported bugs in OpenOffice 3.4.1 and one of them depended on the
>>> profile migration, we should be rather conservative.
>>>
>>> I agree it's better not to migrate extensions, since some of
>>> them might not work in OpenOffice 4 and their description.xml
>>> file in most cases will only state that they need "OpenOffice 3.0
>>> or later".
>>>
>>>> Yes, an easy reset of the user profile would be great.
>>>
>>> This would be a very welcome improvement. Maybe technically this
>>> could invalidate the current profile and ask the user to restart
>>> OpenOffice, which would start on a clean profile. This would
>>> offer a good user experience (not optimal, since the optimal one
>>> would be triggered by a reinstallation too), and the right moment
>>> for the cleanup would be just after the code that checks if
>>> FirstStartWizard must be run and just before the profile is
>>> loaded and locked (which means that the "invalidate" bit must be
>>> set in a way that does not require profile access but probably a
>>> simple filesystem access... OK, I'll stop here!).
>>>
>>>> Thus, I assume that the risk of a defect or a regression is low
>>>> when solving issue 122398 and 122397 for AOO 4.0, except the
>>>> issue which would be "copied" from a "messy" user profile.
>>>
>>> This is a case to consider. So I would suggest to set the
>>> default answer to "Don't migrate" for extra safety, especially if
>>> we don't have an easy profile reset mechanism in place.
>>
>> I agree. But it will cause translation effort - see screenshot of
>> FirstStartWizard migration page [1] String "...If you do not want
>> to reuse any settings in %PRODUCTNAME %PRODUCTVERSION, unmark the
>> check box." will be change to "...If you do want to reuse settings
>> in %PRODUCTNAME %PRODUCTVERSION, mark the check box."
>>
>>>
>>>> Thus, send my your AOO 3.4.x or OOo 3.x user profile in a
>>>> compressed form (.zip file or .tar.gz file or ...) or let me
>>>> know, if you want to try my builds.
>>>
>>> If you had a build available, it would be easier for the QA
>>> volunteers to test.
>>>
>>
>> Yes, that would be the best.
>>
>> I will make the changes on trunk. Then the buildbot builds and the
>> snapshot builds can be tested. As all changes will contain the ID
>> of the corresponding issue in the submit summary, it will be easy
>> to revert these changes.
>>
>> [1] https://issues.apache.org/ooo/attachment.cgi?id=80738
>>
>>
>> Best regards, Oliver.
>>
>> ---------------------------------------------------------------------
>>
>>
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>
>
> ---------------------------------------------------------------------
>
>
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
For additional commands, e-mail: api-help@openoffice.apache.org
RE: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Posted by Hans Zybura <hz...@zybura.com>.
Hi, comments inline...
Crosspost to the api mailing list for a reason.
Regards, Hans Zybura
> -----Original Message-----
> From: Oliver-Rainer Wittmann [mailto:orwittmann@googlemail.com]
> Sent: Monday, June 03, 2013 10:47 AM
> To: dev@openoffice.apache.org
> Subject: Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
> help needed
>
> Hi,
>
> small wrap-up at the top:
> - nobody prefers to migrate extensions from AOO 3.4.x resp. OOo 3.x
A couple of month ago there was a heated dispute about introducing incompatible changes for extensions in the addons.xcu (for negligible benefit). One of the arguments meant to silence the critics was: Well, it's no problem because we have an update mechanism for extensions. I expressed doubts if the update mechanism would work. Now it turns out I was wrong. I shouldn't have worried about the update mechanism. Without migration, users will have to find and reinstall all of their extensions anyway "by hand".
The current update mechanism for extensions simply looks for a newer version of the extension by use of a link provided by the extension developer himself. We did that for our extension, but didn't have to make use of it until now.
OO developers decided not to take into account compatibility issues caused by introducing incompatible changes in addons.xcu. OK, so we have to deal with it. To prevent any trouble for our customers, we could very likely have provided an automatic update, so that an end user wouldn't have noticed any problem at all after a successful migration.
Now OO developers are about to make it impossible for extension developers to simply provide an automatic update before or after the migration to AOO 4.0. Without migrating extensions, there is no automatic update path anymore.
Great user experience! Great experience for extension developers and support folks!
I remember much talk about the "eco system of AOO" on this mailing list. Is this what the talk was about?
>
> more comments inline.
>
> On 02.06.2013 13:17, Andrea Pescetti wrote:
> > On 29/05/2013 Oliver-Rainer Wittmann wrote:
> >> On 28.05.2013 18:23, Rob Weir wrote:
> >>> Do we need to worry about the "messy" profiles that occurred from
> >>> OOo
> >>> 3.3.0 upgrades to AOO 3.4.0? That was when we saw spell checking
> >>> breaking, missing dictionaries, and crashes. One of the nice things
> >>> about a "clean start" with AOO 4.0 was that we avoid these kinds of
> >>> problems.
> >> From my point of view AOO 3.4.x users which had problems due to a
> >> "messy" profile and had solved these problems, can migrate their
> >> profile to AOO 4.0. AOO 3.4.x users which does not had solved their
> >> problems are able to suppress the migration of their existing profile
> >> - see the corresponding FirstStartWizard page for the user profile
> migration.
> >
> > I agree with Rob here that, since we had only a few widely reported
> > bugs in OpenOffice 3.4.1 and one of them depended on the profile
> > migration, we should be rather conservative.
> >
> > I agree it's better not to migrate extensions, since some of them
> > might not work in OpenOffice 4 and their description.xml file in most
> > cases will only state that they need "OpenOffice 3.0 or later".
> >
> >> Yes, an easy reset of the user profile would be great.
> >
> > This would be a very welcome improvement. Maybe technically this could
> > invalidate the current profile and ask the user to restart OpenOffice,
> > which would start on a clean profile. This would offer a good user
> > experience (not optimal, since the optimal one would be triggered by a
> > reinstallation too), and the right moment for the cleanup would be
> > just after the code that checks if FirstStartWizard must be run and
> > just before the profile is loaded and locked (which means that the
> > "invalidate" bit must be set in a way that does not require profile
> > access but probably a simple filesystem access... OK, I'll stop here!).
> >
> >> Thus, I assume that the risk of a defect or a regression is low when
> >> solving issue 122398 and 122397 for AOO 4.0, except the issue which
> >> would be "copied" from a "messy" user profile.
> >
> > This is a case to consider. So I would suggest to set the default
> > answer to "Don't migrate" for extra safety, especially if we don't
> > have an easy profile reset mechanism in place.
>
> I agree.
> But it will cause translation effort - see screenshot of FirstStartWizard
> migration page [1] String "...If you do not want to reuse any settings in
> %PRODUCTNAME %PRODUCTVERSION, unmark the check box." will be
> change to "...If you do want to reuse settings in %PRODUCTNAME
> %PRODUCTVERSION, mark the check box."
>
> >
> >> Thus, send my your AOO 3.4.x or OOo 3.x user profile in a compressed
> >> form (.zip file or .tar.gz file or ...) or let me know, if you want
> >> to try my builds.
> >
> > If you had a build available, it would be easier for the QA volunteers
> > to test.
> >
>
> Yes, that would be the best.
>
> I will make the changes on trunk. Then the buildbot builds and the snapshot
> builds can be tested.
> As all changes will contain the ID of the corresponding issue in the submit
> summary, it will be easy to revert these changes.
>
> [1] https://issues.apache.org/ooo/attachment.cgi?id=80738
>
>
> Best regards, Oliver.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Posted by Hans Zybura <hz...@zybura.com>.
Hi, comments inline...
Crosspost to the api mailing list for a reason.
Regards, Hans Zybura
> -----Original Message-----
> From: Oliver-Rainer Wittmann [mailto:orwittmann@googlemail.com]
> Sent: Monday, June 03, 2013 10:47 AM
> To: dev@openoffice.apache.org
> Subject: Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
> help needed
>
> Hi,
>
> small wrap-up at the top:
> - nobody prefers to migrate extensions from AOO 3.4.x resp. OOo 3.x
A couple of month ago there was a heated dispute about introducing incompatible changes for extensions in the addons.xcu (for negligible benefit). One of the arguments meant to silence the critics was: Well, it's no problem because we have an update mechanism for extensions. I expressed doubts if the update mechanism would work. Now it turns out I was wrong. I shouldn't have worried about the update mechanism. Without migration, users will have to find and reinstall all of their extensions anyway "by hand".
The current update mechanism for extensions simply looks for a newer version of the extension by use of a link provided by the extension developer himself. We did that for our extension, but didn't have to make use of it until now.
OO developers decided not to take into account compatibility issues caused by introducing incompatible changes in addons.xcu. OK, so we have to deal with it. To prevent any trouble for our customers, we could very likely have provided an automatic update, so that an end user wouldn't have noticed any problem at all after a successful migration.
Now OO developers are about to make it impossible for extension developers to simply provide an automatic update before or after the migration to AOO 4.0. Without migrating extensions, there is no automatic update path anymore.
Great user experience! Great experience for extension developers and support folks!
I remember much talk about the "eco system of AOO" on this mailing list. Is this what the talk was about?
>
> more comments inline.
>
> On 02.06.2013 13:17, Andrea Pescetti wrote:
> > On 29/05/2013 Oliver-Rainer Wittmann wrote:
> >> On 28.05.2013 18:23, Rob Weir wrote:
> >>> Do we need to worry about the "messy" profiles that occurred from
> >>> OOo
> >>> 3.3.0 upgrades to AOO 3.4.0? That was when we saw spell checking
> >>> breaking, missing dictionaries, and crashes. One of the nice things
> >>> about a "clean start" with AOO 4.0 was that we avoid these kinds of
> >>> problems.
> >> From my point of view AOO 3.4.x users which had problems due to a
> >> "messy" profile and had solved these problems, can migrate their
> >> profile to AOO 4.0. AOO 3.4.x users which does not had solved their
> >> problems are able to suppress the migration of their existing profile
> >> - see the corresponding FirstStartWizard page for the user profile
> migration.
> >
> > I agree with Rob here that, since we had only a few widely reported
> > bugs in OpenOffice 3.4.1 and one of them depended on the profile
> > migration, we should be rather conservative.
> >
> > I agree it's better not to migrate extensions, since some of them
> > might not work in OpenOffice 4 and their description.xml file in most
> > cases will only state that they need "OpenOffice 3.0 or later".
> >
> >> Yes, an easy reset of the user profile would be great.
> >
> > This would be a very welcome improvement. Maybe technically this could
> > invalidate the current profile and ask the user to restart OpenOffice,
> > which would start on a clean profile. This would offer a good user
> > experience (not optimal, since the optimal one would be triggered by a
> > reinstallation too), and the right moment for the cleanup would be
> > just after the code that checks if FirstStartWizard must be run and
> > just before the profile is loaded and locked (which means that the
> > "invalidate" bit must be set in a way that does not require profile
> > access but probably a simple filesystem access... OK, I'll stop here!).
> >
> >> Thus, I assume that the risk of a defect or a regression is low when
> >> solving issue 122398 and 122397 for AOO 4.0, except the issue which
> >> would be "copied" from a "messy" user profile.
> >
> > This is a case to consider. So I would suggest to set the default
> > answer to "Don't migrate" for extra safety, especially if we don't
> > have an easy profile reset mechanism in place.
>
> I agree.
> But it will cause translation effort - see screenshot of FirstStartWizard
> migration page [1] String "...If you do not want to reuse any settings in
> %PRODUCTNAME %PRODUCTVERSION, unmark the check box." will be
> change to "...If you do want to reuse settings in %PRODUCTNAME
> %PRODUCTVERSION, mark the check box."
>
> >
> >> Thus, send my your AOO 3.4.x or OOo 3.x user profile in a compressed
> >> form (.zip file or .tar.gz file or ...) or let me know, if you want
> >> to try my builds.
> >
> > If you had a build available, it would be easier for the QA volunteers
> > to test.
> >
>
> Yes, that would be the best.
>
> I will make the changes on trunk. Then the buildbot builds and the snapshot
> builds can be tested.
> As all changes will contain the ID of the corresponding issue in the submit
> summary, it will be easy to revert these changes.
>
> [1] https://issues.apache.org/ooo/attachment.cgi?id=80738
>
>
> Best regards, Oliver.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: api-unsubscribe@openoffice.apache.org
For additional commands, e-mail: api-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
small wrap-up at the top:
- nobody prefers to migrate extensions from AOO 3.4.x resp. OOo 3.x
more comments inline.
On 02.06.2013 13:17, Andrea Pescetti wrote:
> On 29/05/2013 Oliver-Rainer Wittmann wrote:
>> On 28.05.2013 18:23, Rob Weir wrote:
>>> Do we need to worry about the "messy" profiles that occurred from OOo
>>> 3.3.0 upgrades to AOO 3.4.0? That was when we saw spell checking
>>> breaking, missing dictionaries, and crashes. One of the nice things
>>> about a "clean start" with AOO 4.0 was that we avoid these kinds of
>>> problems.
>> From my point of view AOO 3.4.x users which had problems due to a
>> "messy" profile and had solved these problems, can migrate their profile
>> to AOO 4.0. AOO 3.4.x users which does not had solved their problems are
>> able to suppress the migration of their existing profile - see the
>> corresponding FirstStartWizard page for the user profile migration.
>
> I agree with Rob here that, since we had only a few widely reported bugs
> in OpenOffice 3.4.1 and one of them depended on the profile migration,
> we should be rather conservative.
>
> I agree it's better not to migrate extensions, since some of them might
> not work in OpenOffice 4 and their description.xml file in most cases
> will only state that they need "OpenOffice 3.0 or later".
>
>> Yes, an easy reset of the user profile would be great.
>
> This would be a very welcome improvement. Maybe technically this could
> invalidate the current profile and ask the user to restart OpenOffice,
> which would start on a clean profile. This would offer a good user
> experience (not optimal, since the optimal one would be triggered by a
> reinstallation too), and the right moment for the cleanup would be just
> after the code that checks if FirstStartWizard must be run and just
> before the profile is loaded and locked (which means that the
> "invalidate" bit must be set in a way that does not require profile
> access but probably a simple filesystem access... OK, I'll stop here!).
>
>> Thus, I assume that the risk of a defect or a regression is low when
>> solving issue 122398 and 122397 for AOO 4.0, except the issue which
>> would be "copied" from a "messy" user profile.
>
> This is a case to consider. So I would suggest to set the default answer
> to "Don't migrate" for extra safety, especially if we don't have an easy
> profile reset mechanism in place.
I agree.
But it will cause translation effort - see screenshot of
FirstStartWizard migration page [1]
String "...If you do not want to reuse any settings in %PRODUCTNAME
%PRODUCTVERSION, unmark the check box." will be change to "...If you do
want to reuse settings in %PRODUCTNAME %PRODUCTVERSION, mark the check box."
>
>> Thus, send my your AOO 3.4.x or OOo 3.x user profile in a compressed
>> form (.zip file or .tar.gz file or ...) or let me know, if you want
>> to try my builds.
>
> If you had a build available, it would be easier for the QA volunteers
> to test.
>
Yes, that would be the best.
I will make the changes on trunk. Then the buildbot builds and the
snapshot builds can be tested.
As all changes will contain the ID of the corresponding issue in the
submit summary, it will be easy to revert these changes.
[1] https://issues.apache.org/ooo/attachment.cgi?id=80738
Best regards, Oliver.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Andrea Pescetti <pe...@apache.org>.
On 29/05/2013 Oliver-Rainer Wittmann wrote:
> On 28.05.2013 18:23, Rob Weir wrote:
>> Do we need to worry about the "messy" profiles that occurred from OOo
>> 3.3.0 upgrades to AOO 3.4.0? That was when we saw spell checking
>> breaking, missing dictionaries, and crashes. One of the nice things
>> about a "clean start" with AOO 4.0 was that we avoid these kinds of
>> problems.
> From my point of view AOO 3.4.x users which had problems due to a
> "messy" profile and had solved these problems, can migrate their profile
> to AOO 4.0. AOO 3.4.x users which does not had solved their problems are
> able to suppress the migration of their existing profile - see the
> corresponding FirstStartWizard page for the user profile migration.
I agree with Rob here that, since we had only a few widely reported bugs
in OpenOffice 3.4.1 and one of them depended on the profile migration,
we should be rather conservative.
I agree it's better not to migrate extensions, since some of them might
not work in OpenOffice 4 and their description.xml file in most cases
will only state that they need "OpenOffice 3.0 or later".
> Yes, an easy reset of the user profile would be great.
This would be a very welcome improvement. Maybe technically this could
invalidate the current profile and ask the user to restart OpenOffice,
which would start on a clean profile. This would offer a good user
experience (not optimal, since the optimal one would be triggered by a
reinstallation too), and the right moment for the cleanup would be just
after the code that checks if FirstStartWizard must be run and just
before the profile is loaded and locked (which means that the
"invalidate" bit must be set in a way that does not require profile
access but probably a simple filesystem access... OK, I'll stop here!).
> Thus, I assume that the risk of a defect or a regression is low when
> solving issue 122398 and 122397 for AOO 4.0, except the issue which
> would be "copied" from a "messy" user profile.
This is a case to consider. So I would suggest to set the default answer
to "Don't migrate" for extra safety, especially if we don't have an easy
profile reset mechanism in place.
> Thus, send my your AOO 3.4.x or OOo 3.x user profile in a compressed
> form (.zip file or .tar.gz file or ...) or let me know, if you want
> to try my builds.
If you had a build available, it would be easier for the QA volunteers
to test.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi,
On 28.05.2013 18:23, Rob Weir wrote:
> On Tue, May 28, 2013 at 11:10 AM, Oliver-Rainer Wittmann
> <or...@googlemail.com> wrote:
>> Hi,
>>
>> I would like to activate/introduce code which migrates certain user profile
>> data from AOO 3.4.x and OOo 3.x installations during the reactivated
>> FirstStartWizard when the user starts the first time an installed AOO 4.0.
>> I have submitted two issues for this task:
>> - 122398 for the reactivation of the FirstStartWizard [1]
>> - 122397 for the code and configuration changes to migrate an AOO 3.4.x/OOo
>> 3.x user profile [2]
>>
>> In the last days I had a look at the user profile migration code and its
>> configuration. I figured out how it works in general.
>>
>> Further investigation is needed to figure out, if and how the existing
>> service to 'migrate' installed extensions works. I am currently not sure, if
>> the automatic user profile migration should try to install extensions from a
>> former version. My current preference is not to migrate extension from a
>> former version.
>>
>>
>> I need support and help with the migration of the user profile:
>>
>> (A) To figure out and test the user profile migration 'real-life' user
>> profiles or 'early-alpha-testers' would be welcome.
>> Thus, send my your AOO 3.4.x or OOo 3.x user profile in a compressed form
>> (.zip file or .tar.gz file or ...) or let me know, if you want to try my
>> builds.
>>
>
> Do we need to worry about the "messy" profiles that occurred from OOo
> 3.3.0 upgrades to AOO 3.4.0? That was when we saw spell checking
> breaking, missing dictionaries, and crashes. One of the nice things
> about a "clean start" with AOO 4.0 was that we avoid these kinds of
> problems.
From my point of view AOO 3.4.x users which had problems due to a
"messy" profile and had solved these problems, can migrate their profile
to AOO 4.0. AOO 3.4.x users which does not had solved their problems are
able to suppress the migration of their existing profile - see the
corresponding FirstStartWizard page for the user profile migration.
>
> But maybe there is some good as well? Since we're unlikely to totally
> eliminate all profile errors forever, maybe as part of your changes
> you can an easy way for the user to reset their profile? Today it is
> quite complicated for the average user. It would be great if a user
> with profile problems could reinstall AOO and when they hit the wizard
> be prompted to either preserve their profile or initialize a fresh
> profile.
Yes, an easy reset of the user profile would be great.
I do not think that reinstallation of AOO will help to reset the user
profile. The information that the FirstStartWizard had been run is
stored inside the user profile data. Thus, a reinstallation will not
bring the FirstStartWizard into life.
I also do not think that the user profile can be reset during the
FirstStartWizard as the application is already accessing (and locking)
the user profile during this time.
>
> So there are really three scenarios on an install:
>
> 0) Fresh install, no previous version: start with new profile
Works already.
>
> 1) Installing over an older version: migrate profile or not.
This currently depends on the involved versions.
(A) If new version does use the same user profile folder.
--> The user profile from the former version is just used for the new
version. No FirstStartWizard will popup.
(B) If new version does use another user profile folder.
--> the new version starts with a new profile. If a migration of the
former user profile has been configured in the new version an activated
FirstStartWizard would provide choice 'migrate or not'.
>
> 2) Installing over a current version: preserve current profile or not.
>
Here the same applies as in scenario 1).(A)
>
> Of course, the same caution I raise with all last-minute features:
> let's make sure we have volunteers willing/able to test.
>
I agree.
The user profile migration functionality is available at least since OOo
3.0. It works for the migration of a OOo 2.x user profile.
What is needed to activate it for the migration of a AOO 3.4.x/OOo 3.x
user profile are the corresponding configuration entries which specify
which part of the user profile data is migrated.
The FirstStartWizard functionality is also available since a couple of
OOo versions.
Thus, I assume that the risk of a defect or a regression is low when
solving issue 122398 and 122397 for AOO 4.0, except the issue which
would be "copied" from a "messy" user profile.
Best regards, Oliver.
> Regards,
>
> -Rob
>
>> (B) The first page of the FirstStartWizard is a general welcome containing
>> the following en-US strings.
>> String "This wizard will guide you through the license agreement, the
>> transfer of user data from %OLD_VERSION and the registration of
>> %PRODUCTNAME.", if a user profile for a migration is found, and string "This
>> wizard will guide you through the registration of %PRODUCTNAME." otherwise.
>> Since at least OOo 3.2 no license agreement was shown --> no text for a
>> license agreement is needed on the welcome page.
>> Since AOO 3.4 we do not have a registration --> no text for a registration
>> has to be shown.
>> Thus, I am asking for new string proposals for the welcome page of the
>> FirstStartWizard.
>> I have attached screenshots of the currently deactivated FirstStartWizard.
>>
>> [1] https://issues.apache.org/ooo/show_bug.cgi?id=122398
>> [2] https://issues.apache.org/ooo/show_bug.cgi?id=122397
>>
>>
>> Thanks in advance,
>> Oliver.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
>> For additional commands, e-mail: dev-help@openoffice.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Rob Weir <ro...@apache.org>.
On Tue, May 28, 2013 at 11:10 AM, Oliver-Rainer Wittmann
<or...@googlemail.com> wrote:
> Hi,
>
> I would like to activate/introduce code which migrates certain user profile
> data from AOO 3.4.x and OOo 3.x installations during the reactivated
> FirstStartWizard when the user starts the first time an installed AOO 4.0.
> I have submitted two issues for this task:
> - 122398 for the reactivation of the FirstStartWizard [1]
> - 122397 for the code and configuration changes to migrate an AOO 3.4.x/OOo
> 3.x user profile [2]
>
> In the last days I had a look at the user profile migration code and its
> configuration. I figured out how it works in general.
>
> Further investigation is needed to figure out, if and how the existing
> service to 'migrate' installed extensions works. I am currently not sure, if
> the automatic user profile migration should try to install extensions from a
> former version. My current preference is not to migrate extension from a
> former version.
>
>
> I need support and help with the migration of the user profile:
>
> (A) To figure out and test the user profile migration 'real-life' user
> profiles or 'early-alpha-testers' would be welcome.
> Thus, send my your AOO 3.4.x or OOo 3.x user profile in a compressed form
> (.zip file or .tar.gz file or ...) or let me know, if you want to try my
> builds.
>
Do we need to worry about the "messy" profiles that occurred from OOo
3.3.0 upgrades to AOO 3.4.0? That was when we saw spell checking
breaking, missing dictionaries, and crashes. One of the nice things
about a "clean start" with AOO 4.0 was that we avoid these kinds of
problems.
But maybe there is some good as well? Since we're unlikely to totally
eliminate all profile errors forever, maybe as part of your changes
you can an easy way for the user to reset their profile? Today it is
quite complicated for the average user. It would be great if a user
with profile problems could reinstall AOO and when they hit the wizard
be prompted to either preserve their profile or initialize a fresh
profile.
So there are really three scenarios on an install:
0) Fresh install, no previous version: start with new profile
1) Installing over an older version: migrate profile or not.
2) Installing over a current version: preserve current profile or not.
Of course, the same caution I raise with all last-minute features:
let's make sure we have volunteers willing/able to test.
Regards,
-Rob
> (B) The first page of the FirstStartWizard is a general welcome containing
> the following en-US strings.
> String "This wizard will guide you through the license agreement, the
> transfer of user data from %OLD_VERSION and the registration of
> %PRODUCTNAME.", if a user profile for a migration is found, and string "This
> wizard will guide you through the registration of %PRODUCTNAME." otherwise.
> Since at least OOo 3.2 no license agreement was shown --> no text for a
> license agreement is needed on the welcome page.
> Since AOO 3.4 we do not have a registration --> no text for a registration
> has to be shown.
> Thus, I am asking for new string proposals for the welcome page of the
> FirstStartWizard.
> I have attached screenshots of the currently deactivated FirstStartWizard.
>
> [1] https://issues.apache.org/ooo/show_bug.cgi?id=122398
> [2] https://issues.apache.org/ooo/show_bug.cgi?id=122397
>
>
> Thanks in advance,
> Oliver.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi
On 28.05.2013 17:10, Oliver-Rainer Wittmann wrote:
> Hi,
>
> I would like to activate/introduce code which migrates certain user
> profile data from AOO 3.4.x and OOo 3.x installations during the
> reactivated FirstStartWizard when the user starts the first time an
> installed AOO 4.0.
> I have submitted two issues for this task:
> - 122398 for the reactivation of the FirstStartWizard [1]
> - 122397 for the code and configuration changes to migrate an AOO
> 3.4.x/OOo 3.x user profile [2]
>
I have solved both tasks inclusive the migration of user-installed
extensions.
As the translation deadline has passed I have made no string changes.
Please provide feedback from your tests once a snapshot build or a
buildbot build including these changes is available.
Best regards, Oliver.
> In the last days I had a look at the user profile migration code and its
> configuration. I figured out how it works in general.
>
> Further investigation is needed to figure out, if and how the existing
> service to 'migrate' installed extensions works. I am currently not
> sure, if the automatic user profile migration should try to install
> extensions from a former version. My current preference is not to
> migrate extension from a former version.
>
>
> I need support and help with the migration of the user profile:
>
> (A) To figure out and test the user profile migration 'real-life' user
> profiles or 'early-alpha-testers' would be welcome.
> Thus, send my your AOO 3.4.x or OOo 3.x user profile in a compressed
> form (.zip file or .tar.gz file or ...) or let me know, if you want to
> try my builds.
>
> (B) The first page of the FirstStartWizard is a general welcome
> containing the following en-US strings.
> String "This wizard will guide you through the license agreement, the
> transfer of user data from %OLD_VERSION and the registration of
> %PRODUCTNAME.", if a user profile for a migration is found, and string
> "This wizard will guide you through the registration of %PRODUCTNAME."
> otherwise.
> Since at least OOo 3.2 no license agreement was shown --> no text for a
> license agreement is needed on the welcome page.
> Since AOO 3.4 we do not have a registration --> no text for a
> registration has to be shown.
> Thus, I am asking for new string proposals for the welcome page of the
> FirstStartWizard.
> I have attached screenshots of the currently deactivated FirstStartWizard.
>
> [1] https://issues.apache.org/ooo/show_bug.cgi?id=122398
> [2] https://issues.apache.org/ooo/show_bug.cgi?id=122397
>
>
> Thanks in advance,
> Oliver.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@openoffice.apache.org
For additional commands, e-mail: users-help@openoffice.apache.org
Re: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data -
help needed
Posted by Oliver-Rainer Wittmann <or...@googlemail.com>.
Hi
On 28.05.2013 17:10, Oliver-Rainer Wittmann wrote:
> Hi,
>
> I would like to activate/introduce code which migrates certain user
> profile data from AOO 3.4.x and OOo 3.x installations during the
> reactivated FirstStartWizard when the user starts the first time an
> installed AOO 4.0.
> I have submitted two issues for this task:
> - 122398 for the reactivation of the FirstStartWizard [1]
> - 122397 for the code and configuration changes to migrate an AOO
> 3.4.x/OOo 3.x user profile [2]
>
I have solved both tasks inclusive the migration of user-installed
extensions.
As the translation deadline has passed I have made no string changes.
Please provide feedback from your tests once a snapshot build or a
buildbot build including these changes is available.
Best regards, Oliver.
> In the last days I had a look at the user profile migration code and its
> configuration. I figured out how it works in general.
>
> Further investigation is needed to figure out, if and how the existing
> service to 'migrate' installed extensions works. I am currently not
> sure, if the automatic user profile migration should try to install
> extensions from a former version. My current preference is not to
> migrate extension from a former version.
>
>
> I need support and help with the migration of the user profile:
>
> (A) To figure out and test the user profile migration 'real-life' user
> profiles or 'early-alpha-testers' would be welcome.
> Thus, send my your AOO 3.4.x or OOo 3.x user profile in a compressed
> form (.zip file or .tar.gz file or ...) or let me know, if you want to
> try my builds.
>
> (B) The first page of the FirstStartWizard is a general welcome
> containing the following en-US strings.
> String "This wizard will guide you through the license agreement, the
> transfer of user data from %OLD_VERSION and the registration of
> %PRODUCTNAME.", if a user profile for a migration is found, and string
> "This wizard will guide you through the registration of %PRODUCTNAME."
> otherwise.
> Since at least OOo 3.2 no license agreement was shown --> no text for a
> license agreement is needed on the welcome page.
> Since AOO 3.4 we do not have a registration --> no text for a
> registration has to be shown.
> Thus, I am asking for new string proposals for the welcome page of the
> FirstStartWizard.
> I have attached screenshots of the currently deactivated FirstStartWizard.
>
> [1] https://issues.apache.org/ooo/show_bug.cgi?id=122398
> [2] https://issues.apache.org/ooo/show_bug.cgi?id=122397
>
>
> Thanks in advance,
> Oliver.
---------------------------------------------------------------------
To unsubscribe, e-mail: qa-unsubscribe@openoffice.apache.org
For additional commands, e-mail: qa-help@openoffice.apache.org