Re: user switching criterion proposal

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

 



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




[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux