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:orwittm...@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:orwittm...@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-unsubscr...@openoffice.apache.org > >> For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > > For additional commands, e-mail: dev-h...@openoffice.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: api-unsubscr...@openoffice.apache.org > For additional commands, e-mail: api-h...@openoffice.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
