Le 25/10/2017 à 18:28, Jason DeRose a écrit :
On Wed, Oct 25, 2017, at 10:02 AM, Didier Roche wrote:
How come you are creating this breaking situation? Do you mind
expanding on this?
1) Switch to Vanilla Gnome session. 2) Receive update notification for
system-provided extension and take a
On Wed, Oct 25, 2017, at 10:02 AM, Didier Roche wrote:
> How come you are creating this breaking situation? Do you mind
> expanding on this?>
1) Switch to Vanilla Gnome session. 2) Receive update notification for
system-provided extension and take action, updating it via e.g.o. 3)
Switch to
On Wed, 25 Oct 2017, at 15:51, Jason DeRose wrote:
> 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.
He can use the vanilla GNOME session then.
> (I don't like that
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
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 pla
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.
On Wed, 25 Oct 2017 at 12:15:37 +0200, Didier Roche wrote:
> I guess RHEL should a similar problem shipping gnome-classic by default,
> made of system extensions, which can be equally overriden by user's update
I think GNOME Classic mostly dodges this by its extensions being
relatively tightly cou
On Wed, Oct 25, 2017, at 06:15 AM, Didier Roche wrote:
> My proposal would be:
> * Do not propose updating system extensions being part of a mode
> if his> mode is the current one.
> * If a there is an installed system extension and a local user
> one, but> this extension is part of the current
I want to propose some thoughts and potential rework around system
extensions which are part of a mode towards update & QA process.
In ubuntu, we implement an "ubuntu" GNOME Shell mode which enables some
extensions by default ("ubuntu-dock" and "ubuntu-appindicator"). Those
are respectively an I
