Re: Freeze break exception for the new lock screen

[Michael Catanzaro <mcatanzaro gnome org>]

On Tue, Jan 28, 2020 at 6:36 pm, Allan Day <aday gnome org> wrote:
> 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.

Right. If there's going to be a lot of testing, it becomes easier to 
justify the risk of the freeze break.

And landing early after freeze is very different from landing later. If 
this is going to land during the first week or two after freeze, and 
it's going to be thoroughly tested, that's probably OK. More than that, 
I would say no.

> 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.

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.

Michael