LGTM2, even better! On Fri, Feb 24, 2023 at 5:04 PM Yoav Weiss <[email protected]> wrote:
> SGTM! > > On Fri, Feb 24, 2023 at 4:40 PM Henrik Boström <[email protected]> wrote: > >> Yes, I think throwing in M117, stable on Aug 30 would be even better. >> >> On Friday, February 24, 2023 at 4:32:21 PM UTC+1 Philip Jägenstedt wrote: >> >>> I think the overall timeline looks great, the final removal is almost a >>> year from now, after the 2023 holiday season. >>> >>> However, I'd like to bikeshed "Throw an exception if the trial is not >>> used in Stable in M119 (Release: October 31, 2023)". This is when the >>> breakage will be apparent to most users/developers, anyone who isn't paying >>> attention to deprecation warnings. Oct 31 doesn't give a whole lot of time >>> to figure out how origin trials work and opt into that, so I would suggest >>> M117, stable on Aug 30. That's as early as seems reasonable given summer >>> vacations in the northern hemisphere. >>> >>> WDYT Henrik, would that work just as well for you? >>> >>> On Thu, Feb 23, 2023 at 1:17 PM Yoav Weiss <[email protected]> wrote: >>> >>>> LGTM1 for that plan >>>> >>>> On Thu, Feb 23, 2023 at 12:48 PM Henrik Boström <[email protected]> >>>> wrote: >>>> >>>>> In that case the proposal is: >>>>> - Add deprecation warning in M113 (Release: May 2, 2023) with the >>>>> possibility to opt-in to the Deprecation Trial. >>>>> - Throw an exception if the trial is not used in Canary/Dev/Beta in >>>>> M114. >>>>> - Throw an exception if the trial is not used in Stable in M119 >>>>> (Release: October 31, 2023). >>>>> - Let M121 be the last version where the Trial is available (Release: >>>>> January 9, 2024). In other words the first version where the trial and >>>>> legacy getStats API is entirely removed is M122 (Release: February 6, >>>>> 2024). >>>>> >>>>> On Thursday, February 23, 2023 at 11:38:48 AM UTC+1 Yoav Weiss wrote: >>>>> >>>>>> SGTM >>>>>> >>>>>> On Thu, Feb 23, 2023 at 11:34 AM Henrik Boström <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Thursday, February 23, 2023 at 11:03:44 AM UTC+1 Yoav Weiss wrote: >>>>>>> >>>>>>> On Mon, Feb 20, 2023 at 12:52 PM Henrik Boström <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>> OK, so deprecation warning in M113, throwing in Beta in M114 and >>>>>>> throwing in Stable on M119. We can do that. >>>>>>> >>>>>>> >>>>>>> Awesome! >>>>>>> >>>>>>> >>>>>>> Under this less aggressive timeline, for how many more milestones >>>>>>> would the Deprecation Trial span? >>>>>>> >>>>>>> >>>>>>> How much would be needed for people to schedule the work to make the >>>>>>> switch? >>>>>>> >>>>>>> >>>>>>> If they notice the deprecation warning they would have enough time >>>>>>> to migrate before the Deprecation Trial is even needed. If they don't, >>>>>>> how >>>>>>> about 3 months extra? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> I do not have any more deprecations planned on my end and I think >>>>>>> this is "standalone" enough (stats being rather specific) that in my >>>>>>> opinion it should not be bundled together with anything else. >>>>>>> >>>>>>> >>>>>>> OK, cool! >>>>>>> >>>>>>> >>>>>>> On Friday, February 17, 2023 at 8:52:56 AM UTC+1 Yoav Weiss wrote: >>>>>>> >>>>>>> Hey Henrik! >>>>>>> >>>>>>> I think the general outline of the plan makes sense, but the >>>>>>> timelines seem too aggressive. As we've recently seen in the track stats >>>>>>> removal, there can be a time difference between the point a developer >>>>>>> puts >>>>>>> in the work to opt-in for a deprecation trial and the point in which >>>>>>> this >>>>>>> work reaches users. >>>>>>> >>>>>>> I think it would make sense to: >>>>>>> * Add a deprecation warning in M113 and enable a Deprecation Trial. >>>>>>> Set a tentative removal milestone for M119. >>>>>>> * Start throwing an exception up to Beta in M114 to try and get >>>>>>> people's attention >>>>>>> * Broadly communicate this change is coming in multiple channels. >>>>>>> DevRel folks may be able to help there. +Paul Kinlan and +Andre >>>>>>> Bandarra for thoughts. >>>>>>> * In parallel to the above, turn the usecounters into UKM >>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:components/page_load_metrics/browser/observers/use_counter/ukm_features.cc;l=14?q=usecounter%20ukm&ss=chromium>, >>>>>>> and try to see where most usage lies. (and try to understand if it's >>>>>>> coming >>>>>>> from libraries with longer deployment lifecycles) >>>>>>> * Flip the switch (and be ready to revert) in M119 >>>>>>> >>>>>>> I know this is a bit longer and more work than the plan you >>>>>>> outlined, but given the few fire drills we had recently, it seems >>>>>>> better to >>>>>>> err on the cautious side. >>>>>>> >>>>>>> Also, do you know if more removals are planned on your side? It >>>>>>> seems like it'd be better to "bundle" them so that library authors only >>>>>>> have to "respin" their deployment once, rather than every few >>>>>>> milestones. >>>>>>> >>>>>>> >>>>>>> On Thu, Feb 16, 2023 at 3:10 PM Henrik Boström <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>> *This deprecation is not to be confused with the track stats >>>>>>> deprecation >>>>>>> <https://groups.google.com/a/chromium.org/g/blink-dev/c/NZVXsJQ7tV8>, >>>>>>> which >>>>>>> is deprecating a small subset of the modern API. This deprecation >>>>>>> related >>>>>>> to the removal of the legacy API, a different API with the same name.* >>>>>>> >>>>>>> *Contact emails* >>>>>>> [email protected], [email protected] >>>>>>> >>>>>>> *Specification* >>>>>>> The legacy getStats() API has no spec, no official documentation and >>>>>>> no web platform tests. >>>>>>> >>>>>>> The modern (promise-based) version of getStats() does have a spec, >>>>>>> but this is a different method returning different stats objects: >>>>>>> https://w3c.github.io/webrtc-stats/ >>>>>>> >>>>>>> There are lots of similarities between the modern and legacy APIs, >>>>>>> including several metrics that are the same, but the stats report >>>>>>> structure >>>>>>> is different and the legacy API contains several "goog"-prefixed >>>>>>> metrics or >>>>>>> metrics that behave differently from the modern API. >>>>>>> >>>>>>> In 2019, a document was created outlining the differences between >>>>>>> the legacy and modern API >>>>>>> <https://docs.google.com/document/d/1z-D4SngG36WPiMuRvWeTMN7mWQXrf1XKZwVl3Nf1BIE/edit?usp=sharing> >>>>>>> which >>>>>>> may still be a useful resource, but for latest information we refer to >>>>>>> the >>>>>>> modern API's spec <https://w3c.github.io/webrtc-stats/> and code >>>>>>> search >>>>>>> <https://source.chromium.org/chromium/chromium/src/+/main:third_party/webrtc/api/stats/rtcstats_objects.h> >>>>>>> . >>>>>>> >>>>>>> *Summary* >>>>>>> WebRTC is a set of JavaScript APIs (spec >>>>>>> <https://w3c.github.io/webrtc-pc/>) enabling real-time >>>>>>> communication, most notably realtime audio and video for Video >>>>>>> Conferencing >>>>>>> in the browser. getStats() is an API that allow apps to measure things >>>>>>> like >>>>>>> bitrate and media quality information about the session. >>>>>>> >>>>>>> The history is that spec and implementations evolved so quickly that >>>>>>> the API was forked into two paths: the callback-based one that only >>>>>>> exists >>>>>>> in Chromium and has no spec and the promise-based one which has both a >>>>>>> spec >>>>>>> and pretty good cross-browser compatibility support >>>>>>> <https://wpt.fyi/results/webrtc-stats/supported-stats.https.html?label=experimental&label=master&aligned> >>>>>>> . >>>>>>> >>>>>>> In Chromium, the legacy API has been on feature freeze for several >>>>>>> years and the goal was always to deprecate and remove it, but due to >>>>>>> high >>>>>>> usage this was not a possibility. This story is finally changing: usage >>>>>>> graphs >>>>>>> <https://webrtchacks.github.io/chromestatus/?buckets=1058,1476,1402&start=2022-01-01&window=7> >>>>>>> . >>>>>>> >>>>>>> [image: Screenshot 2023-02-16 at 13.43.40.png] >>>>>>> >>>>>>> According to chromestatus.com stats >>>>>>> <https://chromestatus.com/metrics/feature/popularity>, >>>>>>> - RTCPeerConnectionGetStatsLegacyNonCompliant is 0.0183% and >>>>>>> - RTCPeerConnectionGetStats is 0.2177% of page loads. >>>>>>> In other words, legacy is 8% as popular as modern. >>>>>>> >>>>>>> According to UMA stats, >>>>>>> - RTCPeerConnectionGetStatsLegacyNonCompliant is 0.000177% and >>>>>>> - RTCPeerConnectionGetStats is 0.00114% of page loads. >>>>>>> In other words, legacy is 15% as popular as modern. >>>>>>> >>>>>>> I don't know why UMAs and chromestatus shows different orders of >>>>>>> magnitude when it comes to usage, but we're roughly talking about the >>>>>>> legacy API being 1/10th as popular as the modern API. I think it is >>>>>>> time to >>>>>>> add a deprecation warning to the legacy API. >>>>>>> >>>>>>> *Risks* >>>>>>> Usage is still high and migrating from the legacy API to the modern >>>>>>> API may require a significant amount of work from developers. >>>>>>> >>>>>>> To mitigate this, we should have a long deprecation timeline and >>>>>>> allow developers to opt-in to a Deprecation Trial to get more time. >>>>>>> >>>>>>> *Proposal* >>>>>>> Add a deprecation warning in M113 and the possibility to opt-in to a >>>>>>> deprecation trial. >>>>>>> Add use counts for how many of the legacy API uses do and do not use >>>>>>> the deprecation trial and track this over time. >>>>>>> >>>>>>> In M114, start throwing an exception in Canary/Beta if attempting to >>>>>>> use the legacy API outside the trial *but do not throw* in Stable >>>>>>> yet. Give apps more time to sign up to the trial. >>>>>>> >>>>>>> In M115, gently roll out the throwing of the exception to Stable, >>>>>>> i.e. from this milestone onwards apps are required to use the >>>>>>> deprecation >>>>>>> trial if they want to continue to use the legacy getStats() API. >>>>>>> >>>>>>> M115 is Stable on June 27. >>>>>>> Set the Deprecation Trial end date to M120 / December 5, 2023. >>>>>>> This gives apps paying attention to the deprecation warning ~9 >>>>>>> months to migrate and apps only paying attention to exceptions on >>>>>>> stable ~6 >>>>>>> months to migrate. >>>>>>> >>>>>>> -- >>>>>>> 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 [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/a/chromium.org/d/msgid/blink- >>>>>>> dev/8edb3ad3-c383-4c18-9595-81fb0732fa10n%40chromium.org >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8edb3ad3-c383-4c18-9595-81fb0732fa10n%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 [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXvoddJYizkHGzmavf6LLyqxY1VGLfZfW%3D%2BrmZBBHNq8Q%40mail.gmail.com >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfXvoddJYizkHGzmavf6LLyqxY1VGLfZfW%3D%2BrmZBBHNq8Q%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 [email protected]. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAARdPYfRn4nBRmfmvgJ8DFnmEZaCN_fGxqkEGsYK9z2ndyL1fQ%40mail.gmail.com.
