|
Le 25/10/2017 à 15:51, Jason DeRose a
écrit :
On Wed, Oct 25, 2017, at 09:12 AM, Didier Roche wrote:
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
What one user calls "supported" another calls "stale". Just
because a session enables an extension doesn't necessarily mean
the user wants the old version of the extension. (I don't like
that the user can't disable the session-enabled extensions,
anyway - the session configuration should remember the user's
configuration, not force the distro's configuration upon them..
but that's a different discussion).
Right, however, there are questions of security support, ensuring to
your users that what they got are supported. If people are starting
to update your extensions thinking they are supported when they are
not, you will some wrong perception, get them into unsupported and
potentially broken situation, and this reflects directly on the
quality of your product.
From the Ubuntu standpoint, if you only block extensions from
the current session, you would cause users to potentially
"break" the other sessions on their system, and possibly
encounter the issue when logging into that session at a later
time. It seems that you wouldn't want update notifications
prompting the user to replace an ubuntu version with an e.g.o
version, ever. Otherwise a user could login to their Vanilla
session and overwrite packages needed by the default session.
How come you are creating this breaking situation? Do you mind
expanding on this?
First, I don't think people switch between sessions really often,
and as told, in case they do and upgrade one extension, my proposal
is effectively targeted to not break the other sessions:
- the session where your extension is a system extension as part of
a mode is running the distributor version, as told *even* if there
is an user installed one
- the other session where you updated your version is the user's
local one, as the system extension isn't part of the current running
mode.
Basically, you have a strict-down session where you control the user
experience (gnome classic, ubuntu session…), still enabling them
adding more extensions, but not changing default's one, and the
other which are more freely tweakable.
The core issue in my opinion is competing platforms trying to
maintain specific different versions of the same files - which
is why I suggested allowing them to live side-by-side from
multiple sources and allow the user to toggle between them if
they so desire. The users who don't care and want things to
"just work" would never get a notification about an extension
that ubuntu had installed - those extensions would just be
maintained by the distro's package manager.
This is currently what we have done by changing the extension ID.
However, as stated in my first blog post, there is the issue that
potentially people will register the same name on
extensions.gnome.org and own it. Or you can upload an empty
extension which is just a hack…
Also, I note that you will end up with "staled" extension as you
meant, so I don't see how this is better than the first proposal?
What does it fix that the proposal doesn't?
Didier
|
