Re: Freeze break exception for the new lock screen

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

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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]