OK - let's consider this I2S officially revived. Looking for a 3rd LGTM to begin shipping in M115.

We have implemented 3rd party deprecation trial support for M115+ (see https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/#participate-in-the-deprecation-trials), and extended the deprecation trial's expiration date accordingly to account for the delay. And we have the Enterprise policy ready to go.

The rollout schedule will look something like the following, pending metrics and compatibility stability:

July 25th: 1% of Stable population (approximately 1 week after M115 is released)
Aug 8th: 10%
Aug 22nd: 50%
Sep 5: 100%

As always, if we discover significant user-facing breakage we'll explore pausing or rolling back to address.

thanks,
Mike

On 5/1/23 10:43 AM, Mike Taylor wrote:

Thanks Rick and Yoav.

We learned from two partners (one internal, one external) late last week that a 3P deprecation trial would be needed for them to preserve widely-used functionality while they work on a migration strategy.

We're tracking the work in crbug.com/1441411 and hope to have that ready by M115. Once we land the fix, I'll circle back and look for a 3rd LGTM and have an updated rollout schedule. :)

On 5/1/23 12:21 AM, Yoav Weiss wrote:
LGTM2

On Thu, Apr 27, 2023, 16:23 Rick Byers <rby...@chromium.org> wrote:



    On Wed, Apr 26, 2023 at 2:02 PM Mike Taylor
    <miketa...@chromium.org> wrote:

        On 4/26/23 9:36 AM, Mike Taylor wrote:

        > On 4/25/23 12:00 PM, Rick Byers wrote:
        >
        >> In terms of the standards / process piece, it looks as if
        the spec
        >> PRs have all stalled for several months. What do you think is
        >> necessary to get these unblocked and landed? As the last
        engine to
        >> implement this behavior, perhaps we shouldn't feel too
        compelled to
        >> block shipping on PRs landing?

        I was gently reminded offline that I didn't answer this part
        of your
        question - oops.

        Right now it seems to me that the costs of landing these spec
        PRs is
        higher than we're willing to block on, given the requested
        refactoring
        (and yes, it's unfortunate that 3 engines would be shipping
        essentially
        unspecced behavior, but that's where we're at). That said,
        I'm happy to
        devote my few IC hours to pushing these along as a personal
        project over
        the coming months.


    Thanks Mike. I trust your and wanderview@'s judgement here - I
    know how hard y'all have been willing to work in the past to get
    the right thing done in specs. Thanks for being willing to keep
    pushing in parallel. But given two other implementations have
    already shipped this, it was clearly already a spec bug that the
    spec didn't reflect reality. I agree that we shouldn't block
    shipping a 3rd implementation on spec refactoring work.

    LGTM1 to ship from my perspective. Obviously this will need a
    very thoughtful and careful roll-out. But I trust Mike and his
    team to engage with impacted folks to make sure it goes smoothly,
    as they did with UA reduction.


--
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/bc52292b-9142-adad-d126-b93231468ed0%40chromium.org.

Reply via email to