The "old" versions (m92-m95) are the only versions that are currently out,
so breaking for anything else would be breaking in theory only. What I am
asking for is:

   - Break 2021-11-08 to 2021-11-28, all versions.
   - Re-enable on 2021-11-29 for m92-m99. (Using m92 instead of m96 as the
   lower-bound is the "special" part of my request here.)

Jason, Yoav, wdyt?

On Tue, Nov 2, 2021 at 4:43 PM Yoav Weiss <yoavwe...@chromium.org> wrote:

> Thanks! I think it's important to have the trial break in all versions, so
> the current default OT configuration you described SGTM
>
> On Tue, Nov 2, 2021, 17:32 Jason Chase <cha...@chromium.org> wrote:
>
>> Currently, origin trials are time-bound, not version-bound. That is,
>> trial tokens contain an expiry date that applies regardless of the Chrome
>> version.
>>
>> In this case, the break in availability would be done by remote update
>> that disables the trial. We can target that update to specific Chrome
>> versions. So, it is possible to leave the trial enabled on older versions,
>> while newer versions have the break enforced, and then have the trial
>> re-enabled on all versions.
>>
>> On Tue, Nov 2, 2021 at 6:09 AM Yoav Weiss <yoavwe...@chromium.org> wrote:
>>
>>> If the current status quo is that OTs are exposed on older milestones
>>> during the time they are enabled (e.g. for users that haven't updated their
>>> browser), then from my perspective, the break in the OT's availability
>>> should not change that. (I think that's the case ATM, but not sure).
>>> If it isn't the case, changing it merits a broader discussion.
>>>
>>> On Tuesday, November 2, 2021 at 11:14:13 AM UTC+2 Elad Alon wrote:
>>>
>>>> After the break. If code could work not only for m96-m99, but rather
>>>> for m92-m99, during the calendar time of m96-m99, that would be nice. But
>>>> it's not critical. I am just thinking that the OT process is probably
>>>> intended to look more at time than actual milestones, so possibly we could
>>>> tweak the rules to reflect that? But this might be a larger discussion to
>>>> be had elsewhere, and not specifically to this feature. Up to you!
>>>>
>>>> On Tuesday, November 2, 2021 at 8:39:52 AM UTC+1 yoav...@chromium.org
>>>> wrote:
>>>>
>>>>> LGTM to break the experiment 2021-11-08 to 2021-11-28 (I'm guessing
>>>>> it's to late to aim for the 1st, apologies for not responding earlier).
>>>>> Also LGTM to experiment for 4 milestones after that, till M99,
>>>>> inclusive.
>>>>>
>>>>>
>>>>> On Thursday, October 28, 2021 at 11:38:49 PM UTC+3 Elad Alon wrote:
>>>>>
>>>>>> If 2021-11-01 is too short-notice by now, we could also do 2021-08 to
>>>>>> 2021-11-28.
>>>>>>
>>>>>> On Wednesday, October 27, 2021 at 4:08:38 PM UTC+2 Elad Alon wrote:
>>>>>>
>>>>>>> Thank you, Yoav, for this suggestion about resetting the clock. We
>>>>>>> would like to now do just that, pausing the experiment 2021-11-01 to
>>>>>>> 2021-11-21, and restarting it again on 2021-11-22. We would like to
>>>>>>> experiment for 4 milestones (96 to 99, inclusive). However, if it's
>>>>>>> possible to also have the experiment active for older milestones during
>>>>>>> this time, that would be nice, too.
>>>>>>>
>>>>>>
>>>>> Can you clarify what you mean by "during this time"? During the break,
>>>>> or after it?
>>>>>
>>>>>
>>>>>>
>>>>>>> On Friday, August 20, 2021 at 6:44:10 AM UTC+2 yoav...@chromium.org
>>>>>>> wrote:
>>>>>>>
>>>>>>>> LGTM to continue experimenting.
>>>>>>>>
>>>>>>>> Note that it might be worthwhile to stop the experiment at some
>>>>>>>> point, as that could "reset the clock" in terms of burn-in risk, and 
>>>>>>>> enable
>>>>>>>> an overall longer experimentation period.
>>>>>>>>
>>>>>>>> On Tuesday, August 17, 2021 at 3:41:14 PM UTC+2 Elad Alon wrote:
>>>>>>>>
>>>>>>>>> Thanks, Yoav.
>>>>>>>>> Yes, I intend to formally reach out to Mozilla and Apple soon.
>>>>>>>>> Agreed about strong positive signals from developers.
>>>>>>>>>
>>>>>>>>> On Tuesday, August 17, 2021 at 10:56:26 AM UTC+2
>>>>>>>>> yoav...@chromium.org wrote:
>>>>>>>>>
>>>>>>>>>> On Mon, Aug 16, 2021 at 11:42 PM 'Elad Alon' via blink-dev <
>>>>>>>>>> blin...@chromium.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> Contact emailselad...@chromium.org
>>>>>>>>>>>
>>>>>>>>>>> Explainer
>>>>>>>>>>> https://github.com/WICG/capture-handle/blob/main/README.md
>>>>>>>>>>>
>>>>>>>>>>> Specificationhttps://wicg.github.io/capture-handle/
>>>>>>>>>>>
>>>>>>>>>>> Summary
>>>>>>>>>>>
>>>>>>>>>>> We introduce a mechanism that allows an application to opt-in to
>>>>>>>>>>> exposing certain information to other applications which are
>>>>>>>>>>> video-capturing it. This allows collaboration between capturing and
>>>>>>>>>>> captured applications. For example, a VC application that's 
>>>>>>>>>>> video-capturing
>>>>>>>>>>> a tab where a presentation application lives, could expose 
>>>>>>>>>>> user-facing
>>>>>>>>>>> controls in the VC tab for navigating the presentation in the 
>>>>>>>>>>> captured tab.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Blink componentBlink>GetUserMedia>Tab
>>>>>>>>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EGetUserMedia%3ETab>
>>>>>>>>>>>
>>>>>>>>>>> TAG reviewhttps://github.com/w3ctag/design-reviews/issues/645
>>>>>>>>>>>
>>>>>>>>>>> TAG review statusPending
>>>>>>>>>>>
>>>>>>>>>>> Risks
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Interoperability and Compatibility
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Gecko: No signal
>>>>>>>>>>>
>>>>>>>>>>> WebKit: No signal
>>>>>>>>>>>
>>>>>>>>>> Have we reached out? https://bit.ly/blink-signals is not
>>>>>>>>>> required for an experiment, but may be good to reach out 
>>>>>>>>>> nevertheless.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> Web developers: No signals
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I'd say
>>>>>>>>>> https://discourse.wicg.io/t/proposal-capture-handle-bootstrap-app-collaboration-when-screensharing/5354/
>>>>>>>>>> gives you a strong positive signal..
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Reason this experiment is being extended
>>>>>>>>>>>
>>>>>>>>>>> Enthusiastic support for the feature:
>>>>>>>>>>> https://discourse.wicg.io/t/proposal-capture-handle-bootstrap-app-collaboration-when-screensharing/5354
>>>>>>>>>>> Efforts to build useful features on top of this new API are still 
>>>>>>>>>>> ongoing.
>>>>>>>>>>> Request extension m95-m97 (three months).
>>>>>>>>>>> Debuggability
>>>>>>>>>>>
>>>>>>>>>>> No DevTools support is needed.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Will this feature be supported on all six Blink platforms
>>>>>>>>>>> (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?
>>>>>>>>>>>
>>>>>>>>>>> Supported on all Desktop platforms. Not supported on any Mobile
>>>>>>>>>>> platform.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Is this feature fully tested by web-platform-tests
>>>>>>>>>>> <https://chromium.googlesource.com/chromium/src/+/master/docs/testing/web_platform_tests.md>
>>>>>>>>>>> ?No
>>>>>>>>>>>
>>>>>>>>>>> Flag nameCaptureHandle
>>>>>>>>>>>
>>>>>>>>>>> Tracking bug
>>>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1200910
>>>>>>>>>>>
>>>>>>>>>>> Launch bug
>>>>>>>>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1200907
>>>>>>>>>>>
>>>>>>>>>>> Estimated milestones
>>>>>>>>>>> OriginTrial desktop first 92
>>>>>>>>>>> OriginTrial desktop last 94Request extension m95-m97 (three
>>>>>>>>>>> months).
>>>>>>>>>>>
>>>>>>>>>>> Link to entry on the Chrome Platform Status
>>>>>>>>>>> https://www.chromestatus.com/feature/4854125411958784
>>>>>>>>>>>
>>>>>>>>>>> Links to previous Intent discussionsIntent to prototype:
>>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/yLTykllpNmI
>>>>>>>>>>> Intent to Experiment:
>>>>>>>>>>> https://groups.google.com/a/chromium.org/g/blink-dev/c/RKONugfoGwM/m/mpFizHPxAwAJ
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This intent message was generated by Chrome Platform Status
>>>>>>>>>>> <https://www.chromestatus.com/>.
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> You received this message because you are subscribed to the
>>>>>>>>>>> Google Groups "blink-dev" group.
>>>>>>>>>>>
>>>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>>>>> send an email to blink-dev+...@chromium.org.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> To view this discussion on the web visit
>>>>>>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMO6jDOMkgjL_HUMohx4hk7tbC__M53aX3NEiGxeTPfw8nJUHw%40mail.gmail.com
>>>>>>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMO6jDOMkgjL_HUMohx4hk7tbC__M53aX3NEiGxeTPfw8nJUHw%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>>>>>>>>>> .
>>>>>>>>>>>
>>>>>>>>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "blink-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to blink-dev+unsubscr...@chromium.org.
>>> To view this discussion on the web visit
>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ecba514a-77be-4f6a-b3a2-faeb56ecc7f2n%40chromium.org
>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/ecba514a-77be-4f6a-b3a2-faeb56ecc7f2n%40chromium.org?utm_medium=email&utm_source=footer>
>>> .
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAMO6jDPb0-4mhwqPRCKeCejnD1iEro0utkLr3F7xfvJ_hekQLA%40mail.gmail.com.

Reply via email to