I'm not sure how much we can rely on OmahaProxy to help here, none of the tools there were really designed to handle your particular use case (which is complex due to V8 rolling, sadly).

What in go/find-releases did you use to make the decision?  Maybe we need some better tools and documentation here.

I started with a misconception (a change that is fixed in canary and has not occurred in dev is resolved). Using go/find-releases on the V8 revert gives me:

  Commit a8be5d4d... initially landed in 58.0.3029.0

  No merges found.

  https://storage.googleapis.com/chromium-find-releases-static/a8b.html#a8be5d4dabe8587567639e63831e3fc74ee089c2

And the reland:

  Commit 42e64efb... initially landed in 59.0.3032.0

  No merges found.

  https://storage.googleapis.com/chromium-find-releases-static/42e.html#42e64efbfec73ed99927e1fc666c8838668b1f24

This doesn't tell me much about the release channels, though. I'm not sure exactly how it ought to work, but I'd have liked some indication that an upcoming dev channel release would be on the 3029 branch. If the next dev channel release had been on the 3032 branch, this issue would have had less impact, but I don't know how to tell.

Maybe something like:

  Commit a8be5d4d... initially landed in 58.0.3029.0
  Canary: shipped
  Dev: expected to ship in release on branch 3029 (tomorrow)
  Beta: expected to ship in M58 cut (two weeks from now)
  Stable: expected to ship in M58 (eight weeks from now)

  No merges found.

Which I could them compare to the reland and know that the reland wasn't expected to ship in the upcoming dev release.

Or maybe the query would be better of the form "is there an upcoming release whose master position is between commit X and commit Y"?

I'm not sure I would have known to check for this, but I felt like it would have been nice to be able to say "I'm aware of badness in this commit range; what release channels do I have to worry about?".

I'm going to add the Chromium Dash component to this bug as well so we keep visibility on it (Chromium Dash is a new tool we're building to take over some of the functionality of OmahaProxy, check out the prototype at https://chromiumdash.appspot.com/releases if you'd like).  I can't promise we'll be able to build exactly what you're looking for in c#2, but we do plan to include a release schedule where we tag builds as dev / beta / stable candidates that might make things a bit more obvious.

It would be nice if branch/revision information was more visible in dashboard, but honestly, I'm not sure how much that would have helped here.

Branches that get promoted to dev channel aren't known far ahead of time -- it takes a while to collect the various stability metrics and to make the final human decision -- so even if chromedash (or omahaproxy or whatever) had such a feature, you might have still missed it if you had looked before it was known and there had been no followup. But in this case, there actually was a warning right in the bug:

https://bugs.chromium.org/p/chromium/issues/detail?id=698214#c7

which requested that the fix be applied to M58 (3029) for the next dev release. I doubt anything in chromedash would have been any more explicit.

[The safest route would be to always fix any canary problems on the given canary branch, whether or not you know if it's going to promote to dev channel, but that of course would mean sometimes fixing stuff that is never used.]

Leaving open as a feature request for dashboard, but feel free to close if it's no longer wanted.

Yes, a close read of #7 does imply the necessary information if you properly understand our release process; I did not.

I'm also not sure "govind@ will warn you" is a substitute for some tool clarifying what's going on (but I'm just one committer, so this is anecdotal), but it probably has reduced the number of such issues.

ChromiumDash has been getting increasingly nice, but IIUC it still doesn't surface more subtle cases like the one in the bug. (I realize it's rare, so feel free to prioritize/wontfix as you feel appropriate.)

We can leave this as a tracking bug for Chromium Dash + user education on release process (which is on my plate to fix up as well, because we don't have good training here).

Updating title since this may be addressed in Chromium Dash and not OmahaProxy.

Bulk edit**

This bug has the label Postmortem-Followup but has not been updated in 3+ weeks. We are working on a new workflow to improve postmortem followthrough. Postmortems and postmortem bugs are very important in making sure we don't repeat prior mistakes and for making Chrome better for all.

We will be taking a closer look at these bugs in the coming weeks. Please take some time to work on this, reassign, or close if the issue has been fixed. Thank you.

No longer on the Chrome team, e-mail me @google.com if any attention still required from me here, otherwise good luck!