> From: Juergen Schmidt [mailto:jogischm...@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:orwittm...@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-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: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
