On Tue, Mar 17, 2020 at 2:10 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote:
On Tue, Mar 17, 2020 at 4:48 AM Kamil Paral <kparal@xxxxxxxxxx> wrote:
>
> All system services present after installation with one of the release-blocking package sets must not time out frequently or regularly when they are being stopped during system reboot/shutdown.
>
I like it generally, but I worry we'll get hung up on the definition
of "frequently" or "regularly". For shutdown in particular, I'm less
concerned with service timeouts (granted, I'm not paying for my
compute by the minute).
The problem is not in the timeout itself, but when you need to wait for it. If I do 30 system reboots a day, because I test stuff, a 90 second timeout is suddenly a lot of time :) As a regular user, when I want to shut down the computer and leave, and the system just doesn't, and I need to wait 2 minutes before it does, I get annoyed. Or when I want to reboot to a different operating system, etc. It's those cases where you wait for it, which matter.
I'm leaning toward something like
"predictably" or "reliably" (which is an awkward use of the word).
I'm all for finding better words. "Reliably" might be confusing :-) I want to cover scenarios where it covers very frequently (e.g. in 70% of shutdowns), or deterministically (e.g. for all VMs, but not bare metals), and discuss those. I think we can't go for a clear definition here that would allow us to specify an exact scenario when to block and when don't.
As an example which problems could be found and discussed, I have a suspicion that PackageKit hangs if you try to reboot the machine too early after it starts up. Likely not a blocker, because it's not a too frequent use case, but it could be discussed. Or imagine PackageKit hanging every time you perform some particular operation, like a package install. That could be a more viable candidate for a blocker.
Basically, it's not a blocker unless it does it every time.
This is probably the only exact scenario where we could make it a clear blocker, no discussion needed. But it also means no discussion possible. If we say "every time", as Frantisek proposed as well, we'll likely use this criterion once in a few years, and certainly not now against spice-vdagent. Because it doesn't time out every time, it times out every time just on VMs. That is a condition, i.e. it is not "every time".
We can have such a criterion for sure, I just think it's not that useful. I'd rather have one that gives us some leeway to discuss and decide how important the issue is. Which means including "frequently", "regularly", "predictably" or something along those lines.
_______________________________________________ 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