Thanks for the update, Kyra. Would like to ask a follow-up question here. I noticed that in chrome://flags/ there's the flag *Experimental third-party storage partitioning. *For how long will users have access to this flag? And for how long will they be able to disable this?
Additionally, for further clarification, if a customer disables this flag in Chrome, would the user have the storage partition change that is scheduled to roll out on 7/28 at 1%? On Thursday, July 27, 2023 at 3:33:01 PM UTC-4 Kyra Seevers wrote: > Hi all, > > M115 is now being served at 100% on Desktop and Android. We will begin the > rollout to Stable 1% shortly - the approximate rollout schedule is now as > follows: > > Stable 1%: July 28th > Stable 10%: Aug 11th > Stable 50%: Aug 25th > Stable 100%: Sept 8th > > On Thu, Jul 27, 2023 at 11:52 AM Mike Taylor <mike...@chromium.org> wrote: > >> No, we don't know with certainty. >> >> You can watch https://chromiumdash.appspot.com/releases?platform=Windows >> to see when 115 is being served to 100% for all platforms. Today it's at >> 50% for Windows, for example. >> On 7/26/23 5:39 PM, Jagadeesha B Y wrote: >> >> Do we know when does M115 will hit 100%? Exact date would help us to >> communicate on the storage partition impact to our customers. >> >> >> On Wednesday, July 26, 2023 at 2:12:10 PM UTC-7 mike...@chromium.org >> wrote: >> >>> On 7/26/23 4:01 PM, Vi S wrote: >>> >>> Hi Kyra, >>> >>> Per your message here ( >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/24hK6DKJnqY/m/tu0i5OmhCAAJ) >>> >>> it sounds like as of 7/26/2023, the Storage Partitioning change has not >>> been released yet since M115 is not served to 100% of users. Is that >>> correct? My understanding of this message is that M115 is currently served >>> to 12.5% of users and that once M115 is served to 100% of users (which will >>> happen in the next ~4 weeks), only then will the storage partition change >>> be rolled out in a gradual manner. Is this understanding accurate? >>> >>> That's correct. >>> >>> >>> Additionally, would you be able to provide an updated schedule for the >>> rollout of the storage partitioning change (similar to the one linked here: >>> https://groups.google.com/a/chromium.org/g/blink-dev/c/24hK6DKJnqY/m/Tts2gjrEBwAJ) >>> >>> ? >>> >>> Once we begin the gradual roll-out, we'll provide a estimated rollout >>> schedule on this thread (I hesitate to do so now - it's hard to know when >>> we will begin exactly). >>> >>> thanks, >>> Mike >>> >>> >>> Thank you >>> >>> On Monday, July 24, 2023 at 10:18:26 AM UTC-4 Kyra Seevers wrote: >>> >>>> Hi there, >>>> >>>> Thank you for your email - as of today (Monday 7/24/23), the feature is >>>> not rolled-out to stable. >>>> >>>> However, I can confirm that the rollout schedule for this feature >>>> begins in M115 at Stable 1% (once M115 is served to 100% of users). M115 >>>> is >>>> currently served to 12.5% of users - you can track the status at >>>> https://chromiumdash.appspot.com/releases?platform=Windows. Two weeks >>>> after that, we'll go to 10%, assuming no large stability or compatibility >>>> regressions. Then 50 and 100% at additional 2 week increments. >>>> >>>> >>>> In the meantime, we have a deprecation trial ( >>>> https://developer.chrome.com/blog/storage-partitioning-deprecation-trial/#participate-in-the-deprecation-trials) >>>> >>>> running in M115+ that allows sites who opt-in to maintain unpartitioned >>>> storage for a few milestones while they develop a >>>> storage-partitioning-compatible solution. >>>> >>>> Thanks, >>>> >>>> Kyra >>>> >>>> On Sun, Jul 23, 2023 at 7:05 PM Jagadeesha B Y <jaga...@gmail.com> >>>> wrote: >>>> >>>>> >>>>> I see that Chrome 115 release notes - >>>>> https://chromestatus.com/feature/5723617717387264 mentioning about >>>>> storage partition being enabled by default. Could someone confirm how >>>>> gradual this rollout is? do we know if storage partition is rolled out >>>>> fully? >>>>> >>>>> Our SASS product has a heavy reliance on Shared worker and this would >>>>> break our customer use cases. We use shared worker to co-ordinate Web >>>>> RTC >>>>> signalling and websocket management which is critical for the app. >>>>> On Wednesday, May 31, 2023 at 8:42:15 AM UTC-7 mk...@chromium.org >>>>> wrote: >>>>> >>>>>> LGTM3 with all the caveats about careful rollout discussed above. >>>>>> >>>>>> -mike >>>>>> >>>>>> >>>>>> On Tue, May 30, 2023 at 5:39 PM Mike Taylor <mike...@chromium.org> >>>>>> wrote: >>>>>> >>>>>>> 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 <mike...@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+...@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 >>>>>>> >>>>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bc52292b-9142-adad-d126-b93231468ed0%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+...@chromium.org. >>>>> >>>> To view this discussion on the web visit >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0e6d131f-f6c7-4bbb-ad3e-bd68cd63ec0dn%40chromium.org >>>>> >>>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/0e6d131f-f6c7-4bbb-ad3e-bd68cd63ec0dn%40chromium.org?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>> >>>> >>>> -- >>>> >>>> Kyra Seevers (she/her) | Software Engineer | kyras...@google.com | >>>> 859-537-9917 <(859)%20537-9917> >>>> >>> > > -- > > Kyra Seevers (she/her) | Software Engineer | kyras...@google.com | > 859-537-9917 <(859)%20537-9917> > -- 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/e548639e-3062-4252-a393-992ec220a54an%40chromium.org.
