Re: Freeze break exception for the new lock screen

Michael Catanzaro <mcatanzaro gnome org> 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

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


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