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 Wed, 05 Jun 2013 16:27:51 GMT
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


Mime
View raw message