On Thu, 2020-05-07 at 10:52 +0200, Kamil Paral wrote: > On Thu, May 7, 2020 at 8:48 AM Lukas Ruzicka <lruzicka@xxxxxxxxxx> 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_configuration_dependent_issues.3F which is what we usually use as the target for such references. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ test mailing list -- test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to test-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/test@xxxxxxxxxxxxxxxxxxxxxxx
