The installation process of updates needs redesigned as a matter of urgency so that LO can run some form of auto-update in the background (similar to what Firefox does these days) so end users always are up to date with the latest versions and, more importantly, security updates.
Most end users are (understandably) lazy and will update their software less often than they should, especially if the process is complicated or time consuming. In the case of LO, it is both. LO is not reliable in terms of carrying over the user settings from one version to the next (for example, it *always* tries to re-install 'English (South Africa)' for some strange reason; in the case of users where the UI locale is not the same as the OS locale, it sometimes will default back to English or the OS locale, not entirely sure which). This is not helpful for mid to low-tech users.
Case in point, I have just had to upgrade 5 systems for a small office (as a favour), which had various version ranging from 3.2 to 4.0. I had mentioned the security fix I had noticed but they had never heard of it. When questioned, they pointed out that most software (like Windows or Mozilla) these days has a simple update/upgrade process where user intervention is often no longer necessary beyond restarting.
I apologise for not being able to propose a patch or even a technical solution, I'm most active on the localization side and have almost no skills at coding.
Thanks for your issue and explaining here.
I expect that the people that should do this work will judge WONTFIX. Simply because there is a huge risk that this will break balance between free and corporate support, thus harming the whole project.. So I take freedom to set accordingly. Sorry.
Maybe there is room for improving explanation to users?
There is the automatic update notification. Maybe that should include warnings?
Thanks for commenting. But isn't it premature to pre-empt their response?
Secondly, I don't understand what it would break? Why would people be bothered by that when every other piece of software does it? And it this is a concern on the LO side, has anyone ever asked these clients? And lastly, if there are people who want the current setup, then we could always make it opt-in.
Let's run with this one for a bit longer, shall we?
PS: You're somewhat missing the point. Yes, there is that notification button up at the top right but people dislike the steps that follow.
Let's put this as enhancement.
> The installation process of updates needs redesigned as a matter of urgency
Yeah, every issue is urgent, of course.
> LO is not reliable in terms of carrying over the user settings
Weren’t we talking about the update system? Michael, in future please resist the urge to cramp a bunch of unrelated issues into one report — be as specific as possible. This applies to any software project you report bugs for. ;-)
> I apologise for not being able to propose a patch or even a technical solution
Don’t worry, a technical proposal has already been proposed: see...
*** This bug has been marked as a duplicate of bug 68274 ***
>Yeah, every issue is urgent, of course.
This is the first bug ever I've marked as urgent and yes, when small businesses consider the update process of a product so overly complicated they don't bother, it IS urgent I'd say. Unless we're making LO just for ourselves.
>Weren’t we talking about the update system? Michael, in future please resist the >urge to cramp a bunch of unrelated issues into one report — be as specific as >possible. This applies to any software project you report bugs for. ;-)
Look, I know that life in general would be so much easier if we could break down everything into neat little boxes and deal with them calmly, one after the other. But with all due respect, it doesn't work like that. For the end user, the 'upgrade process' is one interconnected issue and the reason I referred to the user settings not being carried over was less of an attempt to file a bug for that issue but simply part of the narrative I got from the hotel in question who were complaining about the upgrade process. So I wasn't actually bunching bugs.
Thirdly, the bug you refer to is specifically OSX whereas I'm talking cross-platform/Windows, so I'm not so sure it IS a duplicate, so I'm opening it again unless someone can reassure me that the solution you mentioned works for ALL OS.
Michael: thought you might provide point of view as expert dev, since there's a kind of debate about this tracker.
>thought you might provide point of view as expert dev, since there's a kind
>of debate about this tracker.
Julien, I'm not 100% sure what you mean. Are you asking on my views on bug 68274?
@ Michael Bauer: my previous comment was for Michael Meeks (that I put on cc on this bugtracker).
I'm happy to leave this open as an enhancement really; looking forward to seeing some progress here. As Cor says there may be some problems here; on the other hand the update mechanism used for single users is very different from corporate ones (who don't love magically downloading and running code from left/right outside their control ;-).
(In reply to comment #6)
> Thirdly, the bug you refer to is specifically OSX whereas I'm talking
> cross-platform/Windows, so I'm not so sure it IS a duplicate
Over that bug I mentioned a implementation for Windows as well, you need to read the whole bug and not just the description ;-) But whatever
I saw indeed that you mention there being a version of Sparkle that works on Windows but otherwise the whole thrust of bug 68274 is to implement Sparkle on OSX.
Since I'm being told time and again (just had it happen again over on WordPress where I dared file a bug for the moble app that covered both Android and iOS) that I cannot cover the same issue across multipe OS in the same but, it seems to me we need a bug to cover Windows too.
I have to say that I am strongly in favour of adopting the 'Fire Fox' model for automatic updates. For enterprise users (as is the case in FF) they require elevated authority before they can execute the update from the 'About' window, so I don't see install authority being a barrier.
I've long thought that the complete re-installation of LO is overkill for the installation of some minor bug fixes, but I can also understand from the developers point of view that it adds an extra tier of backward compatibility and support.
Would it be possible to share knowledge with FF devs (borrow their update code), or create this as a project for something like the 'summer of code' as there will be quite a large 'ecosystem' change required if LO goes down this route.
I have to agree with Michael that an auto update mechanism is something 'today's' software users expect, but it is such a big change that perhaps the bug tracker is the wrong place, and there needs to be a 'submission to the LO management board' for consideration.
> I have to say that I am strongly in favour of adopting the 'Fire Fox' model
> for automatic updates.
So am I - however, "me too" comments are pretty useless noise in bugzilla =) the longer the bug gets (comment-wise) the lower the probability of a fix [ JFYI ].
> Would it be possible to share knowledge with FF devs (borrow their=
> update code)
Certainly; it'd be madness to not re-use code for this.
> there needs to be a 'submission to the LO management board' for consideration.
LibreOffice development doesn't really work like that =) it's run by volunteers, if you want the feature you get to either a) implement it yourself, or b) provide resource for someone to implement it for you =)
In the meantime, lets leave this bug open.
*** Bug 92835 has been marked as a duplicate of this bug. ***
No reason for this not to be resolved duplicate of 62874 -- provide better update mechanism -- Mozilla ARchive (mar) based incrementals
*** This bug has been marked as a duplicate of bug 68274 ***