Re: user switching criterion proposal

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, May 6, 2020 at 5:51 PM Kamil Paral <kparal@xxxxxxxxxx> 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


I didn't receive much feedback so far. But since there was enough supportive feedback in our preliminary discussions, I take it as an agreement with the current criterion phrasing :-) I'll wait a few more days for more feedback, and if no one objects, I'll make the criterion live.

_______________________________________________
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

[Index of Archives]     [KDE Users]     [Fedora General Discussion]     [Older Fedora Users Mail]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Maintainers]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Triage]     [Coolkey]     [Yum Users]     [Yosemite Forum]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]

  Powered by Linux