Proposal: no LGTMs needed for shipping an existing API on more platforms (except when there are known risks)

[Chris Harrelson]

There seems to be no carveout in the launching-features guide, for this case, and I can't think of a reason why we would not approve shipping an API already on one platform to a new one in almost all cases. (Example: this intent)

One potentially risky situation I can think of is if the feature implementation requires APIs not easily available to all user agents on a platform (e.g. complex code in //chrome--a situation already called out as a risk factor in the I2S process).

So I propose that no LGTMs are needed for shipping an existing API on more platforms, if there are no platform-specific complexity risks to the new platform. In such a case use the Web-Facing Change PSA template on chromestatus.

All: WDYT?

[Jeffrey Yasskin]

The other risky situation is when only a piece of the API is being shipped on the new platform. e.g. in the File System Access intent, "Android files (content-URIs) do not support atomic writes, or atomic renames. As such, not all operations will be supported, or some operations like move will be implemented as copy.", and getFileHandle() was omitted. +1 for omitting LGTMs when it's actually the same API being shipped to a new platform, but I think subsets deserve review.

I also don't think we want to use the "PSA" category on Chrome Status. That's now described as "No developer-visible change" because people were over-using it, and this is a developer-visible change. Instead, they should re-use the existing entry for the feature that already shipped. We could say to just send a PSA email to blink-dev, or perhaps the "Draft Intent to Ship email" button will work from a feature that's already approved.

Jeffrey

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2BN6QZuGXjOy2dQMfWkBfeCxvhseCr0QCP8CCdMHFip339XrpQ%40mail.gmail.com.

[Chris Harrelson]

These are good points, +1 to both of them.

[Mike Taylor]

I think in general I agree, but do worry about compat risk when a very long time has passed from the initial shipping moment and enabling on the new platform. Developer assumptions can be baked into code in ways that are hard to predict, especially for APIs where feature detection is imperfect.

I'm fine w/ an FYI email approach, but still think we should consider if it needs to be elevated (downgraded?) to an I2S.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2BN6QZuJdPDR4oQzrPOYBctPn1cEC-LrmoavAYOBhTY-vW2K%3DA%40mail.gmail.com.

[Chris Harrelson]

Update: the API owners met and discussed this proposal. The group was supportive of lightening the process of shipping on a new platform to a PSA / reply to the existing I2S, as long as there are no known risks or differences from platform to platform. We also noted that there might be a need for some more chromestatus tooling to make it easier to process these PSAs and not get missed.

[Johnny Stenback]

+Panos Astithas for visibility regarding the need for some updates to Chromestatus tooling as a result of this change.

- jstenback (he/him)

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2BN6QZsY%2BHv71PxiNGX6c3605PzP2S6k-JR5k6i8nrDa09crgg%40mail.gmail.com.

[Chris Harrelson]

One thing that would be really good to have on chromestatus is a way to indicate which milestones additional shipping happened on. Is it possible already to have two I2Ses associated with the same chromestatus entry? (Guessing no.)

[Panos Astithas]

It is actually possible to add a new shipping stage (or any other stage). That's what Jeffrey recommended in the initial thread.

With that in mind, would you like to see past I2S milestones in any new I2S or is seeing them in Chromestatus sufficient?

[Rick Byers]

FWIW just updating the existing I2S thread is what I did when reviewing a CL for such a situation recently, so I'm glad to see that's roughly where the group converged. Keeping everything on the same I2S thread might be helpful for organization purposes. In terms of chromestatus, I'd say this is rare and minor enough that we should do whatever is easiest and cheapest. Getting really great automated data (webstatus.dev, WPT, BCD etc.) seems like the only real scalable high-quality solution for this sort of thing to me.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CAJ8Nf21Hbngp_TF-xM_rFsat6dFePGtDwchd8dOrHvZ-gGVs9g%40mail.gmail.com.

[Johnny Stenback]

I agree that the more important piece in the long term is great automated data, but expressing this "correctly" in chromestatus is important if we care in these cases to include the ship events in the Chrome Beta blog posts, which are essentially automated (humans do still play a role in making sure incorrect data doesn't leak out there, but catching things that are missing in chromestatus in that process would be challenging).

- jstenback (he/him)

[Jeffrey Yasskin]

Chris, would you mind updating https://www.chromium.org/blink/launching-features/ to describe this exception?

Thanks,
Jeffrey

On Wednesday, November 6, 2024 at 2:41:33 PM UTC-8 Chris Harrelson wrote:

Update: the API owners met and discussed this proposal. The group was supportive of lightening the process of shipping on a new platform to a PSA / reply to the existing I2S, as long as there are no known risks or differences from platform to platform. We also noted that there might be a need for some more chromestatus tooling to make it easier to process these PSAs and not get missed.

On Tue, Nov 5, 2024 at 6:03 AM Mike Taylor <mike...@chromium.org> wrote:

I think in general I agree, but do worry about compat risk when a very long time has passed from the initial shipping moment and enabling on the new platform. Developer assumptions can be baked into code in ways that are hard to predict, especially for APIs where feature detection is imperfect.

I'm fine w/ an FYI email approach, but still think we should consider if it needs to be elevated (downgraded?) to an I2S.

On 11/4/24 9:16 PM, Chris Harrelson wrote:

These are good points, +1 to both of them.

On Mon, Nov 4, 2024 at 3:45 PM Jeffrey Yasskin <jyas...@google.com> wrote:

The other risky situation is when only a piece of the API is being shipped on the new platform. e.g. in the File System Access intent, "Android files (content-URIs) do not support atomic writes, or atomic renames. As such, not all operations will be supported, or some operations like move will be implemented as copy.", and getFileHandle() was omitted. +1 for omitting LGTMs when it's actually the same API being shipped to a new platform, but I think subsets deserve review.

I also don't think we want to use the "PSA" category on Chrome Status. That's now described as "No developer-visible change" because people were over-using it, and this is a developer-visible change. Instead, they should re-use the existing entry for the feature that already shipped. We could say to just send a PSA email to blink-dev, or perhaps the "Draft Intent to Ship email" button will work from a feature that's already approved.

Jeffrey

On Mon, Nov 4, 2024 at 3:16 PM Chris Harrelson <chri...@chromium.org> wrote:

There seems to be no carveout in the launching-features guide, for this case, and I can't think of a reason why we would not approve shipping an API already on one platform to a new one in almost all cases. (Example: this intent)

One potentially risky situation I can think of is if the feature implementation requires APIs not easily available to all user agents on a platform (e.g. complex code in //chrome--a situation already called out as a risk factor in the I2S process).

So I propose that no LGTMs are needed for shipping an existing API on more platforms, if there are no platform-specific complexity risks to the new platform. In such a case use the Web-Facing Change PSA template on chromestatus.

All: WDYT?

--
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-discuss+unsub...@chromium.org.

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2BN6QZuGXjOy2dQMfWkBfeCxvhseCr0QCP8CCdMHFip339XrpQ%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-discuss+unsub...@chromium.org.

[Chris Harrelson]

Thanks for the reminder. @Rick Byers kindly volunteered to do it for me, thanks Rick!

On Tue, Jan 14, 2025 at 2:14 PM Jeffrey Yasskin <jyas...@chromium.org> wrote:

Chris, would you mind updating https://www.chromium.org/blink/launching-features/ to describe this exception?

Thanks,
Jeffrey

On Wednesday, November 6, 2024 at 2:41:33 PM UTC-8 Chris Harrelson wrote:

Update: the API owners met and discussed this proposal. The group was supportive of lightening the process of shipping on a new platform to a PSA / reply to the existing I2S, as long as there are no known risks or differences from platform to platform. We also noted that there might be a need for some more chromestatus tooling to make it easier to process these PSAs and not get missed.

On Tue, Nov 5, 2024 at 6:03 AM Mike Taylor <mike...@chromium.org> wrote:

I think in general I agree, but do worry about compat risk when a very long time has passed from the initial shipping moment and enabling on the new platform. Developer assumptions can be baked into code in ways that are hard to predict, especially for APIs where feature detection is imperfect.

I'm fine w/ an FYI email approach, but still think we should consider if it needs to be elevated (downgraded?) to an I2S.

On 11/4/24 9:16 PM, Chris Harrelson wrote:

These are good points, +1 to both of them.

On Mon, Nov 4, 2024 at 3:45 PM Jeffrey Yasskin <jyas...@google.com> wrote:

The other risky situation is when only a piece of the API is being shipped on the new platform. e.g. in the File System Access intent, "Android files (content-URIs) do not support atomic writes, or atomic renames. As such, not all operations will be supported, or some operations like move will be implemented as copy.", and getFileHandle() was omitted. +1 for omitting LGTMs when it's actually the same API being shipped to a new platform, but I think subsets deserve review.

I also don't think we want to use the "PSA" category on Chrome Status. That's now described as "No developer-visible change" because people were over-using it, and this is a developer-visible change. Instead, they should re-use the existing entry for the feature that already shipped. We could say to just send a PSA email to blink-dev, or perhaps the "Draft Intent to Ship email" button will work from a feature that's already approved.

Jeffrey

On Mon, Nov 4, 2024 at 3:16 PM Chris Harrelson <chri...@chromium.org> wrote:

There seems to be no carveout in the launching-features guide, for this case, and I can't think of a reason why we would not approve shipping an API already on one platform to a new one in almost all cases. (Example: this intent)

One potentially risky situation I can think of is if the feature implementation requires APIs not easily available to all user agents on a platform (e.g. complex code in //chrome--a situation already called out as a risk factor in the I2S process).

So I propose that no LGTMs are needed for shipping an existing API on more platforms, if there are no platform-specific complexity risks to the new platform. In such a case use the Web-Facing Change PSA template on chromestatus.

All: WDYT?

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-api-owners-discuss/CA%2BN6QZuGXjOy2dQMfWkBfeCxvhseCr0QCP8CCdMHFip339XrpQ%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.

[Rick Byers]

Up for review here: https://chromium-review.googlesource.com/c/website/+/6177108