Re: GNOME Shell and system extensions being part of a mode

[Didier Roche <didrocks ubuntu com>]

Le 25/10/2017 à 13:22, Jason DeRose a écrit :

The problem you describe is a real issue. The flip problem is also an issue, where the user intends to install a newer version. This is an issue in distros where many extensions are shipping out of the box, and the package manager competes with e.g.o. This is also an issue where the user installs a development version of an extension and the Update notifier thinks the e.g.o is newer and continually requests that the user update.

However, giving system extensions favor of a user's local extensions seems counter-intuitive and blocking the user from updating extensions on his own system seems potentially maddening.

The issue of letting users upgrading is the proposal of auto-updating. Nothing will tell that a new release of distribution X will have a newer GNOME Shell, and so, version compatibility check (which is currently disabled in most places) won't prevent people to ugprade to a new *unsupported* version of the extension, which didn't go to the same QA rules than a traditional Stable Release Update.

Remember that I'm not proposing to favor system extensions for all extensions, due to the issue you are describing (stalled or old versions). I'm only suggesting this for system extension enabled from the current mode (which are already unconditionnally enabled).

In the Ubuntu case for instance, we offer another session with no extensions enabled by default via a vanilla GNOME Shell look and behavior. On this one, people would be able to use the new, user's local version of those extensions.

However, you can consider extensions enabled as part of a mode as being really part of the Shell, which means, the default desired behavior which has to be QAed, controlled and such.

Making sense?
Didier