Make it easier to try/test different study endings

[gregglind]

Instead of 'testing.expired', do 'testing.endWith'

Semanitics:

• startup (possible)
• install if not
• end with the flag.

Problems:

• maybe it should be a list of states / commands
• how long to wait

It feels rich to drive the study with commands from a pref, but the affordance here is non obvious.

Food for thought, @motin

[motin]

I am not following the main suggestion here. Currently we have testing.expired as a convenience pref for testers to be able to not have to set firstRunTimestamp to 0 and match it with a decently short expire.days value themselves (all testing.expired does is to ensure that delayInMinutes returns 0)

I agree that we may not need this convenience pref, but adding testing.endWith to semi-simulate endings seems forced. What is the underlying motivation here?

[gregglind]

Engineers want to try endings QA wants to get to endings Expired is a “weird” ending that is set up differently by most studies Some solutions: 1 co bundled addon that has a control panel / extension page for “shield lifecycle events”. It is signed and bundled study debug 2 an observed pref that replicated some of what StudyDebug does? 3 rebuild this all in shield using prefs Maybe whatever this is ALSO does the telemetry stuff. Hm. I think I am liking plan 1. But I see how prefs might be useful from outside. Can web-ext also install two addons? Maybe this is a Peter question too?

…

On Thu, Jun 21, 2018 at 10:10 AM Fredrik Wollsén ***@***.***> wrote: I am not following the main suggestion here. Currently we have testing.expired as a convenience pref for testers to be able to not have to set firstRunTimestamp to 0 and match it with a decently short expire.days value themselves (all testing.expired does is to ensure that delayInMinutes returns 0) I agree that we may not need this convenience pref, but adding testing.endWith to semi-simulate endings seems forced. What is the underlying motivation here? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#208 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAKAj3fKhDMgY876gjqKQUt461yX9NBqks5t-7d2gaJpZM4UuAIh> .

[motin]

Related/duplicate(?): #206

[gregglind]

Proposed:

• a tool that makes it easy to have a the study in 'second run' mode, using this mechanism: A profile creator. Then we can distribute / build profiles to clone from. See WIP on a make profile tool, to support 'profile retest' flows. #245 for WIP.