Intent To Ship: Provide network quality estimates to web servers via Client Hints

[Tarun Bansal]

Intent To Ship: Provide network quality estimates to web servers via Client Hints

Contact emails

tba...@chromium.org, igri...@chromium.org, be...@chromium.org,

Explainer

https://github.com/WICG/netinfo/issues/46#issuecomment-276804272

Spec

NetInfo spec: https://wicg.github.io/netinfo/

WICG thread: https://discourse.wicg.io/t/proposal-netinfo-provide-effective-network-speed-expose-save-data/1980

Summary:

This is a proposal to ship three new client hints (and corresponding three HTTP request headers) to convey the HTTP client's network connection speed. The headers will be sent individually, and will be sent only to hosts that opt in to receiving them using the existing client hints mechanism. The headers will surface the same data as the Network Information API to make it easy to make network speed-related decisions. The three new headers are “rtt”, “downlink” and “ect” and they provide the same value as existing NetInfo APIs (navigator.connection.rtt, navigator.connection.downlink and navigator.connection.effectiveType, respectively).

Link to “Intent to Implement” blink-dev discussion

Intent to implement: https://groups.google.com/a/chromium.org/d/topic/blink-dev/TS9zT_u2M4k/discussion

(Related) Intent to ship for NetInfo JavaScript API: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/UVfNMH50aaQ/XQiWq35WCAAJ

(Related) Intent to ship for client hints: https://groups.google.com/a/chromium.org/d/topic/blink-dev/8RBFue7RMXQ/discussion

Motivation:

See explainer for detailed motivation.

Web servers and proxies benefit, because they can tailor content to network constraints. For example, on very slow networks, a simplified version of the page can be provided to improve document load and first paint times. Users benefit by being offered only that content that they can consume given network constraints, which results in faster paints, and less frustration.

Providing network quality as a client hint allows origins to adapt the HTML content of the webpage immediately without incurring an extra RTT from querying the JavaScript API.

Interoperability and Compatibility Risk:

Low. Opt-in header and extension to existing client hints mechanism and NetInfo API.

Activation

Activating this feature should be straightforward since the web servers simply need to add couple of more attributes (e.g., “rtt”, “downlink”, “ect” or their combination) to the existing Accept-CH header.

Ongoing technical constraints:

None.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

Demo link

https://bit.ly/client-hints-demo

Debuggability

The network quality estimates are also exposed via chrome://net-internals. Developers can use net-internals, in a local environment to better understand the behavior of the estimation process: open Events tab and look for “network_quality_estimator” records. Developers can also override the network quality estimate using the Chrome switch “force-effective-connection-type” which can be set from chrome://flags or as a command line switch.

Requesting Approval to Ship?

Yes.

OWP launch tracking bug:

https://bugs.chromium.org/p/chromium/issues/detail?id=826950

Is this feature fully tested by web-platform-tests? Link to test suite results from wpt.fyi.

There are existing tests for NetInfo JavaScript API (https://wpt.fyi/netinfo)  as well as client hints (https://wpt.fyi/client-hints).  We need to add these rtt, downlink and ect client hints to the existing client hints test suite. Tracking bug: https://bugs.chromium.org/p/chromium/issues/detail?id=835333

Entry on the feature dashboard

https://www.chromestatus.com/feature/5407907378102272

[Anne van Kesteren]

On Fri, Apr 20, 2018 at 7:11 PM, Tarun Bansal <tba...@chromium.org> wrote:
> NetInfo spec: https://wicg.github.io/netinfo/

As I understand from https://github.com/whatwg/fetch/issues/707 none
of this is defined in detail. And since these are new request headers
it's also unclear how they interact with the same-origin policy.
What's the plan here?


--
https://annevankesteren.nl/

[Tarun Bansal]

The plan is to update the fetch spec and the Blink implementation to handle the new headers. Plan here (thanks Yoav!): https://github.com/whatwg/fetch/issues/707#issuecomment-383874881

As far as the same origin policy is concerned, these headers should be treated similar to other currently existing client hints headers (dpr, width etc.). We plan to update the fetch spec to add the new headers: https://fetch.spec.whatwg.org/#terminology-headers, and then update the Blink implementation to conform with the spec.

[Yoav Weiss]

On Tue, Apr 24, 2018 at 7:07 PM Tarun Bansal <tba...@chromium.org> wrote:

The plan is to update the fetch spec and the Blink implementation to handle the new headers. Plan here (thanks Yoav!): https://github.com/whatwg/fetch/issues/707#issuecomment-383874881

As far as the same origin policy is concerned, these headers should be treated similar to other currently existing client hints headers (dpr, width etc.). We plan to update the fetch spec to add the new headers: https://fetch.spec.whatwg.org/#terminology-headers, and then update the Blink implementation to conform with the spec.

To be clear: you're planning to go ahead with the spec changes before shipping?

[Yoav Weiss]

On Thu, Apr 26, 2018 at 8:34 AM Yoav Weiss <yo...@yoav.ws> wrote:

On Tue, Apr 24, 2018 at 7:07 PM Tarun Bansal <tba...@chromium.org> wrote:

The plan is to update the fetch spec and the Blink implementation to handle the new headers. Plan here (thanks Yoav!): https://github.com/whatwg/fetch/issues/707#issuecomment-383874881

As far as the same origin policy is concerned, these headers should be treated similar to other currently existing client hints headers (dpr, width etc.). We plan to update the fetch spec to add the new headers: https://fetch.spec.whatwg.org/#terminology-headers, and then update the Blink implementation to conform with the spec.

To be clear: you're planning to go ahead with the spec changes before shipping?

Just had a chat with Tarun and he agreed to go ahead with the relevant Fetch spec changes, adding the new headers to the Client Hints list as well as the CORS-safelisted request header list.

So LGTM1, pending on said spec changes.

[Philip Jägenstedt]

On Thu, May 3, 2018 at 4:05 PM Yoav Weiss <yo...@yoav.ws> wrote:

On Thu, Apr 26, 2018 at 8:34 AM Yoav Weiss <yo...@yoav.ws> wrote:

On Tue, Apr 24, 2018 at 7:07 PM Tarun Bansal <tba...@chromium.org> wrote:

The plan is to update the fetch spec and the Blink implementation to handle the new headers. Plan here (thanks Yoav!): https://github.com/whatwg/fetch/issues/707#issuecomment-383874881

As far as the same origin policy is concerned, these headers should be treated similar to other currently existing client hints headers (dpr, width etc.). We plan to update the fetch spec to add the new headers: https://fetch.spec.whatwg.org/#terminology-headers, and then update the Blink implementation to conform with the spec.

To be clear: you're planning to go ahead with the spec changes before shipping?

Just had a chat with Tarun and he agreed to go ahead with the relevant Fetch spec changes, adding the new headers to the Client Hints list as well as the CORS-safelisted request header list.

So LGTM1, pending on said spec changes.

Tarun, will you ping the intent when https://github.com/whatwg/fetch/issues/707#issuecomment-383874881 is resolved, or is this blocked on API owners in some other way?

[Tarun Bansal]

Hi Philip,

Thanks for poking this thread.

https://github.com/whatwg/fetch/issues/707#issuecomment-383874881 describes our overall plan, and we would be working on that in the immediate future. I had an offline discussion with Ilya and Yoav (see Yoav's comment above). From the overall plan, the blocker for this specific intent is adding RTT, ECT, Downlink headers to the CORS-safelisted list, and the Client Hints list.  Once that blocker has been resolved, I will ping back this intent.

[Anne van Kesteren]

On Wed, May 9, 2018 at 6:21 PM, Tarun Bansal <tba...@chromium.org> wrote:
> https://github.com/whatwg/fetch/issues/707#issuecomment-383874881 describes
> our overall plan, and we would be working on that in the immediate future. I
> had an offline discussion with Ilya and Yoav (see Yoav's comment above).
> From the overall plan, the blocker for this specific intent is adding RTT,
> ECT, Downlink headers to the CORS-safelisted list, and the Client Hints
> list. Once that blocker has been resolved, I will ping back this intent.

I'd rather you consider the whole plan a blocker as otherwise the
feature is still underdefined and other implementations would have to
resort to reverse engineering.


--
https://annevankesteren.nl/

[Yoav Weiss]

Tackling the whole plan seems high priority, and talking to Tarun, he is planning to do that soon.

However, it doesn't seem fair nor related to block this intent on the overall plan for Client-Hints spec improvements.

So from my perspective, this intent is blocked only on the spec changes I outlined in a previous comment.

[Anne van Kesteren]

On Fri, May 11, 2018 at 8:05 AM, Yoav Weiss <yo...@yoav.ws> wrote:
> However, it doesn't seem fair nor related to block this intent on the
> overall plan for Client-Hints spec improvements.

These are not improvements. Chromium fundamentally changed how client
hints worked and nobody updated the specification to reflect that so
other implementers could follow along.

This feels very similar to rel=preload shipping without the
infrastructure being defined. Something we're still dealing with
today. Given it's mostly the same people that are involved "seems high
priority" doesn't seem like enough of a guarantee it will actually get
fixed.


--
https://annevankesteren.nl/

[Yoav Weiss]

On Thursday, May 3, 2018 at 4:05:18 PM UTC+2, Yoav Weiss wrote:

On Thu, Apr 26, 2018 at 8:34 AM Yoav Weiss <yo...@yoav.ws> wrote:

On Tue, Apr 24, 2018 at 7:07 PM Tarun Bansal <tba...@chromium.org> wrote:

The plan is to update the fetch spec and the Blink implementation to handle the new headers. Plan here (thanks Yoav!): https://github.com/whatwg/fetch/issues/707#issuecomment-383874881

As far as the same origin policy is concerned, these headers should be treated similar to other currently existing client hints headers (dpr, width etc.). We plan to update the fetch spec to add the new headers: https://fetch.spec.whatwg.org/#terminology-headers, and then update the Blink implementation to conform with the spec.

To be clear: you're planning to go ahead with the spec changes before shipping?

Just had a chat with Tarun and he agreed to go ahead with the relevant Fetch spec changes, adding the new headers to the Client Hints list as well as the CORS-safelisted request header list.

So LGTM1, pending on said spec changes.

I'm now getting involved in related spec changes so would like to recuse myself from the decision here, and withdraw my previous LGTM.

[ywe...@akamai.com]

On Thursday, May 3, 2018 at 4:05:18 PM UTC+2, Yoav Weiss wrote:

On Thu, Apr 26, 2018 at 8:34 AM Yoav Weiss <yo...@yoav.ws> wrote:

On Tue, Apr 24, 2018 at 7:07 PM Tarun Bansal <tba...@chromium.org> wrote:

The plan is to update the fetch spec and the Blink implementation to handle the new headers. Plan here (thanks Yoav!): https://github.com/whatwg/fetch/issues/707#issuecomment-383874881

As far as the same origin policy is concerned, these headers should be treated similar to other currently existing client hints headers (dpr, width etc.). We plan to update the fetch spec to add the new headers: https://fetch.spec.whatwg.org/#terminology-headers, and then update the Blink implementation to conform with the spec.

To be clear: you're planning to go ahead with the spec changes before shipping?

Just had a chat with Tarun and he agreed to go ahead with the relevant Fetch spec changes, adding the new headers to the Client Hints list as well as the CORS-safelisted request header list.

So LGTM1, pending on said spec changes.

I'm now getting involved in related spec changes, so would like to recuse myself from making a decision here, and withdraw my LGTM.

[Rick Byers]

We (Ojan, Yoav, Alex, Daniel, Rick) discussed this intent in the API owners meeting today.  We agree with Anne's perspective that it's the responsibility of the chromium project to ensure we're precisely defining (via spec and test PRs) the behavior we're shipping, and therefore it's reasonable to block this intent on doing that (not just ask that people trust we'll get to it eventually).  Thank you for raising your concern around this Anne!

It seems likely that there's going to be a bunch of debate more on the editorial side (eg. which changes belong in fetch spec vs. html spec) and with minor details which are unlikely to results in real-world interop problems in practice, and that it's unlikely to be worth the cost to block shipping this feature on all of those questions. So the API owners expect we will be approving this intent based on unlanded pull requests we judge to be of sufficient quality.  Yoav expects that he can get the PRs to this state in plenty of time to revisit this intent ahead of the M69 branch (July 19), and so this will ultimately translate into slipping this feature by one milestone as a result of these concerns.

Rick

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/a407fd25-9282-4235-91b8-9e4dbd57eaf4%40chromium.org.

[Yoav Weiss]

On Thu, May 24, 2018 at 8:51 PM Rick Byers <rby...@chromium.org> wrote:

We (Ojan, Yoav, Alex, Daniel, Rick) discussed this intent in the API owners meeting today.  We agree with Anne's perspective that it's the responsibility of the chromium project to ensure we're precisely defining (via spec and test PRs) the behavior we're shipping, and therefore it's reasonable to block this intent on doing that (not just ask that people trust we'll get to it eventually).  Thank you for raising your concern around this Anne!

It seems likely that there's going to be a bunch of debate more on the editorial side (eg. which changes belong in fetch spec vs. html spec) and with minor details which are unlikely to results in real-world interop problems in practice, and that it's unlikely to be worth the cost to block shipping this feature on all of those questions. So the API owners expect we will be approving this intent based on unlanded pull requests we judge to be of sufficient quality.  Yoav expects that he can get the PRs to this state in plenty of time to revisit this intent ahead of the M69 branch (July 19), and so this will ultimately translate into slipping this feature by one milestone as a result of these concerns.

Those unlanded PRs are now ready for review:

https://github.com/whatwg/fetch/pull/725 - Tarun's PR, which adds the new hints to the list.

https://github.com/whatwg/fetch/pull/773 - which aligns the spec with the implementation and initializes Fetch's client-hints list with the environment settings object one.

https://github.com/whatwg/html/pull/3774 - which defines the ACHL cache, ACH and ACHL response header parsing and creates a new client-hints list on the environment settings object. It also defines the processing of the http-equiv header equivalents.

Reviewing the WPTs, I think there are a few missing:

* Given where we landed on the privacy discussions, we need to make sure that ACH and ACHL do nothing when returned on a subresource response. 

* We also need to make sure the http-equiv variants of ACH and ACHL behave the same as their header variants.

Tarun - will you be able to take on adding those tests?

Anne seems to be OOO up until the M69 branch, so we probably should not hold off on his reviews. The overall design is based on a discussion I had with him before, so I don't expect a huge amount of changes. I also commit to follow-up on those PRs with any reasonable changes that will be required. 

 

[Tarun Bansal]

Yes, I am going to add the tests. crbug.com/852484 and crbug.com/856700 track the work.

[Rick Byers]

Excellent, thanks for the progress! Tarun, when do you expect you'll be able to land the tests? I.e. should we circle back on this thread sometime before M69 branch? Note that if they refer to as-yet-unlanded specs, you can still land them in the WPT repo (eg. either exported from a chromium CL or direct in github) with a .tentative suffix.

[Yoav Weiss]

API owners, PTAL?

On Tue, Jun 26, 2018 at 8:45 PM Rick Byers <rby...@chromium.org> wrote:

Excellent, thanks for the progress! Tarun, when do you expect you'll be able to land the tests? I.e. should we circle back on this thread sometime before M69 branch? Note that if they refer to as-yet-unlanded specs, you can still land them in the WPT repo (eg. either exported from a chromium CL or direct in github) with a .tentative suffix.

On Tue, Jun 26, 2018 at 1:47 PM Tarun Bansal <tba...@chromium.org> wrote:

Yes, I am going to add the tests. crbug.com/852484 and crbug.com/856700 track the work.

On Tuesday, June 26, 2018 at 5:24:39 AM UTC-7, Yoav Weiss wrote:

On Thu, May 24, 2018 at 8:51 PM Rick Byers <rby...@chromium.org> wrote:

We (Ojan, Yoav, Alex, Daniel, Rick) discussed this intent in the API owners meeting today.  We agree with Anne's perspective that it's the responsibility of the chromium project to ensure we're precisely defining (via spec and test PRs) the behavior we're shipping, and therefore it's reasonable to block this intent on doing that (not just ask that people trust we'll get to it eventually).  Thank you for raising your concern around this Anne!

It seems likely that there's going to be a bunch of debate more on the editorial side (eg. which changes belong in fetch spec vs. html spec) and with minor details which are unlikely to results in real-world interop problems in practice, and that it's unlikely to be worth the cost to block shipping this feature on all of those questions. So the API owners expect we will be approving this intent based on unlanded pull requests we judge to be of sufficient quality.  Yoav expects that he can get the PRs to this state in plenty of time to revisit this intent ahead of the M69 branch (July 19), and so this will ultimately translate into slipping this feature by one milestone as a result of these concerns.

Those unlanded PRs are now ready for review:

https://github.com/whatwg/fetch/pull/725 - Tarun's PR, which adds the new hints to the list.

https://github.com/whatwg/fetch/pull/773 - which aligns the spec with the implementation and initializes Fetch's client-hints list with the environment settings object one.

https://github.com/whatwg/html/pull/3774 - which defines the ACHL cache, ACH and ACHL response header parsing and creates a new client-hints list on the environment settings object. It also defines the processing of the http-equiv header equivalents.

The HTML PR, which is the largest and more complex of the three, was reviewed by Domenic, and I believe it is in good shape. We're still waiting on Anne to review it before landing, but I believe we should no longer block shipping on it.

 

Reviewing the WPTs, I think there are a few missing:

* Given where we landed on the privacy discussions, we need to make sure that ACH and ACHL do nothing when returned on a subresource response. 

* We also need to make sure the http-equiv variants of ACH and ACHL behave the same as their header variants.

Tarun - will you be able to take on adding those tests?

Anne seems to be OOO up until the M69 branch, so we probably should not hold off on his reviews. The overall design is based on a discussion I had with him before, so I don't expect a huge amount of changes. I also commit to follow-up on those PRs with any reasonable changes that will be required. 

 

--

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/CAFUtAY_Wv1nMHX6HGV_ycoLRgK2%3D6c6B2zn%3Da--M0Q%2BEBCcrdQ%40mail.gmail.com.

[Daniel Bratell]

As Rick wrote earlier, the threshold the API owners put on this feature was to have enough of the required spec changes at least in the pipeline, and more or less finished. This includes making up for some earlier shortcuts taken in the client hints area so that the feature can be implemented in other browsers without guesswork. We also wanted there to be wpt tests for the same reason.

It seems to me that the criteria is now fulfilled, though there are still three outstanding spec change requests (linked below).

LGTM1

/Daniel

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgG9d%2Bnuk88Ngz24%3DGrB4qfTpVQ5Ght_ghhQKphQhLAgQ%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

[Rick Byers]

Agreed with one caveat - it's both reasonable spec AND test changes in the pipeline that I think we want to see. So I'd still like to see a discussion on what amount of test work folks feel should block this intent. Obviously test coverage is never perfect, but what's a reasonable amount of coverage in WPT (even as "tentative tests") before we feel comfortable saying we've provided enough tests to provide likely real-world interoperability with future implementations?

Yoav / Tarun, what's your opinion?

Rick

[Daniel Bratell]

Some tests landed yesterday https://chromium.googlesource.com/chromium/src.git/+/960dfcbf80b41b83d4f5f5729fd21c4f4f7f003b but I'm not familiar enough with this to determine how good the test coverage is and how much more is needed.

/Daniel

[Yoav Weiss]

On Tue, Jul 3, 2018 at 5:38 PM Rick Byers <rby...@chromium.org> wrote:

Agreed with one caveat - it's both reasonable spec AND test changes in the pipeline that I think we want to see. So I'd still like to see a discussion on what amount of test work folks feel should block this intent. Obviously test coverage is never perfect, but what's a reasonable amount of coverage in WPT (even as "tentative tests") before we feel comfortable saying we've provided enough tests to provide likely real-world interoperability with future implementations?

Yoav / Tarun, what's your opinion?

From a test perspective, Tarun has landed Accept-CH http-equiv tests.

There are a few more tests related to {cross,same} origin iframe behavior in the pipeline, waiting to be landed.

Otherwise, there's still http-equiv Accept-CH-Lifetime tests which need to be written. It should also be noted that the Chromium implementation is not there yet for those bits. 

So we could either:

1) Argue that test coverage is complete, ship the current NQE intent, then send a separate I2S for ACHL http-equiv support with the appropriate tests.

2) Integrate the ACHL http-equiv functionality into this intent, and wait for its tests and implementation to be complete.

 

Tarun - any comments on the timeline for the http-equiv ACHL WPT and implementation?

I have a slight preference for 1) as it seems cleaner and will enable us to ship the larger chunk of the functionality, while not hiding the addition of ACHL http-equiv support in the larger intent.

[Rick Byers]

Thanks Yoav, either of those plans sounds reasonable to me.

[Tarun Bansal]

http-equiv ACHL WPT CL should be out today. I am working on the CL for actual Chromium implementation.  That might take couple of days to land.

Rick

API owners, PTAL?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_Wv1nMHX6HGV_ycoLRgK2%3D6c6B2zn%3Da--M0Q%2BEBCcrdQ%40mail.gmail.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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgG9d%2Bnuk88Ngz24%3DGrB4qfTpVQ5Ght_ghhQKphQhLAgQ%40mail.gmail.com.

[Chris Harrelson]

LGTM2 to to ship each of these pieces as test coverage and spec PRs land.

Rick

API owners, PTAL?

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/CAFUtAY_Wv1nMHX6HGV_ycoLRgK2%3D6c6B2zn%3Da--M0Q%2BEBCcrdQ%40mail.gmail.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/CACj%3DBEgG9d%2Bnuk88Ngz24%3DGrB4qfTpVQ5Ght_ghhQKphQhLAgQ%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

--

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/209f5aad-62af-4666-9ec3-cc03bf9bc90f%40chromium.org.

[Rick Byers]

LGTM3 to ship as reasonable test coverage lands.

Chris, above Yoav was talking about not blocking shipping on AnneVK getting back from vacation and reviewing the PRs he has (which he feels are complete). Is that OK with you?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAOMQ%2Bw-d1T9FvHsokUowvLWGNx0ZTi9LKgenU23inkegKDTE3w%40mail.gmail.com.

[Ilya Grigorik]

\o/ ... super excited to see this ship!

+Yoav Weiss +Tarun Bansal thank you for the great work on aligning all the spec + testing bits (not to mention, the implementation! :)).

On Tue, Jul 3, 2018 at 10:33 AM Chris harrelson <chri...@chromium.org> wrote:

On Tue, Jul 3, 2018 at 10:31 AM, Rick Byers <rby...@chromium.org> wrote:

LGTM3 to ship as reasonable test coverage lands.

Chris, above Yoav was talking about not blocking shipping on AnneVK getting back from vacation and reviewing the PRs he has (which he feels are complete). Is that OK with you?

Yes, that's ok by me.

[Chris harrelson]

On Tue, Jul 3, 2018 at 10:31 AM, Rick Byers <rby...@chromium.org> wrote:

LGTM3 to ship as reasonable test coverage lands.

Chris, above Yoav was talking about not blocking shipping on AnneVK getting back from vacation and reviewing the PRs he has (which he feels are complete). Is that OK with you?

Yes, that's ok by me.

 

Rick

API owners, PTAL?

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_Wv1nMHX6HGV_ycoLRgK2%3D6c6B2zn%3Da--M0Q%2BEBCcrdQ%40mail.gmail.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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CACj%3DBEgG9d%2Bnuk88Ngz24%3DGrB4qfTpVQ5Ght_ghhQKphQhLAgQ%40mail.gmail.com.

--

/* Opera Software, Linköping, Sweden: CEST (UTC+2) */

--
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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/209f5aad-62af-4666-9ec3-cc03bf9bc90f%40chromium.org.