Hello,
we're discussing a release criterion which is tightly related to GNOME and KDE environments. Could your teams please provide some feedback on the proposed criterion update, see below? Is user switching something you believe should be working (and in which milestone?), or should we rather de-emphasize/remove that function?
Please respond to the test@ list, if possible, to avoid fragmenting the discussion.
Thanks!
----- Original Message -----
Hello,
yesterday we have discussed whether user switching should be included in our criteria. We agreed that Beta is a good target for it, and accepted this bug as a blocker:
https://bugzilla.redhat.com/show_bug.cgi?id=1184933 https://bugzilla.gnome.org/show_bug.cgi?id=719418
Now we need to adjust this criterion: https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria#Shutdown.2C_r... Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops. Work? [hide] Similar to the Alpha criterion for shutting down, shutdown and reboot mechanisms must take storage volumes down cleanly and correctly request a shutdown or reboot from the system firmware. Logging out must return the user to the environment from which they logged in, working as expected.
I propose this change: title: Shutdown, reboot, logout, switch Shutting down, rebooting, logging out and user switching must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops. Work? [hide] Similar to the Alpha criterion for shutting down, shutdown and reboot mechanisms must take storage volumes down cleanly and correctly request a shutdown or reboot from the system firmware. Logging out must return the user to the environment from which they logged in, working as expected. User switching must allow multiple users to perform live switching between their sessions, working as expected.
What do you think?
On Wed, 2015-01-28 at 07:51 -0500, Kamil Paral wrote:
Hello,
we're discussing a release criterion which is tightly related to GNOME and KDE environments. Could your teams please provide some feedback on the proposed criterion update, see below? Is user switching something you believe should be working (and in which milestone?), or should we rather de-emphasize/remove that function?
Please respond to the test@ list, if possible, to avoid fragmenting the discussion.
Thanks!
----- Original Message -----
Hello,
yesterday we have discussed whether user switching should be included in our criteria. We agreed that Beta is a good target for it, and accepted this bug as a blocker:
https://bugzilla.redhat.com/show_bug.cgi?id=1184933 https://bugzilla.gnome.org/show_bug.cgi?id=719418
Now we need to adjust this criterion: https://fedoraproject.org/wiki/Fedora_22_Beta_Release_Criteria#Shutdown.2C_r... Shutting down, logging out and rebooting must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops. Work? [hide] Similar to the Alpha criterion for shutting down, shutdown and reboot mechanisms must take storage volumes down cleanly and correctly request a shutdown or reboot from the system firmware. Logging out must return the user to the environment from which they logged in, working as expected.
I propose this change: title: Shutdown, reboot, logout, switch Shutting down, rebooting, logging out and user switching must work using standard console commands and the mechanisms offered (if any) by all release-blocking desktops. Work? [hide] Similar to the Alpha criterion for shutting down, shutdown and reboot mechanisms must take storage volumes down cleanly and correctly request a shutdown or reboot from the system firmware. Logging out must return the user to the environment from which they logged in, working as expected. User switching must allow multiple users to perform live switching between their sessions, working as expected.
What do you think?
I think user switching is much less important than the other things on your list (login, shutdown, reboot) - if user switching is broken, the majority of our users won't even notice because they are on single-user systems.
Testing it is fine of course, but I don't really think we should block on this. Also worth considering: user switching has never worked 100% reliably, so increased qa focus may just uncover old heisenbugs, and turn them into blocking issues.
Matthias Clasen wrote: I think user switching is much less important than the other things on your list (login, shutdown, reboot)
I agree it's not as important as shutdown, but the question is whether it's important enough to be considered "basic functionality" and we block the release when it's broken heavily.
For example, by our current standards, gnome-calculator must work or we do not ship: https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria#Default_appl... We also don't ship when we don't have high-contrast icons for all apps, or when we miss some artwork.
All of that is probably not as important as shutdown working, but still forms some kind of basis which needs to work.
Btw, I just realized that it could be argued that user switching is already covered by this criterion: https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria#Default_pane... but it's good we're having this discussion, at least we can clarify this.
if user switching is broken, the majority of our users won't even notice because they are on single-user systems.
It's hard to make some estimates here, but judging by my surroundings, single user systems are very common for us IT geeks, but do not necessarily represent Fedora's larger audience. On my home laptop, I have user profiles for me and for my girlfriend (my account is mostly logged in when the laptop gets suspended), and I need her to be able to use it even when I'm not around to manually switch VTs. My dad's laptop has user profiles for him and my mom. And even I have a guest account on my work laptop when I need to lend it to someone for a minute, I guess that's also a very common use case.
It seems to me that family usage is the most commonly mentioned scenario when I see people complaining about this feature being broken.
Testing it is fine of course, but I don't really think we should block on this.
Do you mean not block on it even for Final, i.e. at all, or Beta?
What I see as a problem is that any serious bugs [1] cut off multi-user usage of that system almost completely. I feel that we're losing a really big part of our audience this way. And now that we have Fedora Workstation product (and the KDE spin) with its more targeted focus on a specific user base, it would be a real pity to sacrifice those people.
Also worth considering: user switching has never worked 100% reliably, so increased qa focus may just uncover old heisenbugs, and turn them into blocking issues.
It that a bad thing or a good thing? Could this be a worthy goal for F22? It's still pretty early in the cycle. Or if you think it's too late, does it make sense to target this for F23? Is it about technical complexity, or is there no will/manpower to maintain this? (Since this is one of my painful issues with GNOME, I can promise you some QA time from my side:)).
Thanks, Kamil
On Thu, Jan 29, 2015 at 4:23 AM, Kamil Paral kparal@redhat.com wrote:
I agree it's not as important as shutdown, but the question is whether it's important enough to be considered "basic functionality" and we block the release when it's broken heavily.
I'm pretty sure that if user switching doesn't work reliably, users should find a better OS to use, so I'd rather block on it....
At the same time, our blocker criteria are generally interpreted to apply to common bugs. If user switching is broken for one guy with an obscure setup, that shouldn't be a blocker.
On Thu, Jan 29, 2015 at 9:41 AM, Michael Catanzaro mcatanzaro@gnome.org wrote:
On Thu, Jan 29, 2015 at 4:23 AM, Kamil Paral kparal@redhat.com wrote:
I agree it's not as important as shutdown, but the question is whether it's important enough to be considered "basic functionality" and we block the release when it's broken heavily.
I'm pretty sure that if user switching doesn't work reliably, users should find a better OS to use, so I'd rather block on it....
At the same time, our blocker criteria are generally interpreted to apply to common bugs. If user switching is broken for one guy with an obscure setup, that shouldn't be a blocker.
Is there a particularly strong use case for user switching when booted from live media? If not, can't this be fixed with an update?
At the same time, our blocker criteria are generally interpreted to apply to common bugs. If user switching is broken for one guy with an obscure setup, that shouldn't be a blocker.
Yes, that's how release criteria usually work. It needs to be a general problem affecting everybody or a large part of the audience (best guesses applied here). We usually don't block on obscure setups, unless it has e.g. catastrophic consequences (severe data loss, etc).
Is there a particularly strong use case for user switching when booted from live media? If not, can't this be fixed with an update?
Release criteria affect more things than just those which are important for LiveCD usage and/or can't be updated. For example, keyring functionality is not too much useful on LiveCD, it can be updated post-install, yet it has to work on the release day. The same goes for lot of apps which you're not likely to use from LiveCD, e.g. gnome-documents, gnome-contacts, etc.
But it's true that software which can be updated post-release gets lower severity when discussing the impact of the bugs (especially when it's not a general issue affecting everybody, but just a part of Fedora user base). The same would apply here, the point is not to block on obscure bugs but to block on widespread bugs.
I agree with Matthias, user switching isn't worth considering a blocker. Besides, even if broken, it can easily be fixed by subsequent updates.
I proposed this criterion because history shows that the approach you mention (let's fix it with updates) didn't really work, at least for GNOME. So I'm trying something else, to make sure it gets the attention I believe it deserves. (We reached the same conclusion during our blocker bug review). It seems that people opinions on importance of this feature vary wildly, which is unfortunate. If we don't reach consensus, it can't be a criterion.
A thing to consider - if we know user switching is completely broken (not just broken in some use cases or for someone, but completely broken), are we OK with releasing Fedora like that? Should that feature deserve a prominent position in the system/user menu, if we're not willing to guarantee at least basic correctness?
In that case we would probably need to specify an explicit exemption for user switching in https://fedoraproject.org/wiki/Fedora_22_Final_Release_Criteria#Default_pane... . Please note the description box below the criterion where it says: # The key question is "would this bug cause significant inconvenience or just a really bad first impression to a typical user or reviewer of the release?"
On Fri, Jan 30, 2015 at 6:50 AM, Kamil Paral kparal@redhat.com wrote:
I proposed this criterion because history shows that the approach you mention (let's fix it with updates) didn't really work, at least for GNOME. So I'm trying something else, to make sure it gets the attention I believe it deserves. (We reached the same conclusion during our blocker bug review). It seems that people opinions on importance of this feature vary wildly, which is unfortunate. If we don't reach consensus, it can't be a criterion.
Extremely basic functionality of the desktop environment, like user switching, is much more important than a bug with any individual application. If we don't want to block on user switching, then it's time to take a look at the existing blocker criteria and start some significant trimming, since we currently block for less important-issues. Do we want to have more quality criteria or fewer? I'm of the opinion that we should have more if we want to expand the audience of Fedora Workstation beyond those who are currently using it. When deciding whether something is a blocker, I propose this question: "If feature X doesn't work, would a reasonable user new to Fedora switch back to his previous OS?" If there's a bug with GNOME Calculator, probably not, but if user switching doesn't work and I have multiple user accounts, then it's time to find a better distro.
Michael
On 30 Jan 2015 15:37, "Michael Catanzaro" mcatanzaro@gnome.org wrote:
When deciding whether something is a blocker, I propose this question:
"If feature X doesn't work, would a reasonable user new to Fedora switch back to his previous OS?" If there's a bug with GNOME Calculator, probably not, but if user switching doesn't work and I have multiple user accounts, then it's time to find a better distro.
Yep, I concur. I'd classify reliable suspend/wake as similarly important, for the same reasons. I understand that can be tricky depending upon the hardware, but it's fundamental when, for example, carrying a laptop around the office.
R
On Fri, Jan 30, 2015 at 11:41 AM, Richard Turner rjt@zygous.co.uk wrote:
On 30 Jan 2015 15:37, "Michael Catanzaro" mcatanzaro@gnome.org wrote:
When deciding whether something is a blocker, I propose this question: "If feature X doesn't work, would a reasonable user new to Fedora switch back to his previous OS?" If there's a bug with GNOME Calculator, probably not, but if user switching doesn't work and I have multiple user accounts, then it's time to find a better distro.
Yep, I concur. I'd classify reliable suspend/wake as similarly important, for the same reasons. I understand that can be tricky depending upon the hardware, but it's fundamental when, for example, carrying a laptop around the office.
I agree S/R is important, but the scope needs to be contained. Without a specific reference platform or two, the hardware combinations are too varied. We'll never get anywhere near 100% reliability or coverage on this, and debugging these issues remotely is a major time sink for possible little gain in the larger picture.
josh
On Fri, 2015-01-30 at 09:37 -0600, Michael Catanzaro wrote:
On Fri, Jan 30, 2015 at 6:50 AM, Kamil Paral kparal@redhat.com wrote:
I proposed this criterion because history shows that the approach you mention (let's fix it with updates) didn't really work, at least for GNOME. So I'm trying something else, to make sure it gets the attention I believe it deserves. (We reached the same conclusion during our blocker bug review). It seems that people opinions on importance of this feature vary wildly, which is unfortunate. If we don't reach consensus, it can't be a criterion.
Extremely basic functionality of the desktop environment, like user switching, is much more important than a bug with any individual application. If we don't want to block on user switching, then it's time to take a look at the existing blocker criteria and start some significant trimming, since we currently block for less important-issues. Do we want to have more quality criteria or fewer? I'm of the opinion that we should have more if we want to expand the audience of Fedora Workstation beyond those who are currently using it. When deciding whether something is a blocker, I propose this question: "If feature X doesn't work, would a reasonable user new to Fedora switch back to his previous OS?" If there's a bug with GNOME Calculator, probably not, but if user switching doesn't work and I have multiple user accounts, then it's time to find a better distro.
It is not really relevant if something is 'basic' or not. To decide whether to block on a bug, you should look at:
1) How many users are affected ? 2) How significantly is their use of the system affected ? 3) Is there an easy workaround ?
In all of these, user switching is just not in the same league as logout or shutdown.
Having more criteria is good if you have too many qa people who can't figure out how to spend their time.
On Fri, Jan 30, 2015 at 11:57 AM, Matthias Clasen mclasen@redhat.com wrote:
On Fri, 2015-01-30 at 09:37 -0600, Michael Catanzaro wrote:
On Fri, Jan 30, 2015 at 6:50 AM, Kamil Paral kparal@redhat.com wrote:
I proposed this criterion because history shows that the approach you mention (let's fix it with updates) didn't really work, at least for GNOME. So I'm trying something else, to make sure it gets the attention I believe it deserves. (We reached the same conclusion during our blocker bug review). It seems that people opinions on importance of this feature vary wildly, which is unfortunate. If we don't reach consensus, it can't be a criterion.
Extremely basic functionality of the desktop environment, like user switching, is much more important than a bug with any individual application. If we don't want to block on user switching, then it's time to take a look at the existing blocker criteria and start some significant trimming, since we currently block for less important-issues. Do we want to have more quality criteria or fewer? I'm of the opinion that we should have more if we want to expand the audience of Fedora Workstation beyond those who are currently using it. When deciding whether something is a blocker, I propose this question: "If feature X doesn't work, would a reasonable user new to Fedora switch back to his previous OS?" If there's a bug with GNOME Calculator, probably not, but if user switching doesn't work and I have multiple user accounts, then it's time to find a better distro.
It is not really relevant if something is 'basic' or not. To decide whether to block on a bug, you should look at:
- How many users are affected ?
- How significantly is their use of the system affected ?
- Is there an easy workaround ?
In all of these, user switching is just not in the same league as logout or shutdown.
Having more criteria is good if you have too many qa people who can't figure out how to spend their time.
I absolutely agree here. Thanks for summing this up Matthias. I was having a hard time doing so.
josh
desktop@lists.fedoraproject.org
-
Chris Murphy -
Josh Boyer -
Kamil Paral -
Matthias Clasen -
Michael Catanzaro -
Richard Turner