Philip, no - feature flag, in case we need to killswitch it.
On 3/13/23 11:20 AM, Jiacheng Guo wrote:
Then we may follow this way:
I will ask the contributor to implement the feature behind a feature
flag and fix any test failures. The contributor may add a use counter.
Otherwise I will add one.
Then I can manually ship the feature behind the flag and monitor the
UKM data.
Does that make sense to you?
Jiacheng Guo
On Tue, Mar 14, 2023 at 12:07 AM Philip Jägenstedt
<foo...@chromium.org> wrote:
Mike, do you mean in order to put this behind Finch?
On Mon, Mar 13, 2023 at 3:06 PM Mike Taylor
<miketa...@chromium.org> wrote:
Yes, ideally this change ships behind a flag.
On 3/13/23 7:43 AM, 'Jiacheng Guo' via blink-dev wrote:
For Eli Grey's question:
Yes, the behavior will change with the feature.
I believe it's reasonable to add use. The isValidHost
function behavior varies among different browsers. The change
will make Chrome act as the URL standard.
I believe it's reasonable to add a use counter for the
feature. Since the CL is created by an external developer,
would you suggest creating a feature flag for it as well?
Jiacheng Guo
On Mon, Mar 13, 2023 at 7:31 PM Yoav Weiss
<yoavwe...@chromium.org> wrote:
On Mon, Mar 13, 2023 at 11:21 AM Philip Jägenstedt
<foo...@chromium.org> wrote:
On Mon, Mar 13, 2023 at 11:05 AM Yoav Weiss
<yoavwe...@chromium.org> wrote:
On Mon, Mar 13, 2023 at 10:46 AM Philip
Jägenstedt <foo...@chromium.org> wrote:
To simplify and keep this moving, I've filed
https://github.com/mozilla/standards-positions/issues/759
as an umbrella issue for anything URL in
Interop 2023.
My view is that we can't improve our risk
assessment of this by much with metrics,
because we can't distinguish between harmless
and serious breakage.
Metrics can give us an upper bound, as well as a
pile of examples that one can then manually
sample and assess breakage.
Instead what we should do is take some
comfort in the fact that the behavior is
already shipping in Safari, try to ship it
and revert at the first sign of trouble to
evaluate.
Those are not contradictory. E.g. we could add
metrics (+UKM) and a flag, and then be alert for
bug reports from Beta, as well as randomly
examine sites that touch the relevant usecounters
and see if they were broken.
Would that work from your perspective?
Is the suggestion to do the same as in
https://chromium-review.googlesource.com/c/chromium/src/+/4252309
(for Intent to Ship: Port overflow check in URL
setters
<https://groups.google.com/a/chromium.org/g/blink-dev/c/xsITedSTDnM/m/ANFrwCN0BgAJ>)
to add the use counter but not wait for data before
trying to ship this?
That's what I'm suggesting (+ a manual sampling &
inspection of URLs we'd get from UKM to actively verify
there's no significant breakage coming)
That would work for me if Jiacheng thinks it's
reasonable in this case.
--
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/CAJQw1NywiOk%2BFqtS4-nPDSjbp%3DBFfQ9wtENFVw7ue7EX8yim5g%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAJQw1NywiOk%2BFqtS4-nPDSjbp%3DBFfQ9wtENFVw7ue7EX8yim5g%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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/52b2e83a-8e4f-af60-a6e9-171f481842e1%40chromium.org.
