SGTM On Thu, Feb 23, 2023 at 11:34 AM Henrik Boström <h...@chromium.org> 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 <h...@chromium.org> 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 <paulkin...@google.com> and > +Andre > Bandarra <andre...@google.com> 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 <h...@chromium.org> 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* > h...@chromium.org, h...@chromium.org > > *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 blink-dev+unsubscr...@chromium.org. > 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 blink-dev+unsubscr...@chromium.org. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL5BFfW8A0a6ARNrvguWRH3dQwkTc5O%3DhJCr99EWEnks3Fwrfg%40mail.gmail.com.
