Automation opportunity: Tracking bug status tracking

[jstenback]

Is your feature request related to a problem? Please describe.

Today we ask that developers record their tracking bug in the dashboard. But that's the extent of it, we don't do anything with that information other than including it in email templates etc.

Describe the solution you'd like

We could fairly easily reflect the status of the tracking bug in the tool, we could mirror the star count to get a signal for "importance" of a given feature. We could potentially use the status of the bug to flag incorrect status in the tool for which feature this shipped in etc.

[jpmedley]

We could potentially use the status of the bug to flag incorrect status in the tool for which feature this shipped in etc.

I agree with this, but it's tricky. Project teams sometimes fail to mark the tracking bug as finished for weeks, months, and in rare cases years after a feature ships. In such cases, I look for a shipping commit. these frequently, but not always, contain text such as "Ship Some API Name". I then look up the commit hash in Omaha Proxy or chromiumdash.

Is there some way to enforce a mark that says, this is the commit that ships? This would simplify downstream automation in both Monorail and Chrome Status.

[jpmedley]

@cwilso tells me that the launch bugs are more reliable. I guess there are strict requirements around the completion of those that don't exist for tracking bugs. Should this be changed to use that?

[jpmedley]

This question is answered by #859.