openoffice-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hans Zybura" <>
Subject RE: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Date Wed, 05 Jun 2013 16:27:51 GMT

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

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

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 []
> 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
> >> [] Sent: Monday, June 03, 2013
> >> 10:47 AM To: 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]
> >>
> >>
> >> Best regards, Oliver.
> >>
> >> ---------------------------------------------------------------------
> >>
> >>
> To unsubscribe, e-mail:
> >> For additional commands, e-mail:
> >
> >
> > ---------------------------------------------------------------------
> >
> >
> To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message