On Thu, May 7, 2020 at 8:48 AM Lukas Ruzicka lruzicka@redhat.com wrote:
Hello, I agree, that user switching as described in this proposal is something that should work really well, because it can obviously change the user experience in some cases. I only have a problem with the following statement:
The switching mechanism must correctly attempt the requested operation.
As I understand it, it might be enough if the operation is "attempted" only? This sounds vague and weak to me. I think we need something stronger here, like "it performs the requested operation" or something similar.
It's similar to e.g. shutdown criterion [1] where the "shutdown mechanism must correctly request a shutdown from the system firmware" or storage resize criterion [2] where "installer mechanism for resizing storage volumes must correctly attempt the requested operation". The important word in all these cases is "correctly". It implies that the software part, the calling part, must be implemented correctly. But because it deals with hardware and low level firmware and drivers, it admits that that part might not work correctly in all configurations. Which is then expanded in the next sentence.
I simply got my inspiration from our other criteria when writing this one. It doesn't have to stay this way. But I think the "correctly attempt/request" wording is quite fitting here and it's not weak (at least not towards our software stack, which is the part which we can control reasonably well).
[1] https://fedoraproject.org/wiki/Fedora_32_Beta_Release_Criteria#Shutdown.2C_r... [2] https://fedoraproject.org/wiki/Fedora_32_Final_Release_Criteria#Storage_volu...
On Thu, 2020-05-07 at 10:52 +0200, Kamil Paral wrote:
On Thu, May 7, 2020 at 8:48 AM Lukas Ruzicka lruzicka@redhat.com wrote:
Hello, I agree, that user switching as described in this proposal is something that should work really well, because it can obviously change the user experience in some cases. I only have a problem with the following statement:
The switching mechanism must correctly attempt the requested operation.
As I understand it, it might be enough if the operation is "attempted" only? This sounds vague and weak to me. I think we need something stronger here, like "it performs the requested operation" or something similar.
It's similar to e.g. shutdown criterion [1] where the "shutdown mechanism must correctly request a shutdown from the system firmware" or storage resize criterion [2] where "installer mechanism for resizing storage volumes must correctly attempt the requested operation". The important word in all these cases is "correctly". It implies that the software part, the calling part, must be implemented correctly. But because it deals with hardware and low level firmware and drivers, it admits that that part might not work correctly in all configurations. Which is then expanded in the next sentence.
I simply got my inspiration from our other criteria when writing this one. It doesn't have to stay this way. But I think the "correctly attempt/request" wording is quite fitting here and it's not weak (at least not towards our software stack, which is the part which we can control reasonably well).
I actually would agree with Lukas here. We use the "attempt" wording as a kind of weasel formula when there's a part of the stack we don't want to support. That's why we use it in the resize case: there's a lot of complexity to disk resizing and it's a thing that just doesn't always work, so we don't want to block on the resize itself but rather block on anaconda correctly requesting it. Shutdown is similar: we are blocking on what's under our control, the OS side of things. If there's a system firmware bug that prevents it shutting down properly, that isn't our problem.
I think we don't need the weasel form in this criterion as we actually do want to block on user switching *fully working*. So I think I'd agree with Lukas (and Brandon) that this can be changed to "perform", but keeping the reference to conditional violations if you like - but I'd change the link to this part of the blocker bug FAQ:
https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local...
which is what we usually use as the target for such references.
On Tue, May 12, 2020 at 5:56 PM Adam Williamson adamwill@fedoraproject.org wrote:
I think we don't need the weasel form in this criterion as we actually do want to block on user switching *fully working*. So I think I'd agree with Lukas (and Brandon) that this can be changed to "perform", but keeping the reference to conditional violations if you like - but I'd change the link to this part of the blocker bug FAQ:
https://fedoraproject.org/wiki/Blocker_Bug_FAQ#What_about_hardware_and_local...
which is what we usually use as the target for such references.
Thanks, Adam. That link is much better, and I'm happy to follow your advice on wording as you're our number one criterion lawyer ;-)
Here's an updated criterion proposal. I marked adjusted parts with an asterisk.
~~~~~~~~~~~~~~~~~~~~~ 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 perform* the requested operation. If the operation doesn't 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](Blocker_Bug_FAQ#What about hardware and local configuration dependent issues?)*).
Default configuration?* This is supposed to cover only cases where the system hasn't been modified in a substantial (and relevant) way. This excludes cases where people e.g. install multiple desktop environments, replace their display manager for a different one, tweak relevant systemd settings, or install a non-default graphics driver. ~~~~~~~~~~~~~~~~~~~~~~
* denotes a change in wording
On Wed, May 13, 2020 at 3:19 PM Kamil Paral kparal@redhat.com wrote:
Thanks, Adam. That link is much better, and I'm happy to follow your advice on wording as you're our number one criterion lawyer ;-)
Here's an updated criterion proposal. I marked adjusted parts with an asterisk.
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 perform* the requested operation. If the operation doesn't 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](Blocker_Bug_FAQ#What about hardware and local configuration dependent issues?)*). Default configuration?* This is supposed to cover only cases where the system hasn't been modified in a substantial (and relevant) way. This excludes cases where people e.g. install multiple desktop environments, replace their display manager for a different one, tweak relevant systemd settings, or install a non-default graphics driver.
- denotes a change in wording
Since there were no further objections, I made the criterion official: https://fedoraproject.org/wiki/Fedora_33_Final_Release_Criteria#User_switchi... https://fedoraproject.org/w/index.php?title=Fedora_33_Final_Release_Criteria...
Thanks everyone involved!
-
Adam Williamson -
Kamil Paral