On Tue, Apr 7, 2020 at 4:23 PM Ben Cotton <bcotton@xxxxxxxxxx> wrote:
On Tue, Apr 7, 2020 at 7:55 AM Lukas Ruzicka <lruzicka@xxxxxxxxxx> wrote:
>
> Yes, we are aware that suspend is hardware dependent and we might end up blocking on a particular set of hardware once we are able to identify such a set. Any ideas are welcome.
I think a "squishy" approach here might be the best option. So we
don't care which hardware specifically, but the general impact. Is it
1% of hardware? We probably don't want to block on it. Is it 10% of
hardware? That might be more compelling. Is it 100% of hardware? Yeah,
this is a blocker. Obviously we can't use specific numbers, but
focusing on the scale of the impact the idea.
Yes, this is a general approach we already have here:
"There may be times where a requirement is unmet only in a particular
configuration, such as with some keyboard layouts but not others, or if a
particular character is used in a username, password or passphrase. In
such cases, the release team should use their judgement and refer to
precedent to determine whether or not the issue should be considered to
block the release. They should consider the number of users likely to be
affected by the issue, the severity of the case when the issue is
encountered, and the ease or otherwise with which the issue can be
avoided by both informed and uninformed users."
Do we want to scope it specifically to desktop-oriented deliverables?
Suspending Workstation or the KDE Spin is probably a common use case.
Suspending Server less so. I don't expect there would be cases where
that would actually matter, since they should share the important
parts in common, but if nothing else, it reduces the number of tests
that need to be done.
I'd be in favor of limiting this just to desktop environments. But I don't know how Server/Cloud/CoreOS/IoT folks feel about suspending their machines, whether it's an important use case for them.
_______________________________________________ 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
