In our meeting today we agreed that having testable primary selection and startup notification mechanisms (testable != bug-free) for Alpha would be part of determining whether Wayland could be switched to default in F24.
However, there are a couple other items that need addressing. Which of these should also block that decision? (Input is helpful, but note the WG needs to make a decision on these points.)
* Tablet support and protocols (I take it this is "~equivalent set to what we handle now in GNOME")
* Input methods (Needs a fix for positioning the chooser apparently?)
* On screen keyboard (This seems on a good trajectory from what Matthias said, but doesn't hurt to include.)
* Accessibility features (Michael Catanzaro mentioned a set of these taken from https://fedoraproject.org/wiki/Wayland_features#accessibility_features. However, the outlook seems not good, and IMHO we need a better story for a11y users.)
On Wed, Feb 17, 2016 at 11:45:05AM -0500, Paul W. Frields wrote:
In our meeting today we agreed that having testable primary selection and startup notification mechanisms (testable != bug-free) for Alpha would be part of determining whether Wayland could be switched to default in F24.
However, there are a couple other items that need addressing. Which of these should also block that decision? (Input is helpful, but note the WG needs to make a decision on these points.)
- Tablet support and protocols (I take it this is "~equivalent set to what we handle now in GNOME")
I'm sad to see that Output Rotation was left off this list. I'd argue that more people use Rotation than use Graphics Tablet (Wacom) input devices.
Input methods (Needs a fix for positioning the chooser apparently?)
On screen keyboard (This seems on a good trajectory from what Matthias said, but doesn't hurt to include.)
Accessibility features (Michael Catanzaro mentioned a set of these taken from https://fedoraproject.org/wiki/Wayland_features#accessibility_features. However, the outlook seems not good, and IMHO we need a better story for a11y users.)
Yes, I think it would be a shame to ship with a11y regressions.
El mié, 17-02-2016 a las 13:33 -0500, Chuck Anderson escribió:
I'm sad to see that Output Rotation was left off this list. I'd argue that more people use Rotation than use Graphics Tablet (Wacom) input devices.
Does this refer to rotated monitors? I'm +1 to blocking on that; I think we will get tons of complaints if that's not working.
-1 to blocking on tablet rotation.
Michael
On Wed, Feb 17, 2016 at 7:57 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
El mié, 17-02-2016 a las 13:33 -0500, Chuck Anderson escribió:
I'm sad to see that Output Rotation was left off this list. I'd argue that more people use Rotation than use Graphics Tablet (Wacom) input devices.
Does this refer to rotated monitors? I'm +1 to blocking on that; I think we will get tons of complaints if that's not working.
It works but only for a small subset of hardware (i.e no software implementation)
On Wed, Feb 17, 2016 at 11:57 AM, Michael Catanzaro mcatanzaro@gnome.org wrote:
El mié, 17-02-2016 a las 13:33 -0500, Chuck Anderson escribió:
I'm sad to see that Output Rotation was left off this list. I'd argue that more people use Rotation than use Graphics Tablet (Wacom) input devices.
Does this refer to rotated monitors? I'm +1 to blocking on that; I think we will get tons of complaints if that's not working.
Not working in Fedora 23 (at least on ati/radeon driven setups). https://bugzilla.redhat.com/show_bug.cgi?id=1292596
Works in Fedora 22, and Rawhide, no word on why it's broken in only 23. Not too much complaining, so it's either not that common or the hardware is uncommon.
On Wed, Feb 17, 2016 at 12:06:58PM -0700, Chris Murphy wrote:
On Wed, Feb 17, 2016 at 11:57 AM, Michael Catanzaro mcatanzaro@gnome.org wrote:
El mié, 17-02-2016 a las 13:33 -0500, Chuck Anderson escribió:
I'm sad to see that Output Rotation was left off this list. I'd argue that more people use Rotation than use Graphics Tablet (Wacom) input devices.
Does this refer to rotated monitors? I'm +1 to blocking on that; I think we will get tons of complaints if that's not working.
Not working in Fedora 23 (at least on ati/radeon driven setups). https://bugzilla.redhat.com/show_bug.cgi?id=1292596
Works in Fedora 22, and Rawhide, no word on why it's broken in only 23. Not too much complaining, so it's either not that common or the hardware is uncommon.
Just to clarify, we are now talking about display rotation in X11, not Wayland. And I've since confirmed that this X11 problem affects more than just Gnome (at least Cinnamon too). I'm stuck on Cinnamon w/software rendering right now because of this. I would really like to help get this bug fixed. Should I start bisecting Mesa packages?
On Wed, Feb 17, 2016 at 12:35 PM, Chuck Anderson cra@wpi.edu wrote:
On Wed, Feb 17, 2016 at 12:06:58PM -0700, Chris Murphy wrote:
On Wed, Feb 17, 2016 at 11:57 AM, Michael Catanzaro mcatanzaro@gnome.org wrote:
El mié, 17-02-2016 a las 13:33 -0500, Chuck Anderson escribió:
I'm sad to see that Output Rotation was left off this list. I'd argue that more people use Rotation than use Graphics Tablet (Wacom) input devices.
Does this refer to rotated monitors? I'm +1 to blocking on that; I think we will get tons of complaints if that's not working.
Not working in Fedora 23 (at least on ati/radeon driven setups). https://bugzilla.redhat.com/show_bug.cgi?id=1292596
Works in Fedora 22, and Rawhide, no word on why it's broken in only 23. Not too much complaining, so it's either not that common or the hardware is uncommon.
Just to clarify, we are now talking about display rotation in X11, not Wayland. And I've since confirmed that this X11 problem affects more than just Gnome (at least Cinnamon too). I'm stuck on Cinnamon w/software rendering right now because of this. I would really like to help get this bug fixed. Should I start bisecting Mesa packages?
I couldn't get either F22 or F24 mesa packages to work in F23 (things blew up during startup and I never got to gdm on either X or wayland).
Anyway, sorry about the possible derail: the point was that rotation on wayland is probably legitimately not blocker because it's not working on X on Fedora 23, and yet I'm not hearing stampedes. So the point may be bogus because I don't know the extent of what hardware and DE's this affects, maybe if it affected more hardware there would be a (mini) stampede.
On Wed, Feb 17, 2016 at 8:51 PM, Chris Murphy lists@colorremedies.com wrote:
On Wed, Feb 17, 2016 at 12:35 PM, Chuck Anderson cra@wpi.edu wrote:
On Wed, Feb 17, 2016 at 12:06:58PM -0700, Chris Murphy wrote:
On Wed, Feb 17, 2016 at 11:57 AM, Michael Catanzaro mcatanzaro@gnome.org wrote:
El mié, 17-02-2016 a las 13:33 -0500, Chuck Anderson escribió:
I'm sad to see that Output Rotation was left off this list. I'd argue that more people use Rotation than use Graphics Tablet (Wacom) input devices.
Does this refer to rotated monitors? I'm +1 to blocking on that; I think we will get tons of complaints if that's not working.
Not working in Fedora 23 (at least on ati/radeon driven setups). https://bugzilla.redhat.com/show_bug.cgi?id=1292596
Works in Fedora 22, and Rawhide, no word on why it's broken in only 23. Not too much complaining, so it's either not that common or the hardware is uncommon.
Just to clarify, we are now talking about display rotation in X11, not Wayland. And I've since confirmed that this X11 problem affects more than just Gnome (at least Cinnamon too). I'm stuck on Cinnamon w/software rendering right now because of this. I would really like to help get this bug fixed. Should I start bisecting Mesa packages?
I couldn't get either F22 or F24 mesa packages to work in F23 (things blew up during startup and I never got to gdm on either X or wayland).
Anyway, sorry about the possible derail: the point was that rotation on wayland is probably legitimately not blocker because it's not working on X on Fedora 23, [...]
"not working for you" != "not working"
Chuck Anderson wrote:
On Wed, Feb 17, 2016 at 11:45:05AM -0500, Paul W. Frields wrote:
In our meeting today we agreed that having testable primary selection and startup notification mechanisms (testable != bug-free) for Alpha would be part of determining whether Wayland could be switched to default in F24.
However, there are a couple other items that need addressing. Which of these should also block that decision? (Input is helpful, but note the WG needs to make a decision on these points.)
- Tablet support and protocols (I take it this is "~equivalent set to what we handle now in GNOME")
I'm sad to see that Output Rotation was left off this list. I'd argue that more people use Rotation than use Graphics Tablet (Wacom) input devices.
Input methods (Needs a fix for positioning the chooser apparently?)
On screen keyboard (This seems on a good trajectory from what Matthias said, but doesn't hurt to include.)
Accessibility features (Michael Catanzaro mentioned a set of these taken from https://fedoraproject.org/wiki/Wayland_features#accessibility_features. However, the outlook seems not good, and IMHO we need a better story for a11y users.)
Yes, I think it would be a shame to ship with a11y regressions.
"Completely agree on accessibility features. All I can offer is that on present f23 and arch, orca works fine in gnome 3.18 when wayland is used, but it's always possible there are regressions, possibly serious ones. I remember that when wayland first came on the scene accessibility wasn't working and it took a lot of work before it was. Thanks Kendell clark"
-- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
On Wed, 2016-02-17 at 15:16 -0600, kendell clark wrote:
- Accessibility features
(Michael Catanzaro mentioned a set of these taken from https://fedoraproject.org/wiki/Wayland_features#accessibility _features. However, the outlook seems not good, and IMHO we need a better story for a11y users.)
Yes, I think it would be a shame to ship with a11y regressions.
"Completely agree on accessibility features. All I can offer is that on present f23 and arch, orca works fine in gnome 3.18 when wayland is used, but it's always possible there are regressions, possibly serious ones. I remember that when wayland first came on the scene accessibility wasn't working and it took a lot of work before it was.
This discussion of "accessibilty features" is too abstract to be useful. Different people have different ideas what that means, obviously.
Orca works fine, for them most part. One feature that is not working in orca is 'mouse review', which works by injecting pointer events to remote-control an application. In the absence of global coordinates, that doesn't quite work (https://bugzilla.gnome.org/show_bug.cgi?id=710 012, https://bugzilla.gnome.org/show_bug.cgi?id=709999)
But the 'accessibility features' that are meant by the bullet point are accessx style things like beeping when a key is not held for long enough. Are you willing to block Wayland because the keyboard doesn't beep ? If you are, did you know that some of these accessibility features are broken under X, too ?
El jue, 18-02-2016 a las 09:54 -0500, Matthias Clasen escribió:
But the 'accessibility features' that are meant by the bullet point are accessx style things like beeping when a key is not held for long enough. Are you willing to block Wayland because the keyboard doesn't beep ?
I'm inclined to vote yes blocker, since I know it might be a long time before these a11y features are reimplemented otherwise (I've so far seen not much effort on Wayland a11y regressions), and I don't think that'd be good for Fedora. I'm just one vote and I want Wayland too. :)
If you are, did you know that some of these accessibility features are broken under X, too ?
Of course not, if it doesn't work under X, then making it work under Wayland should not be a blocker.
Michael
I agree with Paul, I don't think all of this needs to be finished for the alpha release, but I do think there needs to be some substantial and testable implementation for the features we decide are blockers, even if the results of those tests are "it's not working very well."
I propose that we revisit any issues that we agree are blockers, and make our go/no-go decision at the last WG meeting before the alpha freeze -- that is, two weeks from today -- based on the progress of any hero development that occurs before then.
If we decide to go, then I propose we use the standard blocker bug process to track unfinished blocker issues as automatic *beta* release blockers using the standard blocker process, and simply delay F24 beta until they are done. It's time to eliminate uncertainty and set clear expectations early on for what we will be releasing. This will incentivize developers to treat Wayland issues (such as the shrinking gnome-terminal) more seriously.
El mié, 17-02-2016 a las 11:45 -0500, Paul W. Frields escribió:
- Tablet support and protocols
(I take it this is "~equivalent set to what we handle now in GNOME")
-1 blocker, only a small minority of users need Wacom tablets, and they can skip one release. I don't think we'll be dinged too badly for this. If we're talking about iPad-style tablets (I think we're talking about Wacom tablets), then that would be an even smaller minority of users.
- Input methods
(Needs a fix for positioning the chooser apparently?)
As we discussed at the meeting, this is already testable in rawhide, so we don't need to vote on it. Rui is on top of the one remaining issue. This seems to be on track.
- On screen keyboard
(This seems on a good trajectory from what Matthias said, but doesn't hurt to include.)
+1 blocker
- Accessibility features
(Michael Catanzaro mentioned a set of these taken from https://fedoraproject.org/wiki/Wayland_features#accessibility_feat ures. However, the outlook seems not good, and IMHO we need a better story for a11y users.)
+1 blocker for the features listed on that page: sticky keys, slow keys, bounce keys, sound keys, visual bell, hover-to-click. Kendell, are there any other a11y features we should block on? Consider that we don't seem to have any developers who are experienced with a11y.
Thanks,
Michael
On Wed, Feb 17, 2016 at 7:54 PM, Michael Catanzaro mcatanzaro@gnome.org wrote:
I agree with Paul, I don't think all of this needs to be finished for the alpha release, but I do think there needs to be some substantial and testable implementation for the features we decide are blockers, even if the results of those tests are "it's not working very well."
I propose that we revisit any issues that we agree are blockers, and make our go/no-go decision at the last WG meeting before the alpha freeze -- that is, two weeks from today -- based on the progress of any hero development that occurs before then.
If we decide to go, then I propose we use the standard blocker bug process to track unfinished blocker issues as automatic *beta* release blockers using the standard blocker process, and simply delay F24 beta until they are done. It's time to eliminate uncertainty and set clear expectations early on for what we will be releasing. This will incentivize developers to treat Wayland issues (such as the shrinking gnome-terminal) more seriously.
El mié, 17-02-2016 a las 11:45 -0500, Paul W. Frields escribió:
- Tablet support and protocols (I take it this is "~equivalent set to what we handle now in
GNOME")
-1 blocker, only a small minority of users need Wacom tablets, and they can skip one release.
Why would they have to do that? The X session isn't going anywhere you can just login into X.
On Wed, 2016-02-17 at 19:57 +0100, drago01 wrote:
Why would they have to do that? The X session isn't going anywhere you can just login into X.
This is a really good point... I was thinking "how many users will we piss off if they cannot use feature XYZ," when I should have been thinking "how many users will want to stop using Wayland because feature XYZ is not implemented?" and "how serious a PR problem would this be for us if not implemented?"
Michael
On Mon, Feb 22, 2016 at 07:19:25PM -0600, Michael Catanzaro wrote:
On Wed, 2016-02-17 at 19:57 +0100, drago01 wrote:
Why would they have to do that? The X session isn't going anywhere you can just login into X.
This is a really good point... I was thinking "how many users will we piss off if they cannot use feature XYZ," when I should have been thinking "how many users will want to stop using Wayland because feature XYZ is not implemented?" and "how serious a PR problem would this be for us if not implemented?"
One of the reasons to change the default is to get more exposure and attention on Wayland so that bugs can be fixed, improvements made, etc.
However, the downside to that is there will be LESS exposure and attention paid to X11. If there are too many feature regressions in Wayland compared to X11, some users who have no choice but to run X11 to get the features they require may experience bugs that may not be fixed in a reasonable time since "everyone else has moved on and is running Wayland".
This has happened over and over again with big changes. The old stuff gets left behind. Nobody wants to work on it anymore.
I think that is one reason why there is resistence to changing the default until the new thing has feature parity with the old thing.
Chuck Anderson wrote:
On Mon, Feb 22, 2016 at 07:19:25PM -0600, Michael Catanzaro wrote:
On Wed, 2016-02-17 at 19:57 +0100, drago01 wrote:
Why would they have to do that? The X session isn't going anywhere you can just login into X.
This is a really good point... I was thinking "how many users will we piss off if they cannot use feature XYZ," when I should have been thinking "how many users will want to stop using Wayland because feature XYZ is not implemented?" and "how serious a PR problem would this be for us if not implemented?"
One of the reasons to change the default is to get more exposure and attention on Wayland so that bugs can be fixed, improvements made, etc.
However, the downside to that is there will be LESS exposure and attention paid to X11. If there are too many feature regressions in Wayland compared to X11, some users who have no choice but to run X11 to get the features they require may experience bugs that may not be fixed in a reasonable time since "everyone else has moved on and is running Wayland".
This has happened over and over again with big changes. The old stuff gets left behind. Nobody wants to work on it anymore.
I think that is one reason why there is resistence to changing the default until the new thing has feature parity with the old thing.
"hi This is true with accessibility as well, though even worse. An example of this is vte2. Some older terminal emulators use it, such as mate-terminal, lxterminal, and xfterm. There are serious accessibility issues in vte2 library which prevents orca from reading some terminal contents. This has been fixed in vte3 but when I ventured a request to have them backported the response I got was a flat and somewhat smug no. Have the other terminal emulators switch over to vte3, was my only option. Easier said than done. This is also true for gtk2.0. There are some, though fortunately not a lot, of accessibility bugs that have been fixed in gtk3, plus lots of new features. Though gtk2 is still being updated, I believe, please feel free to correct me if I'm wrong, that gtk2 is in maintenance mode. This means that some of the bugs in the mate desktop are fixable but aren't getting fixed because no one is committing a11y fixes to gtk2. It's a sad situation I'm not sure how to resolve without getting up on my soap box, which I really hate to do. So exhausting. Thanks Kendell Clark "
-- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
On Mon, 2016-02-22 at 19:59 -0600, kendell clark wrote:
option. Easier said than done. This is also true for gtk2.0. There are some, though fortunately not a lot, of accessibility bugs that have been fixed in gtk3, plus lots of new features. Though gtk2 is still being updated, I believe, please feel free to correct me if I'm wrong, that gtk2 is in maintenance mode. This means that some of the bugs in the mate desktop are fixable but aren't getting fixed because no one is committing a11y fixes to gtk2. It's a sad situation I'm not sure how to resolve without getting up on my soap box, which I really hate to do. So exhausting.
Yes, gtk2 is in maintenance mode. I won't stop anybody from fixing a11y issues in the branch. But the reality is: nobody is showing up to fix a11y issues in gtk3, so I'm not holding my breath for gtk2.
We are fixing a11y issues to the best of our abilities, but the capacity is limited. Accessibility relies on a whole stack of components (atk, at-spi2-core, at-spi2-atk,...) that are all very weakly maintained. at-spi2-core has had <10 commits in the 3.19 cycle.
Matthias Clasen wrote:
On Mon, 2016-02-22 at 19:59 -0600, kendell clark wrote:
option. Easier said than done. This is also true for gtk2.0. There are some, though fortunately not a lot, of accessibility bugs that have been fixed in gtk3, plus lots of new features. Though gtk2 is still being updated, I believe, please feel free to correct me if I'm wrong, that gtk2 is in maintenance mode. This means that some of the bugs in the mate desktop are fixable but aren't getting fixed because no one is committing a11y fixes to gtk2. It's a sad situation I'm not sure how to resolve without getting up on my soap box, which I really hate to do. So exhausting.
Yes, gtk2 is in maintenance mode. I won't stop anybody from fixing a11y issues in the branch. But the reality is: nobody is showing up to fix a11y issues in gtk3, so I'm not holding my breath for gtk2.
We are fixing a11y issues to the best of our abilities, but the capacity is limited. Accessibility relies on a whole stack of components (atk, at-spi2-core, at-spi2-atk,...) that are all very weakly maintained. at-spi2-core has had <10 commits in the 3.19 cycle. "hi
nods, this is why I've taken on the task of filing a11y bugs, to change all of that. I will say that, in my own personal opinion, and I've used both windows and osx, that despite the limited resources this is a fantastically accessible OS, especially the gui layor. If I sounded at all ungreatful, I want to dispell that right here. I want to get more interest in fixing linux a11y, including older components, not drive people away. The main problem is, I file the bugs. Once the bugs are filed, whether it gets fixed is out of my hands. I want to change that, but don't know how. I can't code, and I have so little money as to be useless in that regard. I've written about this on opensource.com, hoping to garner at least some interest, but got little but "why don't you just use windows" comments from anonymous posters. I did get a lot of encouragement though, which is how I've been able to continue without burning out. Thanks Kendell Clark
-- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
On Wed, Feb 17, 2016 at 12:54:19PM -0600, Michael Catanzaro wrote:
I agree with Paul, I don't think all of this needs to be finished for the alpha release, but I do think there needs to be some substantial and testable implementation for the features we decide are blockers, even if the results of those tests are "it's not working very well."
I propose that we revisit any issues that we agree are blockers, and make our go/no-go decision at the last WG meeting before the alpha freeze -- that is, two weeks from today -- based on the progress of any hero development that occurs before then.
If we decide to go, then I propose we use the standard blocker bug process to track unfinished blocker issues as automatic *beta* release blockers using the standard blocker process, and simply delay F24 beta until they are done. It's time to eliminate uncertainty and set clear expectations early on for what we will be releasing. This will incentivize developers to treat Wayland issues (such as the shrinking gnome-terminal) more seriously.
I think our use of the word "blocker" has taken on a meaning I didn't originally intend. This whole discussion was intended to be about go/no-go for switching the default session to Wayland. It is not about blocking the F24 release.
But otherwise, I do think we should be considering each accessibility feature on the basis of whether it is a regression from X behavior. We shouldn't block the default session switch on a non-working a11y feature which also didn't work properly in X.
El mié, 17-02-2016 a las 11:45 -0500, Paul W. Frields escribió:
- Tablet support and protocols
(I take it this is "~equivalent set to what we handle now in GNOME")
-1 blocker, only a small minority of users need Wacom tablets, and they can skip one release. I don't think we'll be dinged too badly for this. If we're talking about iPad-style tablets (I think we're talking about Wacom tablets), then that would be an even smaller minority of users.
Just Wacom AIUI, but keep in mind that a number of tablet-notebook hybrids present their touchscreens as Wacom devices.
- Input methods
(Needs a fix for positioning the chooser apparently?)
As we discussed at the meeting, this is already testable in rawhide, so we don't need to vote on it. Rui is on top of the one remaining issue. This seems to be on track.
- On screen keyboard
(This seems on a good trajectory from what Matthias said, but doesn't hurt to include.)
+1 blocker
- Accessibility features
(Michael Catanzaro mentioned a set of these taken from https://fedoraproject.org/wiki/Wayland_features#accessibility_feat ures. However, the outlook seems not good, and IMHO we need a better story for a11y users.)
+1 blocker for the features listed on that page: sticky keys, slow keys, bounce keys, sound keys, visual bell, hover-to-click. Kendell, are there any other a11y features we should block on? Consider that we don't seem to have any developers who are experienced with a11y.
On Mon, 2016-02-22 at 10:06 -0500, Paul W. Frields wrote:
I think our use of the word "blocker" has taken on a meaning I didn't originally intend. This whole discussion was intended to be about go/no-go for switching the default session to Wayland. It is not about blocking the F24 release.
We can talk about it at the next meeting; it's at least worth considering. I normally don't like delaying releases, but if we need a couple weeks more to get Wayland ready for F24 rather than pushing it off to F25... it's a major one-time event, seems reasonable to delay a bit.
Maybe it won't matter, though.
On Mon, Feb 22, 2016 at 10:52:22AM -0600, Michael Catanzaro wrote:
I think our use of the word "blocker" has taken on a meaning I didn't originally intend. This whole discussion was intended to be about go/no-go for switching the default session to Wayland. It is not about blocking the F24 release.
We can talk about it at the next meeting; it's at least worth considering. I normally don't like delaying releases, but if we need a couple weeks more to get Wayland ready for F24 rather than pushing it off to F25... it's a major one-time event, seems reasonable to delay a bit.
We're already pushed out a month from idea with F24, which in turn puts F25 into the second week of November, with an already truncated schedule. If we push _that_ back at all, we have no choice but to aim for after Thanksgiving, which in turn puts us at a very real risk of slipping F25 into January.
If we're cutting it that close, I'd much rather just go with keeping F24 as on track as possible, and aiming for Wayland in F25 in November - again, assuming that we can do it with maximum benefit and minimal fright to users. If it's really not ready, there's no shame in doing it really well in F26.
On Mon, 2016-02-22 at 18:45 -0500, Matthew Miller wrote:
If we're cutting it that close, I'd much rather just go with keeping F24 as on track as possible, and aiming for Wayland in F25 in November
- again, assuming that we can do it with maximum benefit and minimal
fright to users. If it's really not ready, there's no shame in doing it really well in F26.
OK, you're probably right, I drop this proposal.
On Mon, Feb 22, 2016 at 10:06:18AM -0500, Paul W. Frields wrote:
On Wed, Feb 17, 2016 at 12:54:19PM -0600, Michael Catanzaro wrote:
I agree with Paul, I don't think all of this needs to be finished for the alpha release, but I do think there needs to be some substantial and testable implementation for the features we decide are blockers, even if the results of those tests are "it's not working very well."
I propose that we revisit any issues that we agree are blockers, and make our go/no-go decision at the last WG meeting before the alpha freeze -- that is, two weeks from today -- based on the progress of any hero development that occurs before then.
If we decide to go, then I propose we use the standard blocker bug process to track unfinished blocker issues as automatic *beta* release blockers using the standard blocker process, and simply delay F24 beta until they are done. It's time to eliminate uncertainty and set clear expectations early on for what we will be releasing. This will incentivize developers to treat Wayland issues (such as the shrinking gnome-terminal) more seriously.
I think our use of the word "blocker" has taken on a meaning I didn't originally intend. This whole discussion was intended to be about go/no-go for switching the default session to Wayland. It is not about blocking the F24 release.
But otherwise, I do think we should be considering each accessibility feature on the basis of whether it is a regression from X behavior. We shouldn't block the default session switch on a non-working a11y feature which also didn't work properly in X.
El mié, 17-02-2016 a las 11:45 -0500, Paul W. Frields escribió:
- Tablet support and protocols
(I take it this is "~equivalent set to what we handle now in GNOME")
-1 blocker, only a small minority of users need Wacom tablets, and they can skip one release. I don't think we'll be dinged too badly for this. If we're talking about iPad-style tablets (I think we're talking about Wacom tablets), then that would be an even smaller minority of users.
Just Wacom AIUI, but keep in mind that a number of tablet-notebook hybrids present their touchscreens as Wacom devices.
correct, in the context of Wayland/GNOME/etc. the term tablet refers to a graphics/drawing tablet. A side-note here: touchscreens work already, the missing feature here is support for the stylus tools.
Cheers, Peter
- Input methods
(Needs a fix for positioning the chooser apparently?)
As we discussed at the meeting, this is already testable in rawhide, so we don't need to vote on it. Rui is on top of the one remaining issue. This seems to be on track.
- On screen keyboard
(This seems on a good trajectory from what Matthias said, but doesn't hurt to include.)
+1 blocker
- Accessibility features
(Michael Catanzaro mentioned a set of these taken from https://fedoraproject.org/wiki/Wayland_features#accessibility_feat ures. However, the outlook seems not good, and IMHO we need a better story for a11y users.)
+1 blocker for the features listed on that page: sticky keys, slow keys, bounce keys, sound keys, visual bell, hover-to-click. Kendell, are there any other a11y features we should block on? Consider that we don't seem to have any developers who are experienced with a11y.
-- Paul W. Frields http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 http://redhat.com/ - - - - http://pfrields.fedorapeople.org/ The open source story continues to grow: http://opensource.com -- desktop mailing list desktop@lists.fedoraproject.org http://lists.fedoraproject.org/admin/lists/desktop@lists.fedoraproject.org
desktop@lists.stg.fedoraproject.org
-
Chris Murphy -
Chuck Anderson -
drago01 -
kendell clark -
Matthew Miller -
Matthias Clasen -
Michael Catanzaro -
Paul W. Frields -
Peter Hutterer