As we discussed in today's blocker review meeting[1], I am presenting a draft proposal for the toggle keys. I am proposing this as a *final* criterion, but would not object to adding it as a beta criterion.
== Keyboard toggle keys ==
For all release-blocking desktops, the Caps Lock and Num Lock keys must correctly toggle the relevant behavior for the desktop and all applications. The behavior must be consistent with the displayed status on physical or virtual keyboards, where applicable.
[1] https://meetbot.fedoraproject.org/fedora-blocker-review/2019-09-30/f31-block...
On Mon, Sep 30, 2019 at 9:19 PM Ben Cotton bcotton@redhat.com wrote:
As we discussed in today's blocker review meeting[1], I am presenting a draft proposal for the toggle keys. I am proposing this as a *final* criterion, but would not object to adding it as a beta criterion.
== Keyboard toggle keys ==
For all release-blocking desktops, the Caps Lock and Num Lock keys must correctly toggle the relevant behavior for the desktop and all applications. The behavior must be consistent with the displayed status on physical or virtual keyboards, where applicable.
Sounds reasonable to me.
Yeah, I think this criteria fully and plausibly describes the requirement.
+1
Dne út 1. říj 2019 14:54 uživatel Kamil Paral kparal@redhat.com napsal:
On Mon, Sep 30, 2019 at 9:19 PM Ben Cotton bcotton@redhat.com wrote:
As we discussed in today's blocker review meeting[1], I am presenting a draft proposal for the toggle keys. I am proposing this as a *final* criterion, but would not object to adding it as a beta criterion.
== Keyboard toggle keys ==
For all release-blocking desktops, the Caps Lock and Num Lock keys must correctly toggle the relevant behavior for the desktop and all applications. The behavior must be consistent with the displayed status on physical or virtual keyboards, where applicable.
Sounds reasonable to me.
test mailing list -- test@lists.fedoraproject.org To unsubscribe send an email to test-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Mon, 2019-09-30 at 15:19 -0400, Ben Cotton wrote:
As we discussed in today's blocker review meeting[1], I am presenting a draft proposal for the toggle keys. I am proposing this as a *final* criterion, but would not object to adding it as a beta criterion.
== Keyboard toggle keys ==
For all release-blocking desktops, the Caps Lock and Num Lock keys must correctly toggle the relevant behavior for the desktop and all applications. The behavior must be consistent with the displayed status on physical or virtual keyboards, where applicable.
I think I'm on board with this; however, it'd also be good to get input from the desktop teams, as the responsibility for this ultimately falls on them. So CCing desktop@ and kde@. What do you folks think about this proposed criterion?
On Mon, Oct 7, 2019 at 5:47 PM Adam Williamson adamwill@fedoraproject.org wrote:
On Mon, 2019-09-30 at 15:19 -0400, Ben Cotton wrote:
As we discussed in today's blocker review meeting[1], I am presenting a draft proposal for the toggle keys. I am proposing this as a *final* criterion, but would not object to adding it as a beta criterion.
== Keyboard toggle keys ==
For all release-blocking desktops, the Caps Lock and Num Lock keys must correctly toggle the relevant behavior for the desktop and all applications. The behavior must be consistent with the displayed status on physical or virtual keyboards, where applicable.
I think I'm on board with this; however, it'd also be good to get input from the desktop teams, as the responsibility for this ultimately falls on them. So CCing desktop@ and kde@. What do you folks think about this proposed criterion?
I guess the proposed criterion should get adjusted per our latest discussion in blocker review meeting, i.e. this one:
16:28:24 <adamw> #agreed 1755898 - AcceptedBlocker (Final) - per list and meeting discussion of bcotton's proposed criterion, we agree in principle to block on modifier key toggling working well and consistently throughout the system, but not on the light state being correct (as that is difficult to guarantee). consequently the 'shell and apps behave differently' portion of this is accepted https://meetbot.fedoraproject.org/fedora-blocker-review/2019-10-07/f31-block...
On Wed, Oct 9, 2019 at 7:11 AM Kamil Paral kparal@redhat.com wrote:
I guess the proposed criterion should get adjusted per our latest discussion in blocker review meeting, i.e. this one:
16:28:24 <adamw> #agreed 1755898 - AcceptedBlocker (Final) - per list and meeting discussion of bcotton's proposed criterion, we agree in principle to block on modifier key toggling working well and consistently throughout the system, but not on the light state being correct (as that is difficult to guarantee). consequently the 'shell and apps behave differently' portion of this is accepted https://meetbot.fedoraproject.org/fedora-blocker-review/2019-10-07/f31-block...
Based on this, I am presenting a modified proposal:
== Keyboard toggle keys ==
For all release-blocking desktops, the Caps Lock and Num Lock keys must correctly toggle the relevant behavior for the desktop and all applications.
On Mon, Oct 28, 2019 at 4:34 PM Ben Cotton bcotton@redhat.com wrote:
On Wed, Oct 9, 2019 at 7:11 AM Kamil Paral kparal@redhat.com wrote:
I guess the proposed criterion should get adjusted per our latest
discussion in blocker review meeting, i.e. this one:
16:28:24 <adamw> #agreed 1755898 - AcceptedBlocker (Final) - per list
and meeting discussion of bcotton's proposed criterion, we agree in principle to block on modifier key toggling working well and consistently throughout the system, but not on the light state being correct (as that is difficult to guarantee). consequently the 'shell and apps behave differently' portion of this is accepted
https://meetbot.fedoraproject.org/fedora-blocker-review/2019-10-07/f31-block...
Based on this, I am presenting a modified proposal:
== Keyboard toggle keys ==
For all release-blocking desktops, the Caps Lock and Num Lock keys must correctly toggle the relevant behavior for the desktop and all applications.
I believe we should explicitly state that the light state might not match. Otherwise we'll forget about this discussion and many of us will assume the light state must match as well (and then Adam will have to use his infinite memory and dig through the archives to prove us wrong once again).
But, I wonder if we perhaps still could make it more stricter about the light indicator. The argument was that there is some hardware that doesn't allow querying or something, and that's why we can't guarantee that. Well, what if we said the light state must reflect the reality in principle, but it doesn't need to work for hardware that doesn't support necessary capabilities or is otherwise hard to work with? Because if there's a race condition that lights up the indicator randomly whenever you boot, I'd like to cover that case with the criterion. If the light state is clearly broken in software, because it's inverted on *all* keyboards out there, I'd like to cover that case with the criterion. Only with problematic hardware, I'd make it non-blocking. What do you think?
On Tue, 2019-10-29 at 13:27 +0100, Kamil Paral wrote:
On Mon, Oct 28, 2019 at 4:34 PM Ben Cotton bcotton@redhat.com wrote:
On Wed, Oct 9, 2019 at 7:11 AM Kamil Paral kparal@redhat.com wrote:
I guess the proposed criterion should get adjusted per our latest
discussion in blocker review meeting, i.e. this one:
16:28:24 <adamw> #agreed 1755898 - AcceptedBlocker (Final) - per list
and meeting discussion of bcotton's proposed criterion, we agree in principle to block on modifier key toggling working well and consistently throughout the system, but not on the light state being correct (as that is difficult to guarantee). consequently the 'shell and apps behave differently' portion of this is accepted https://meetbot.fedoraproject.org/fedora-blocker-review/2019-10-07/f31-block... Based on this, I am presenting a modified proposal:
== Keyboard toggle keys ==
For all release-blocking desktops, the Caps Lock and Num Lock keys must correctly toggle the relevant behavior for the desktop and all applications.
I believe we should explicitly state that the light state might not match. Otherwise we'll forget about this discussion and many of us will assume the light state must match as well (and then Adam will have to use his infinite memory and dig through the archives to prove us wrong once again).
Yeah, it could go in as a footnote.
But, I wonder if we perhaps still could make it more stricter about the light indicator. The argument was that there is some hardware that doesn't allow querying or something, and that's why we can't guarantee that. Well, what if we said the light state must reflect the reality in principle, but it doesn't need to work for hardware that doesn't support necessary capabilities or is otherwise hard to work with? Because if there's a race condition that lights up the indicator randomly whenever you boot, I'd like to cover that case with the criterion. If the light state is clearly broken in software, because it's inverted on *all* keyboards out there, I'd like to cover that case with the criterion. Only with problematic hardware, I'd make it non-blocking. What do you think?
I think we should ask someone with more practical knowledge about the actual issues here. Probably a kernel developer or someone at GNOME who has dealt with it before. All I know is that it's a tricky area.
-
Adam Williamson -
Ben Cotton -
Kamil Paral -
Lukas Ruzicka