Proposal: lightweight tooling to catch missing ChromeStatus feature approvals
Helmut Januschka
Hi all,
while working on a recent CL, I managed to forget about the ChromeStatus feature approval process. Weeks later, after finally getting the CR+1, I hit “Submit” without realizing the feature entry wasn’t fully approved yet. The revert + postmortem that followed were a good lesson learned for me — but it also got me thinking about whether we could reduce the chance of this happening again.
As an after-work experiment, I threw together a small PoC tool called Scooby:
https://github.com/hjanuschka/scooby
Scooby queries the ChromeStatus API for a given CL, checks the “Prepare to Ship” gates, and returns whether all required approvals are present (with nice table output, or JSON + exit codes for bots). For me personally, it already serves as a reminder before submitting.
One idea for wider use could be something similar to the fuchsia size bot (it fails and explains, and shows options to bypass):
-
If a CL touches a WPT, it would require a CS-Feature-ID in the commit message (e.g. CS-Feature-ID: 12345).
-
If missing, the bot would fail and display a short explanation.
-
For unrelated cases, contributors could explicitly bypass with CS-Feature-ID: irrelevant.
This way, contributors are nudged to think “does this change need a feature entry?” without adding too much overhead.
Of course, this is just a PoC and might not be the right fit for infra — and it depends on CLs being linked to feature entries in the first place, which is part of the broader challenge. But I figured it’s worth sharing in case it sparks ideas or discussion.
Let’s see where it goes — no emotional bonding, if the idea is crap happy to dig a grave for it.
Best,
Helmut
Yoav Weiss (@Shopify)
* This is extremely neat!!
+Jason Robbins for thoughts on the chromestatus API and linkability to crbugs
--
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/38945825-3549-492e-b0b7-20474f3a4bdfn%40chromium.org.
Helmut Januschka
* Adding a CS-Feature-ID for every CL that changes any WPT feels like a chore (but maybe that's just me)
It's also me! Let's please steer clear of adding more process like this around CLs. My strong opinion is that it's too heavy-handed an approach!I haven't looked closely at what the tool does otherwise, so I'm open to more softer approaches. I just wanted to comment on the "auto fail all CLs that touch WPTs without a CS-Feature-ID in the commit description" bit.
Dominic Farolino
* Adding a CS-Feature-ID for every CL that changes any WPT feels like a chore (but maybe that's just me)
Daniel Bratell
I have not read the post-mortem (is it public?), but to me this was just a mistake, which happens, and it was corrected. Mistakes seem relatively uncommon and the process is already a bit scary so I would not want to make life any more complicated for the common development path because of it.
There is a an implicit check when code that toggle feature related flags is reviewed, but as you noticed, not all changes need to touch those flags.
I could imagine something (very quick-off-the-cuff-thinking) where chromestatus knew of the main development bug and somehow reminded the code author of the current stage in the process when, or after, you commit a change. A human would still have to notice and determine if there is a conflict, but it would have prevented this, I guess?
/Daniel