Re: On updates

[Joaquim Rocha <jrocha endlessm com>]

Hey Matthias,

On Mon, Jan 15, 2018 at 2:32 PM, Matthias Clasen <matthias clasen gmail com> wrote:

On Mon, Jan 15, 2018 at 8:01 AM, Joaquim Rocha <jrocha endlessm com> wrote:

We have already a somehow similar feature in GNOME Software called "download-updates". This setting tells plugins they should download updates during refresh, so the new versions can be later installed/deployed. Although I understand that for packages this is good because installing a version of a package-based app while the app is running can lead to problems, it is not good to base the whole design in this principle, especially taking into account we now have things like Flatpak that can be safely fully updated even if the apps in question are running.

I think that (at least) Flatpak should not have this distinction between download+update in GNOME Software (not shown to the user at least) since it's not at all how users think of updates, and that's also probably why phones don't do it like that either...

I exclude offline updates (OS upgrades) from here because those obviously need to be done in that way.

That is just an assertion. In your opinion, just how do users think about updates?

Users think about updates as one action: "I do the update", or, if automatic, "the update gets done". There's usually no reasoning of "I download the update, and then I deploy the update", or "the update gets downloaded, and then I deploy the update". Again, for systems where deploying the update is a sensitive action, I can see how we should do the deploy state manually (same for offline updates), but for the rest I think it is as I'm describing. E.g. When I run dnf upgrade PACKAGE, it downloads+deploys the updates; when clicking Update in Google Play store it will download+deploy the update; same with my PS3; etc. Only my phone has a two step process but that's an offline update.

Besides, if user's don't deploy the updates right away when they're downloaded, then we're talking about potentially downloading more and more data unnecessarily until the user finally chooses to deploy them.

 

 

I have previously requested from Richard that we should be able to still show updates in GNOME Software that aren't downloaded (list of apps that have new versions) and this motivated having two plugin methods for adding updates: gs_plugin_add_updates, gs_plugin_add_updates_pending.

However, the latter (updates that aren't downloaded) is not called unless download-updates is false, and that's not great because with auto-updates, that setting should be on, but I'd still like to show the list of apps with updates to the user (even if they're not downloaded). Besides, having two methods to fetching updates seems overkill.

The original guiding principles for gnome-software have been:

- Don't make me (the user) wait

This is very arbitrary. Should we be overly smart and download apps that the user may be interested in only to save them a few seconds/minutes when eventually pressing install in those apps? Or maybe automatically download all runtimes available, so save time when eventually installing apps that need those?

I do expect that when I press update on an app it'll take a while to perform it because it will download+deploy it. Again, the same story happens for phones/consoles/etc, that's why I argue that users ought to be used to it.

So I see rather the download+install steps as a limitation of a packaged base system (and that's fine, I was not trying to make it work differently for packages).

Also, this "don't make me wait" principle can surely be accomplished with auto-updates, and even better: packages stay the same (need to be manually deployed), but Flatpaks get automatically deployed!

 

- Don't annoy me unless an action is ready to be taken

Sure! But again, my proposal even honor this principle more because you won't have to be bothered to deploy a Flatpak update when it should have been automatically done!

 

It is a fine line to walk between 'showing updates that aren't downloaded' and 'annoy me about something that isn't ready for action yet'. 

This is very subjective. Again, I am not proposing something new to the App Centers' world here, just actually trying to converge with what is common (and thus expected) elsewhere, as the way GNOME Software behaves is the exception. For me, showing updates even if they need to be downloaded is not something that isn't ready for action... because the action is to update them (download+deploy). Likewise I can argue that if there's an update available but the user needs to wait for the next automatic download to happen in order to see it (instead of showing it and still download it in the background when scheduled), we're relying too much in arbitrary defaults instead of showing the options to the user, as an App Center should do.

Hence, I never proposed to stop the automatic download/updates for apps. Only to do it in the background but also show the updates available to the user so they can: choose to the update it themselves, or to stop any updates happening ATM.

Cheers,

Joaquim Rocha  |  Endless