Blocking on user switching: redux

[Adam Williamson]

Hi folks!

So, during Fedora 32 Final blocker review, a bug relating to "user
switching" came up for review:

https://bugzilla.redhat.com/show_bug.cgi?id=1817708

I dug into the question of whether we have tended to consider the "log
in / log out / shut down / reboot" criterion as covering user
switching, and found that this issue is actually kinda outstanding and
unresolved for a long time.

Back in January 2015, we kinda provisionally decided that we *did* want
to block on user switching bugs, by accepting this one as a blocker
during a review meeting:

https://bugzilla.redhat.com/show_bug.cgi?id=1184933

kparal was detailed to propose clearly adding it to the criteria, and
he duly drafted up a change and mailed it to the relevant lists -
test@, kde@ and desktop@:

https://lists.fedoraproject.org/pipermail/test/2015-January/124811.html
https://lists.fedoraproject.org/pipermail/kde/2015-January/014175.html
https://lists.fedoraproject.org/pipermail/desktop/2015-January/011558.html

However, here things foundered a bit because there was some opposition
to the idea. The discussion is spread across the three lists, but my
reading is broadly that there were distinct camps in favour of and
against blocking on user switching bugs. Prominent "pro-blocking" folks
were Michael Catanzaro and Kevin Kofler. Prominent "anti-blocking"
folks were Matthias Clasen, Rex Dieter and Josh Boyer. Obviously that's
a particularly awkward split because we have pro- and anti- folks on
both the desktop and KDE teams.

The discussion was pretty active, but in the end it sort of petered out
without any definite conclusion being reached. The draft changes Kamil
proposed were never made, and the criterion remained as it was before.

For the purposes of our specific F32 blocker proposal we decided to
adopt the principle that, since there was a discussion that clearly did
not reach a consensus that user switching *should* be release-blocking, 
we could not really treat it as such, and thus we rejected the bug as a
blocker. But I figured it would probably be a good idea to bring the
topic up again and try to come to a definite conclusion this time.

So, once again: do we think it makes sense to consider desktop user
switching - that is, switching between multiple active desktop sessions
for different users, without logging out and in - as release-blocking?
Has anyone who was active in the previous discussion changed their mind
on this?

I suppose one question that could potentially arise is whether we could
treat it as release-blocking for GNOME but not for KDE, or vice versa.
In general I think it's a good goal to try and keep our standards
similar across our release-blocking desktops, but I do think we could
at least consider that, if the discussion seemed to be going in that
direction.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Iñaki Ucar]

On Tue, 14 Apr 2020 at 20:14, Adam Williamson
<adamwill(a)fedoraproject.org&gt; wrote:
>  Hi folks!
>
>  So, during Fedora 32 Final blocker review, a bug relating to "user
>  switching" came up for review:
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=1817708
>
>  I dug into the question of whether we have tended to consider the "log
>  in / log out / shut down / reboot" criterion as covering user
>  switching, and found that this issue is actually kinda outstanding and
>  unresolved for a long time. 
This is about the KillUserProcesses yes/no debate [1], right? Some context [2].

[1]
https://lists.fedoraproject.org/archives/list/[e-mail]...
[2]
https://lists.fedoraproject.org/archives/list/[e-mail]...

Iñaki

[Adam Williamson]

On Tue, 2020-04-14 at 21:20 +0200, Iñaki Ucar wrote:
>  On Tue, 14 Apr 2020 at 20:14, Adam Williamson
>  <adamwill(a)fedoraproject.org&gt; wrote:
>  > Hi folks!
>  > 
>  > So, during Fedora 32 Final blocker review, a bug relating to "user
>  > switching" came up for review:
>  > 
>  > https://bugzilla.redhat.com/show_bug.cgi?id=1817708
>  > 
>  > I dug into the question of whether we have tended to consider the "log
>  > in / log out / shut down / reboot" criterion as covering user
>  > switching, and found that this issue is actually kinda outstanding and
>  > unresolved for a long time.
>  
>  This is about the KillUserProcesses yes/no debate [1], right? 
No.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Kamil Paral]

On Tue, Apr 14, 2020 at 8:14 PM Adam Williamson <adamwill(a)fedoraproject.org&gt;
wrote:

>  Hi folks!
>
>  So, during Fedora 32 Final blocker review, a bug relating to "user
>  switching" came up for review:
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=1817708
>
>  I dug into the question of whether we have tended to consider the "log
>  in / log out / shut down / reboot" criterion as covering user
>  switching, and found that this issue is actually kinda outstanding and
>  unresolved for a long time.
>
>  Back in January 2015, we kinda provisionally decided that we *did* want
>  to block on user switching bugs, by accepting this one as a blocker
>  during a review meeting:
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=1184933
>
>  kparal was detailed to propose clearly adding it to the criteria, and
>  he duly drafted up a change and mailed it to the relevant lists -
>  test@, kde@ and desktop@:
>
>  https://lists.fedoraproject.org/pipermail/test/2015-January/124811.html
>  https://lists.fedoraproject.org/pipermail/kde/2015-January/014175.html
>  https://lists.fedoraproject.org/pipermail/desktop/2015-January/011558.html
>
>  However, here things foundered a bit because there was some opposition
>  to the idea. The discussion is spread across the three lists, but my
>  reading is broadly that there were distinct camps in favour of and
>  against blocking on user switching bugs. Prominent "pro-blocking" folks
>  were Michael Catanzaro and Kevin Kofler. Prominent "anti-blocking"
>  folks were Matthias Clasen, Rex Dieter and Josh Boyer. Obviously that's
>  a particularly awkward split because we have pro- and anti- folks on
>  both the desktop and KDE teams.
>
>  The discussion was pretty active, but in the end it sort of petered out
>  without any definite conclusion being reached. The draft changes Kamil
>  proposed were never made, and the criterion remained as it was before.
>
>  For the purposes of our specific F32 blocker proposal we decided to
>  adopt the principle that, since there was a discussion that clearly did
>  not reach a consensus that user switching *should* be release-blocking,
>  we could not really treat it as such, and thus we rejected the bug as a
>  blocker. But I figured it would probably be a good idea to bring the
>  topic up again and try to come to a definite conclusion this time.
>
>  So, once again: do we think it makes sense to consider desktop user
>  switching - that is, switching between multiple active desktop sessions
>  for different users, without logging out and in - as release-blocking?
>  Has anyone who was active in the previous discussion changed their mind
>  on this?
>  
I use the functionality daily, so I'm biased, same as mattdm. I consider it
really a basic desktop functionality. On our home laptop, my wife never
logs out. Why would she, she just closes the lid and the laptop goes to
sleep. When I want to do something, I simply log it as my own user, do what
I need, and again shut the lid. I reboot the laptop twice a month when I
apply updates. There is almost never just a single user logged in. The idea
that we only validate Fedora for a single-user scenario, where the whole
system can be used just by a single user at any moment, feels... almost
obscene given our UNIX heritage :-) In the past when we had some user
switching issues, it was a huge pain for me, because my wife will never
remember Ctrl+Alt+Fx shortcuts to workaround a framebuffer switching
problem. And constantly making sure the other person is not logged in, and
asking him/her to log out if he/she is, is nothing but a headache. It makes
the home laptop use case completely broken. Not to mention it's really hard
to answer her questions about why we're using something that broken.

In the past, there were concerns about graphics drivers quality. They have
hopefully improved. But I'll repeat again - we have safeguards against
issues that affect just a portion of our hardware. We can be explicit about
it in the criterion, or we can have it implied from our standard
procedures. If the bug only happens on e.g. nouveau, we don't need to block
on it (especially given its maintenance status and Nvidia's zero help). If
the bug only happens on a single Intel GPU family, ditto. If the bug
happens to all radeon or all intel users, well, we would definitely have a
conversation about it. If the bug happens to everyone, all bare metal and
also including VMs, that's a clear indication that the problem is not in
drivers but in our software, and would be a blocker.
It's also possible to remove drivers from the picture completely and only
cover the last mentioned scenario ("happens on all bare metal and VMs") in
the criterion, if developers desire it. It would be weak, but would
definitely be a step in the right direction.

[Neal Gompa]

On Tue, Apr 14, 2020 at 2:14 PM Adam Williamson
<adamwill(a)fedoraproject.org&gt; wrote:
>  Hi folks!
>
>  So, during Fedora 32 Final blocker review, a bug relating to "user
>  switching" came up for review:
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=1817708
>
>  I dug into the question of whether we have tended to consider the "log
>  in / log out / shut down / reboot" criterion as covering user
>  switching, and found that this issue is actually kinda outstanding and
>  unresolved for a long time.
>
>  Back in January 2015, we kinda provisionally decided that we *did* want
>  to block on user switching bugs, by accepting this one as a blocker
>  during a review meeting:
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=1184933
>
>  kparal was detailed to propose clearly adding it to the criteria, and
>  he duly drafted up a change and mailed it to the relevant lists -
>  test@, kde@ and desktop@:
>
>  https://lists.fedoraproject.org/pipermail/test/2015-January/124811.html
>  https://lists.fedoraproject.org/pipermail/kde/2015-January/014175.html
>  https://lists.fedoraproject.org/pipermail/desktop/2015-January/011558.html
>
>  However, here things foundered a bit because there was some opposition
>  to the idea. The discussion is spread across the three lists, but my
>  reading is broadly that there were distinct camps in favour of and
>  against blocking on user switching bugs. Prominent "pro-blocking" folks
>  were Michael Catanzaro and Kevin Kofler. Prominent "anti-blocking"
>  folks were Matthias Clasen, Rex Dieter and Josh Boyer. Obviously that's
>  a particularly awkward split because we have pro- and anti- folks on
>  both the desktop and KDE teams.
>
>  The discussion was pretty active, but in the end it sort of petered out
>  without any definite conclusion being reached. The draft changes Kamil
>  proposed were never made, and the criterion remained as it was before.
>
>  For the purposes of our specific F32 blocker proposal we decided to
>  adopt the principle that, since there was a discussion that clearly did
>  not reach a consensus that user switching *should* be release-blocking,
>  we could not really treat it as such, and thus we rejected the bug as a
>  blocker. But I figured it would probably be a good idea to bring the
>  topic up again and try to come to a definite conclusion this time.
>
>  So, once again: do we think it makes sense to consider desktop user
>  switching - that is, switching between multiple active desktop sessions
>  for different users, without logging out and in - as release-blocking?
>  Has anyone who was active in the previous discussion changed their mind
>  on this?
>
>  I suppose one question that could potentially arise is whether we could
>  treat it as release-blocking for GNOME but not for KDE, or vice versa.
>  In general I think it's a good goal to try and keep our standards
>  similar across our release-blocking desktops, but I do think we could
>  at least consider that, if the discussion seemed to be going in that
>  direction. 
Unfortunately I missed the discussion because of $DAYJOB stuff...

From my perspective in Workstation WG and member of KDE SIG, I would
say that we should consider this release blocking. This is a somewhat
common use-case on family/shared computers that we should have
working.

(I am a tiny bit biased, I've set up several Fedora systems where this
feature has been used heavily...)




--
真実はいつも一つ！/ Always, there's only one truth!

[Rex Dieter]

I think it's probably time to consider this release blocking, with caveat.   It's
been known for quite awhile that lingering processes makes user switching under plasma
problematic, so this problem needs to be solved first as a prerequisite.  One possible
solution is
https://fedoraproject.org/wiki/Changes/KillUserProcesses_by_default
(but I don't insist on that particular fix, just that it is addressed somehow first).

[Mattia Verga]

Il 18/04/20 15:40, Rex Dieter ha scritto:
>  I think it's probably time to consider this release blocking,
> with caveat.   It's been known for quite awhile that lingering processes makes user
> switching under plasma problematic, so this problem needs to be solved first as a
> prerequisite.  One possible solution is
>  https://fedoraproject.org/wiki/Changes/KillUserProcesses_by_default
>  (but I don't insist on that particular fix, just that it is addressed somehow
> first).
>  
One thing it's not clear to me: are we discussing about user switching 
or logout/login?

As a user I would like to be able to switch from user A to user B and 
when I switch back to user A I want to have all my documents and apps 
running as before switching users. This KillUserProcesses_by_default 
seems to me more like logging out user A and login as user B, so when 
logging in again ad user A I will have a new, blank session.

Maybe I'm wrong (for sure...), but current user switching problem 
doesn't seem related to killing processes to me. What I observed is this 
behavior:

- login user A
- you get a Plasma session on VT1 (default)
- try to switch user
- login again as user A
- instead of logging in again to the already opened session on VT1, a 
new Plasma session is created on VT2 (and it doesn't work)

SDDM should remember that user A is already logged in on VT1 and use the 
existing session, instead of opening another one, but this doesn't happen.

Mattia

[Patrick O'Callaghan]

On Sat, 2020-04-18 at 15:33 +0000, Mattia Verga wrote:
>  Il 18/04/20 15:40, Rex Dieter ha scritto:
>  > I think it's probably time to consider this release blocking, with caveat.  
> It's been known for quite awhile that lingering processes makes user switching under
> plasma problematic, so this problem needs to be solved first as a prerequisite.  One
> possible solution is
>  > https://fedoraproject.org/wiki/Changes/KillUserProcesses_by_default
>  > (but I don't insist on that particular fix, just that it is addressed somehow
> first).
>  > 
>  One thing it's not clear to me: are we discussing about user switching 
>  or logout/login?
>  
>  As a user I would like to be able to switch from user A to user B and 
>  when I switch back to user A I want to have all my documents and apps 
>  running as before switching users. This KillUserProcesses_by_default 
>  seems to me more like logging out user A and login as user B, so when 
>  logging in again ad user A I will have a new, blank session.
>  
>  Maybe I'm wrong (for sure...), but current user switching problem 
>  doesn't seem related to killing processes to me. What I observed is this 
>  behavior:
>  
>  - login user A
>  - you get a Plasma session on VT1 (default)
>  - try to switch user
>  - login again as user A
>  - instead of logging in again to the already opened session on VT1, a 
>  new Plasma session is created on VT2 (and it doesn't work)
>  
>  SDDM should remember that user A is already logged in on VT1 and use the 
>  existing session, instead of opening another one, but this doesn't happen. 
IMHO that's a strange interpretation of what user switching is. It
would never occur to me that I would be reconnecting to the same
session. Why would I do that? If I switch sessions I want them to be
independent of each other, otherwise I don't see the point.

poc

[Mattia Verga]

Il 18/04/20 17:41, Patrick O'Callaghan ha scritto:
>  IMHO that's a strange interpretation of what user switching is. It
>  would never occur to me that I would be reconnecting to the same
>  session. Why would I do that? If I switch sessions I want them to be
>  independent of each other, otherwise I don't see the point.
>
>  poc
>  _______________________________________________ 
My bad, I didn't explain well what I understand.

Let's say I'm user A and I'm working on a document. Now user B needs a 
quick login, so I let them to switch user to their account. When they 
finish I switch back into my user and I want to be able to work again on 
my previously opened document - I should not have lost all my work when 
I switched users.

The steps I described were just a corner case to describe what I 
currently observe when switching users: even if I don't really switch 
between users, but I choose "switch user" and the login again on my 
user, I see another session opened on VT2 instead of logging me back on 
existing session on VT1.

Mattia

[Patrick O'Callaghan]

On Sat, 2020-04-18 at 16:28 +0000, Mattia Verga wrote:
>  Il 18/04/20 17:41, Patrick O'Callaghan ha scritto:
>  > IMHO that's a strange interpretation of what user switching is. It
>  > would never occur to me that I would be reconnecting to the same
>  > session. Why would I do that? If I switch sessions I want them to be
>  > independent of each other, otherwise I don't see the point.
>  > 
>  > poc
>  > _______________________________________________
>  
>  My bad, I didn't explain well what I understand.
>  
>  Let's say I'm user A and I'm working on a document. Now user B needs a 
>  quick login, so I let them to switch user to their account. When they 
>  finish I switch back into my user and I want to be able to work again on 
>  my previously opened document - I should not have lost all my work when 
>  I switched users. 
That's also what I mean.

>  The steps I described were just a corner case to describe what I 
>  currently observe when switching users: even if I don't really switch 
>  between users, but I choose "switch user" and the login again on my 
>  user, I see another session opened on VT2 instead of logging me back on 
>  existing session on VT1. 
That's what I don't mean. If I switch to the same user on VT2 I want a
*new* session. If I switch back to VT1 I continue with the old session.
If both VTs are in the same login session, I don't see the point of
this if we already have virtual desktops and Activities (in fact I've
never really seen the point of Activities either, but never mind).

poc

[Kamil Paral]

On Sat, Apr 18, 2020 at 7:09 PM Patrick O'Callaghan <pocallaghan(a)gmail.com&gt;
wrote:

>  > The steps I described were just a corner case to describe what
> I
>  > currently observe when switching users: even if I don't really switch
>  > between users, but I choose "switch user" and the login again on my
>  > user, I see another session opened on VT2 instead of logging me back on
>  > existing session on VT1.
>
>  That's what I don't mean. If I switch to the same user on VT2 I want a
>  *new* session. If I switch back to VT1 I continue with the old session.
>  If both VTs are in the same login session, I don't see the point of
>  this if we already have virtual desktops and Activities (in fact I've
>  never really seen the point of Activities either, but never mind).
>  
If I understand this correctly, one use case speaks about switching user A
and user B, 1 session per each. The other use case speaks about 2 different
sessions for user A. User switching, as discussed here, is only concerned
about the former case, *different* users having a single session each.
Multiple graphical sessions for the same user is not something we'd want to
block the release on, I believe.

Also, as usual with our criteria, user switching would only be required to
work if it was offered by the desktop UI. If KDE decides to remove or hide
that option for whatever reason, we'd of course not require it to have it.
Similarly, we'd not mandate how exactly it is implemented - if I can switch
back to user A existing session only if I type "I❤️KDE" as my password,
otherwise I get a new session, that's fine, as long as it's clearly
communicated. KDE can set any defaults it wants.

[Lukas Ruzicka]

>  If I understand this correctly, one use case speaks about switching user A
>  and user B, 1 session per each. The other use case speaks about 2 different
>  sessions for user A. User switching, as discussed here, is only concerned
>  about the former case, *different* users having a single session each.
>  
+1


>  Multiple graphical sessions for the same user is not something
> we'd want
>  to block the release on, I believe.
>  
Well, originally I thought this to be something unrealistic, but in fact,
if user A is running a desktop session and wants to connect from a
different location via VNC for example, they might also want another
desktop session in the VNC. But we do not have any blocking criteria
against sharing a desktop via VNC or something like that at the moment
AFAIK.


>  Also, as usual with our criteria, user switching would only be
> required to
>  work if it was offered by the desktop UI. If KDE decides to remove or hide
>  that option for whatever reason, we'd of course not require it to have it.
>  Similarly, we'd not mandate how exactly it is implemented - if I can switch
>  back to user A existing session only if I type "I❤️KDE" as my password,
>  otherwise I get a new session, that's fine, as long as it's clearly
>  communicated. KDE can set any defaults it wants.
>  
+1



>  _______________________________________________
>  kde mailing list -- kde(a)lists.fedoraproject.org
>  To unsubscribe send an email to kde-leave(a)lists.fedoraproject.org
>  Fedora Code of Conduct:
>  https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>  List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>  List Archives:
>  https://lists.fedoraproject.org/archives/list/[e-mail]
>  

-- 

Lukáš Růžička

FEDORA QE, RHCE

Red Hat

<https://www.redhat.com>

Purkyňova 115

612 45 Brno - Královo Pole

lruzicka(a)redhat.com
TRIED AND PERSONALLY TESTED, ERGO TRUSTED. <https://redhat.com/trusted>

[Rex Dieter]

Strictly speaking, we're talking only about user switching.  My bad for confusing
matters by bringing up the related-but different issue.  So, that said, I withdraw the
caveat, and will unconditionally support user switching as an important feature worth
blocking for.

What you describe is a corner-case, that should be handled better.