openoffice-api mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hans Zybura" <hzyb...@zybura.com>
Subject RE: [AOO 4.0]: migration of AOO 3.4.x/OOo 3.x user profile data - help needed
Date Tue, 04 Jun 2013 17:26:22 GMT
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


Mime
View raw message