Thanks Rick this is really helpful. I have been involved in a few changes where API OWNERS said "flag-gated" and the implementer chose to use a disabled-by-default flag which I didn't push back on. I think just I needed this recalibration :)
On Tue, Apr 4, 2023 at 1:16 PM Rick Byers <[email protected]> wrote: > Thanks Charlie. Yes I should have been specific, I'm really talking about > enabled-by-default flags here (eg. Runtime Enabled Feature with > status=stable). > > Note that our process for flipping a kill switch via finch includes first > landing a CL that disables the flag (confirming it doesn't break any tests > etc.). We're still learning how best to communicate these rare situations, > but that'll be an ongoing process. In general I've certainly found it > helpful when folks update their I2S threads with rollout status whenever it > deviates from the original plan. > > Rick > > On Wed, Mar 29, 2023 at 3:49 PM Charles Harrison <[email protected]> > wrote: > >> Thanks for posting this Rick. One call-out that I think is worth >> mentioning is the distinction between enabled-by-default flags and >> disabled-by-default flags. The general guidelines for choosing between >> these is in the links you posted, but given that it can be sometimes a >> subjective call it might be worth clarifying in e.g. API owners feedback on >> a particular I2S. I often see requests to flag guard a feature but >> sometimes it's ambiguous in which direction. >> >> On Wed, Mar 29, 2023 at 1:53 PM Rick Byers <[email protected]> wrote: >> >>> Hey blink-dev, >>> >>> Within Google we’ve had a lot of discussion over the past year about how >>> we should make increasing use of flags and kill switches >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md> >>> to reduce the risk of breaking changes, but I realized there hasn’t been >>> discussion here on blink-dev. >>> >>> Once a change hits stable it’s quite expensive and time-consuming to do >>> an emergency patch, but much faster and cheaper to update a server config. >>> For Google Chrome this means “Finch”, but other big chromium embedders like >>> Edge also have their own system for setting flags dynamically. So >>> increasingly we want to ensure that changes which might reasonably cause a >>> regression are guarded by a flag wherever practical. >>> >>> For Blink this simply means using a Runtime Enabled Feature >>> <https://chromium.googlesource.com/chromium/src/+/main/third_party/blink/renderer/platform/RuntimeEnabledFeatures.md#:~:text=Features%20that%20are%20hidden%20behind,To%20Ship%20has%20been%20approved.> >>> (or other base::Feature). I think we’re all largely in the habit of using >>> this for new APIs, but we should also be using one for all intentional >>> breaking changes and this is something the API owners will be asking about. >>> >>> See Flag Guarding Guidelines >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/flag_guarding_guidelines.md> >>> for more details and feel free to reach out to me and/or >>> [email protected] with questions or concerns. >>> >>> Thanks, >>> >>> Rick >>> >>> -- >>> 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/CAFUtAY9iR-n102RPZWfqpUGjYm9W2LpFFb5%2BodimGFUC8Dv8ZA%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9iR-n102RPZWfqpUGjYm9W2LpFFb5%2BodimGFUC8Dv8ZA%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/CADjAqN4EGTmtvmfWps2WiRbqKv8PYeZUxtrHmhXgPfXz8oB9Yg%40mail.gmail.com.
