Improve mechanism for updating the chrome revision used in the PFQ |
||
Issue descriptionCurrently if a problem in Chrome is found in the PFQ and reverted or fixed, it can take an entire day until a new chrome tag is generated and the PFQ version updated. Currently forcing an uprev requires a TPM to be involved and still takes a while for the tag to propagate through and start a PFQ build. We should investigate streamlining this process, or using a different mechanism (e.g. chrome's LKGR revision) for PFQ builds.
,
Mar 21 2016
Currently the Chrome team uses a process called LKGR (Last Known Good Revision) to pick the last known canary build that can be released. This is done on a point system. The last 40 or so builds are awarded between 0 and 52 points and the build with the highest number of points and latest is chosen to be released as a canary. This is to avoid releasing something that has a bunch of recent relatively untested CLs and is unstable as a result. Here is a doc on the Life of a Chrome CL that also references the LKGR process. The logic for LKGR is in the bestrevision.py file that is checked into the depot. We could potentially leverage this to get the latest known good chrome version for our PFQ in case the last one is totally busted because of a nasty bug. https://docs.google.com/drawings/d/1m8YqArTUvYQO8JUNVQUEdHKoUaFOkAetKJZRzuVMkeE/edit I am talking to mmoss@ to understand this process better. I will post back here.
,
Mar 25 2016
mmoss@ is not the right contact for LKGR. He has directed me to laforge@. I have set up a meeting with Anthony 1st week of April.
,
May 17 2016
Chrome currently uses the LKGR(Last KNown Good Revision) process to decide which build it wants to release. Since our PFQ is triggered post the Chrome team making this decision and choosing the best build possible we are already taking advantage of the LKGR process. At this time I don't think there are any next steps here. |
||
►
Sign in to add a comment |
||
Comment 1 by steve...@chromium.org
, Mar 10 2016