user switching criterion proposal

[Kamil Paral]

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....
https://lists.fedoraproject.org/archives/list/[e-mail]...
https://lists.fedoraproject.org/archives/list/[e-mail]...
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_Requi...

[Patrick O'Callaghan]

On Wed, 2020-05-06 at 17:51 +0200, Kamil Paral wrote:
>  For the purpose of this criterion, user switching doesn't include
> switching
>  between different sessions of the *same* user. 
Rather than "doesn't include" I'd suggest "need not include".

Maybe also add wording to suggest this doesn't cover switching between
two different DEs (though that's actually the use case I'm most
interested in personally).

poc

[Kamil Paral]

On Wed, May 6, 2020 at 6:15 PM Patrick O'Callaghan <pocallaghan(a)gmail.com&gt;
wrote:

>  On Wed, 2020-05-06 at 17:51 +0200, Kamil Paral wrote:
>  > For the purpose of this criterion, user switching doesn't include
>  switching
>  > between different sessions of the *same* user.
>
>  Rather than "doesn't include" I'd suggest "need not
> include".
>  
I'm not a native speaker, but that doesn't seem to convey what I'm trying
to say. "For the purpose of this criterion" is the important part. We don't
want different sessions of the same user to be considered blocking. So in
this criterion, it's not considered user switching. In general sense, it
probably is (but that doesn't matter).


>  Maybe also add wording to suggest this doesn't cover switching between
>  two different DEs (though that's actually the use case I'm most
>  interested in personally).
>  
I did. See this explanation note:
"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."
Perhaps I can add it as another footnote box directly to the criterion, I'm
not sure. AdamW, what do you think?

[Adam Williamson]

On Thu, 2020-05-07 at 10:40 +0200, Kamil Paral wrote:
>  On Wed, May 6, 2020 at 6:15 PM Patrick O'Callaghan
> <pocallaghan(a)gmail.com&gt;
>  wrote:
>  
>  > On Wed, 2020-05-06 at 17:51 +0200, Kamil Paral wrote:
>  > > For the purpose of this criterion, user switching doesn't include
>  > switching
>  > > between different sessions of the *same* user.
>  > 
>  > Rather than "doesn't include" I'd suggest "need not
> include".
>  > 
>  
>  I'm not a native speaker, but that doesn't seem to convey what I'm trying
>  to say. "For the purpose of this criterion" is the important part. We
> don't
>  want different sessions of the same user to be considered blocking. So in
>  this criterion, it's not considered user switching. In general sense, it
>  probably is (but that doesn't matter). 
I agree with Kamil here, I find his original wording better. "Need not
include" implies that it *could* be included, which is not what we're
trying to say, we are trying to say it's definitely not included - that
a bug which only affected switching between multiple sessions of one
user would not be release-blocking.

>  
>  > Maybe also add wording to suggest this doesn't cover switching between
>  > two different DEs (though that's actually the use case I'm most
>  > interested in personally).
>  > 
>  
>  I did. See this explanation note:
>  "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."
>  Perhaps I can add it as another footnote box directly to the criterion, I'm
>  not sure. AdamW, what do you think? 
I agree that "in their default configuration" covers it, but an
explicit footnote couldn't hurt, it's always good to be clear.
-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

[Kamil Paral]

On Wed, May 6, 2020 at 5:51 PM Kamil Paral <kparal(a)redhat.com&gt; 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....
>
>
> https://lists.fedoraproject.org/archives/list/[e-mail]...
>
>
> https://lists.fedoraproject.org/archives/list/[e-mail]...
>  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_Requi...
>  

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.

[Brandon Nielsen]

On 5/12/20 1:19 AM, Kamil Paral wrote:
>  On Wed, May 6, 2020 at 5:51 PM Kamil Paral <kparal(a)redhat.com 
>  <mailto:[e-mail]>> wrote:
>
>  
[snip]
>      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]).
>  
[snip]
>  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.
>
>  
I think the snipped section should read more definitively, maybe:

"The switching mechanism must correctly perform the requested operation. 
If the operation does not succeed 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])."

[Kamil Paral]

On Tue, May 12, 2020 at 1:58 PM Brandon Nielsen <nielsenb(a)jetfuse.net&gt;
wrote:

>  On 5/12/20 1:19 AM, Kamil Paral wrote:
>
>  On Wed, May 6, 2020 at 5:51 PM Kamil Paral <kparal(a)redhat.com&gt; wrote:
>
> >
> > [snip]
>
>  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]).
> >
> > [snip]
>
>
>
>  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.
>
>
>  I think the snipped section should read more definitively, maybe:
>
>  "The switching mechanism must correctly perform the requested operation.
>  If the operation does not succeed 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])."
>  
Thanks. "Succeed" sounds better than "work" in the second sentence. As
for
"attempt" vs "perform" - just to be sure, have you seen my response
to
Lukas Ruzicka where I was talking about it? Do you still think the wording
should be stronger after seeing those other examples I listed?