On 06/05/2020 09:51, Kamil Paral wrote:
Following the previous discussion [1] and the gathered support, here's a
proposal for the user switching criterion. I believe we should put it
into the Final milestone [2].
~~~~~~~~~~~~~~~~~~~~~
User switching
User switching must work using the mechanisms offered (if any) by all
release-blocking desktops in their default configuration.
What is user switching?
User switching is a process of changing the currently presented desktop
session between concurrent sessions of two or more different users. The
user sessions keep running in the background, and users can switch
between them repeatedly without losing any running application state.
For the purpose of this criterion, user switching doesn't include
switching between different sessions of the *same* user.
Work?
The switching mechanism must correctly attempt the requested operation.
If the operation doesn't work on a subset of graphical drivers, the
release blocking decision should be based on the number of affected
users, the problem severity and available workarounds (as is our
[standard procedure](Basic_Release_Criteria#Basic_Release_Requirements)[3]).
~~~~~~~~~~~~~~~~~~~~~~
The "in their default configuration" part is there to cover only cases
where the system hasn't been modified in a substantial (and relevant)
way. This will exclude cases where people e.g. install several desktop
environments, replace their DM for a different one, tweak systemd
settings, or install a non-default graphics driver.
In the last paragraph I explicitly pointed out that we'll use our usual
approach of judging the impact if the issue only affects certain
configurations. I hope that alleviates some hardware-related concerns.
Note: I considered the option to also include user switching in
text-only environments (simultaneous user login on different VTs, as is
common on Server), but it's not completely the same. I concluded it's
better to have a separate and tailored criterion for it, if there's
interest.
Please comment, thank you.
[1]
https://lists.fedoraproject.org/archives/list/test%40lists.fedoraproject.org/message/5TZU2LAB5RYBBS3ELQHOOVNCVW4JXHWC/
https://lists.fedoraproject.org/archives/list/desktop@xxxxxxxxxxxxxxxxxxxxxxx/thread/J4Z75Y25Z7DTS43WOXYJRVYNO562GGIZ/
https://lists.fedoraproject.org/archives/list/kde@xxxxxxxxxxxxxxxxxxxxxxx/thread/J4Z75Y25Z7DTS43WOXYJRVYNO562GGIZ/
https://pagure.io/fedora-workstation/issue/139
[2] https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria
[3]
https://fedoraproject.org/wiki/Basic_Release_Criteria#Basic_Release_Requirements
_______________________________________________
kde mailing list -- kde@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kde-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/kde@xxxxxxxxxxxxxxxxxxxxxxx
From a user that utilizes user switching on a regular basis. This is
very critical to me using Fedora or KDE specifically. I have a minimum
of two KDE sessions open at any time and there are times I may have as
many as 4 sessions open, all under different users. All for the
isolation between functions.
As encryption is also an issue on a per user level, that can also
complicate the process. LUKS 1 is supported in pam_mount but LUKS 2
isn't in the default (F31) at least but the default encryption is LUKS 2
so it does become an issue.
Also, with the user switching, session closing needs to be addressed
properly. Logout of a session and find that many processes continue to
that prevent the session from actually closing. If the session doesn't
close properly, then the VT is still running using resources and the
person is not logged out or logged in. On this case, I find if I
prevent desktop search, the problems seems much less.
I have read that systemd will be able to handle user home directory
encryption in the future. This may solve the pam_mount issues that I am
dealing with now.
Robin
_______________________________________________
kde mailing list -- kde@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kde-leave@xxxxxxxxxxxxxxxxxxxxxxx
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/kde@xxxxxxxxxxxxxxxxxxxxxxx
