1111071 - Need a better system for allowing other teams to know when a treeherder change is in production

Status: RESOLVED DUPLICATE of bug 1186936

(Tree Management :: Treeherder, defect, P5)

Description

[Ed Morley [:emorley]]

23:06 <•edmorley> jlund: what repos are running the new jobs?
23:06 <jlund> all of trunk
23:06 <•edmorley> jlund: ouch
23:06 <•edmorley> jlund: ok so I guess something we need to communicate out to anyone doing buildername changes is that with treeherder, we cannot have them land before treeherder has support
23:07 <•edmorley> jlund: even without the duplicating ui bug, we don't have a good way to retrospectively re import
23:07 <jlund> edmorley: I hear ya, my mistake. I thought it was live
23:07 <•edmorley> jlund: since treeherder does this mapping on ingestion and not in the ui layer (unlike tbpl)
23:08 <•edmorley> jlund: ah ok - perhaps we need a better bug flag system, particularly for these type of bugs, to indicate when live

We can either:
1) Leave the bug open until on production (either all bugs or just bugs where we cannot have confusion)
2) Have a different keyword/... to mark in production
3) Use an "in production" comment on the bug
4) Document the "revision currently running on production" file more, and encourage other teams to check that

Either way, we also need to perhaps email the release engineering mailing list to explain about the need for changes to land in treeherder before they are made to buildbot, since whilst Jordan knew we needed to wait, others might not (given for years we said it was fine to just land whenever, with TBPL).

Comment 1

[Ed Morley [:emorley]]

(In reply to Ed Morley [:emorley] from comment #0)
> We can either:
> 1) Leave the bug open until on production (either all bugs or just bugs
> where we cannot have confusion)

I think this just leads to having many bugs open, adding to noise.

> 2) Have a different keyword/... to mark in production

Means more bug noise / paperwork

> 3) Use an "in production" comment on the bug

Ditto

> 4) Document the "revision currently running on production" file more, and
> encourage other teams to check that

We now have the "What's Deployed" link in help (as of bug 1186936), which is an order of magnitude more user-friendly than the SHA. This is also linked from our wiki page.

As such I think this is fixed by bug 1186936.