Stricter process around deprecations

[Yoav Weiss]

Hey folks!

At TPAC, we had a breakout session on "breaking the web responsibly", which made me think more about our deprecation process.

Deprecation reporting seems to be an extremely strong feature to warn developers about upcoming breakage, but I recently caught a bunch of deprecations that were about to go ahead without such reporting in place.

It seems like we need to make it clearer to Chromium developers that *any* deprecation or behavior change that runs a risk of breaking folks should also get a deprecation report wired up (within reason, there are some cases where it's unreasonably hard to wire one up, or results in privacy violations) 

What do y'all think about changing the deprecations section (and/or the guidelines) to properly indicate that a deprecation report is needed?

Cheers :)

Yoav

[Mike West]

Deprecation warnings should be automagically created when `Deprecation::CountDeprecation()` is called. I think it's quite reasonable for us to explicitly recommend that path towards deprecation in Blink, and it's probably worth wiring up more channels to that in //content and //net.

That said, I'm surprised that deprecation reporting was considered so useful. We should produce them, certainly, but it's not clear to me that we're seeing substantial change brought about by the reports that we're sending today via the mechanism above. Skimming the minutes you linked to didn't really provide more insight, and the way reporting and dashboards were discussed seemed to be pointing to things above and beyond sending reports to developers.

-mike

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAL5BFfUqz7uK4VjOse_8Q_eG2gerEYxJovb1y2wwWH%2BeP-m82g%40mail.gmail.com.

[Yoav Weiss]

On Mon, Sep 26, 2022 at 10:33 AM Mike West <mk...@chromium.org> wrote:

Deprecation warnings should be automagically created when `Deprecation::CountDeprecation()` is called. I think it's quite reasonable for us to explicitly recommend that path towards deprecation in Blink

Cool! That's all I'm proposing here - for us to be explicit about this.

 

, and it's probably worth wiring up more channels to that in //content and //net.

That said, I'm surprised that deprecation reporting was considered so useful. We should produce them, certainly, but it's not clear to me that we're seeing substantial change brought about by the reports that we're sending today via the mechanism above.

Substantial change also requires that developers would pay attention. /cc +Andre Bandarra  

Skimming the minutes you linked to didn't really provide more insight, and the way reporting and dashboards were discussed seemed to be pointing to things above and beyond sending reports to developers.

Yeah, the minutes are extremely lossy..

Essentially, producing the reports is table stakes. We also need to raise developer awareness of their existence, improve their ergonomics (currently they report the feature enum number, without any further comment), and potentially a number of other things..

But let's take the first step first :)

[Ian Clelland]

+Ari Chivukula 

On Mon, Sep 26, 2022 at 4:50 AM 'Yoav Weiss' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

On Mon, Sep 26, 2022 at 10:33 AM Mike West <mk...@chromium.org> wrote:

Deprecation warnings should be automagically created when `Deprecation::CountDeprecation()` is called. I think it's quite reasonable for us to explicitly recommend that path towards deprecation in Blink

Cool! That's all I'm proposing here - for us to be explicit about this.

 

, and it's probably worth wiring up more channels to that in //content and //net.

That said, I'm surprised that deprecation reporting was considered so useful. We should produce them, certainly, but it's not clear to me that we're seeing substantial change brought about by the reports that we're sending today via the mechanism above.

Substantial change also requires that developers would pay attention. /cc +Andre Bandarra  

Skimming the minutes you linked to didn't really provide more insight, and the way reporting and dashboards were discussed seemed to be pointing to things above and beyond sending reports to developers.

Yeah, the minutes are extremely lossy..

Essentially, producing the reports is table stakes. We also need to raise developer awareness of their existence, improve their ergonomics (currently they report the feature enum number, without any further comment), and potentially a number of other things..

This was reported (and closed wontfix) in https://crbug.com/1338638. I agree that the egronomics here are critical, and would love to consider reopening that, to report both machine- and human-readable identifiers in tooling and in the reporting API.

Ian

But let's take the first step first :)

 

-mike

On Mon, Sep 26, 2022 at 10:15 AM 'Yoav Weiss' via blink-api-owners-discuss <blink-api-ow...@chromium.org> wrote:

Hey folks!

At TPAC, we had a breakout session on "breaking the web responsibly", which made me think more about our deprecation process.

Deprecation reporting seems to be an extremely strong feature to warn developers about upcoming breakage, but I recently caught a bunch of deprecations that were about to go ahead without such reporting in place.

It seems like we need to make it clearer to Chromium developers that *any* deprecation or behavior change that runs a risk of breaking folks should also get a deprecation report wired up (within reason, there are some cases where it's unreasonably hard to wire one up, or results in privacy violations) 

What do y'all think about changing the deprecations section (and/or the guidelines) to properly indicate that a deprecation report is needed?

Cheers :)

Yoav

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAL5BFfUqz7uK4VjOse_8Q_eG2gerEYxJovb1y2wwWH%2BeP-m82g%40mail.gmail.com.

--
You received this message because you are subscribed to the Google Groups "blink-api-owners-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-api-owners-d...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAL5BFfWjzgmAB3_Pqv9p6r7E_uVvV77W-n4_S54J-SWrBBfNuQ%40mail.gmail.com.

[Ari Chivukula]

There has been an unfortunate expansion in complexity since the DevTools Issues migration occurred (steps for new deprecations are listed here: https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/frame/deprecation/README.md). We should make them easier to use, but the split between chromium invocation and devtools definition makes improvement harder. The best bet might be adding a new code-generation step (the same way browser_protocol.pdl changes propagate cross-repo).

~ Ari Chivukula (Their/There/They're)

[Yoav Weiss]

Those are a lot of steps...

We should definitely add that doc to our process documentation. (while at the same time, making this process simpler would be highly appreciated!)