Re: Freeze break exception for the new lock screen
On Fri, Feb 14, 2020 at 1:17 PM Michael Catanzaro wrote: > On Fri, Feb 14, 2020 at 10:10 am, Allan Day wrote: > > I thought we got the freeze break. We did get it, didn't we?! > > No, you need two approvals to break the freeze, but you only received a > single approval from me. Somebody else would need to give a second > approval. > > I'm in favor of landing this. So here's your second approval ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Freeze break exception for the new lock screen
On Fri, Feb 14, 2020 at 10:10 am, Allan Day wrote: I thought we got the freeze break. We did get it, didn't we?! No, you need two approvals to break the freeze, but you only received a single approval from me. Somebody else would need to give a second approval. ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Freeze break exception for the new lock screen
Michael Catanzaro wrote: ... > > It is equally not smart to never land the things we've worked on for > > years just because we put ourselves under the pressure of yet another > > deadlne. > > So far this exception has only one of two required approvals. Do you > want to give the second approval? I thought we got the freeze break. We did get it, didn't we?! Anyway: a brief update - the lock screen work has now been merged (this is the main reference: https://gitlab.gnome.org/GNOME/gnome-shell/issues/1848 ). A bunch of testing has already happened, and we've been working through the issues that have spotted. I'll try and get more people involved in tested next week. Downstream, Fedora is planning a GNOME 3.36 test day on Thursday 20th, which will be a good opportunity to test. I do have a related freeze break request to make of the release team, but I'll start a new thread for that. Thanks, Allan ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Freeze break exception for the new lock screen
On Fri, Jan 31, 2020 at 3:22 am, Matthias Clasen wrote: It is equally not smart to never land the things we've worked on for years just because we put ourselves under the pressure of yet another deadlne. So far this exception has only one of two required approvals. Do you want to give the second approval? ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Freeze break exception for the new lock screen
On Tue, Jan 28, 2020 at 1:37 PM Allan Day wrote: > Michael Catanzaro wrote: > > > Would it be possible to arrange a freeze exception for the lock > > > screen work, so we can plan on having another week to get it merged? > > > We don't expect there to be any new strings and I'm happy to > > > coordinate with docs and marketing. > > > > Certainly possible, but it is wise? > > That is the question, and I'm not 100% sure. > > It is equally not smart to never land the things we've worked on for years just because we put ourselves under the pressure of yet another deadlne. ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Freeze break exception for the new lock screen
Thanks Allan! Since you put in the effort to create a very detailed test plan, I will give the first of two required +1s for this freeze exception, even though the code isn't quite ready yet. I suggest we allow an extra two weeks for the login screen work, until February 15 (the 3.35.91 tarball deadline). Of course, I assume the developers will go through the test plan to make sure everything is in good shape. Michael ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Freeze break exception for the new lock screen
An initial version of the test plan can be found here: https://gitlab.gnome.org/Teams/Design/os-mockups/issues/44 Allan On Wed, 29 Jan 2020 at 11:38, Allan Day wrote: > > Michael Catanzaro wrote: > ... > > There are many, many, many more like these. Sorry for sending so many > > mails to this thread, but I just happen to remember this is a > > particularly fragile portion of the codebase. ... > > Thanks, I'll try and include those in the test plan. > > I still feel that these issues are better addressed through active, > coordinated testing and bug fixing, but maybe the best thing to do > would be to reassess once the MRs are ready and we have the test plan. > The other thing we'll need is a commitment from the relevant > developers to fix any issues that come up, before the code freeze. > > Allan ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Freeze break exception for the new lock screen
Michael Catanzaro wrote: ... > There are many, many, many more like these. Sorry for sending so many > mails to this thread, but I just happen to remember this is a > particularly fragile portion of the codebase. ... Thanks, I'll try and include those in the test plan. I still feel that these issues are better addressed through active, coordinated testing and bug fixing, but maybe the best thing to do would be to reassess once the MRs are ready and we have the test plan. The other thing we'll need is a commitment from the relevant developers to fix any issues that come up, before the code freeze. Allan ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Freeze break exception for the new lock screen
From https://gitlab.gnome.org/GNOME/gnome-shell/commits/master/js/gdm, some telling examples of what could break: "If the user fails to enter their password then hits escape, we jump back to the user list, then ask again for a password in a garbled screen. this commit fixes that by skipping a retry if the operation is cancelled." "If the user clicks Not Listed? to enter ask for username mode, clicks cancel, and then attempts to log in via the user list, the user will see "Authentication failed" after correctly typing the password, and then will become stuck in an empty screen with just the gray noise background." "The Next and Sign In buttons are disabled when the username/password field is empty. However, the user can still bypass this button by pressing the enter key, leading to some odd glitches with the log in for 'Not Listed?' users." "[I]f the user is currently in the user list and the account changes to locked, we want to remove it from the list, or if the user is not in the list and the account changed to unlocked, we want to add it to the list. This fixes the case where a new user account created in gnome-control-center does not appear in the user list." "The user should be allowed to cancel if verification hasn't started yet and they're typing in their username. This commit changes the authPrompt cancel function to not ignore such requests." "Normally the user isn't allowed to proceed passed the username question until they've filled it in. To ensure this, the authprompt code desensitizes the next button when the number of characters change to zero. Unfortunately it fails to desensitize the next button up front when the entry starts out empty." "fixes a bug [...] that leads to the user session crashing when the login screen is reactivated" "If the next button ever gets set to Sign In, it won't get reset to next until the next question asked by pam. This commit ensures it gets reset to Next when asking for the username." "We currently only cancel the user verifier on reset if verifying, but that means we don't properly cancel it when asking for a username at the Not Listed screen." There are many, many, many more like these. Sorry for sending so many mails to this thread, but I just happen to remember this is a particularly fragile portion of the codebase. We're a lot more stable nowadays then we were five years ago, so hopefully it will go fine, but there are lots and lots of corner cases to test. Be careful! ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Freeze break exception for the new lock screen
On Tue, Jan 28, 2020 at 1:11 pm, Michael Catanzaro wrote: Including the login screen as well, it becomes more complicated. In the distant past we've had a *lot* of weird bugs in edge cases. E.g. type password then click cancel, select a different user, try to log in again. Does it work? Does it try to log into the wrong user account? Are the right buttons sensitive at the right times? Will need to test user switching with multiple accounts, autologin with/without LUKS password, and so forth. Don't forget to test password changing when the account is set to require a new password during next login. I forgot timed login. Please check with halfline and Florian when developing the test matrix... I'm probably missing even more. ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Freeze break exception for the new lock screen
Michael Catanzaro wrote: > > Would it be possible to arrange a freeze exception for the lock > > screen work, so we can plan on having another week to get it merged? > > We don't expect there to be any new strings and I'm happy to > > coordinate with docs and marketing. > > Certainly possible, but it is wise? That is the question, and I'm not 100% sure. I certainly share the concern about landing big features late, but it obviously depends on what the time buys us. What do we lose if we delay by a week? Do we expect 3.35.90 to get more widescale testing than master? My own feeling is that our confidence in the code and our ability to do rounds of testing and fixing prior to merge are potentially the most important factors in ensuring quality. Landing a big change right before UI freeze and walking away is probably worse than landing something late, but doing plenty of testing and fixing, and having a plan in place for post-merge testing. ... > Then again, at least it's not the login screen. Unlock dialog is > simpler. The changes affect both unlock and login. ... > If we do a freeze exception, we'll want to test: > > * Automatic lock after delay > * Manual lock with Ctrl+L > * Fingerprint unlock > * Smartcard or OTP unlock > * (What more am I forgetting?) The testing matrix for login and unlock is potentially large, although I'm not sure that all these features are touched by the redesign. If we go ahead I can commit to coming up with a feature list and a test plan. Allan ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
Re: Freeze break exception for the new lock screen
On Tue, Jan 28, 2020 at 12:08 pm, Allan Day wrote: Would it be possible to arrange a freeze exception for the lock screen work, so we can plan on having another week to get it merged? We don't expect there to be any new strings and I'm happy to coordinate with docs and marketing. Certainly possible, but it is wise? Making big changes to the shell late in the release cycle has high risk of regressions, and we need to be focusing on release quality. That merge request is huge. And having spent a couple weeks in an old fork of the login/unlock dialog a few years ago trying to fix simple bugs, I'm terrified of any changes. Then again, at least it's not the login screen. Unlock dialog is simpler. Florian, what do you think? If we do a freeze exception, we'll want to test: * Automatic lock after delay * Manual lock with Ctrl+L * Fingerprint unlock * Smartcard or OTP unlock * (What more am I forgetting?) Michael ___ release-team@gnome.org https://mail.gnome.org/mailman/listinfo/release-team Release-team lurker? Do NOT participate in discussions.
