1112570 - Speed up the first step of hunting inbound in mozregression

Status: RESOLVED WONTFIX

(Testing :: mozregression, defect)

Description

[Julien Pagès (:parkouss)]

Currently the inbound hunting process works like explained in bug 997388 comment 8.

I think there is some improvement we can make here for the first step. The first step involve to narrow down our inbounds changeset list, by checking that the changeset of a build is in the changesets we got from mercurial.

If I understand all well, this check is only useful on upper and lower limits of the range. In fact, once we found good builds limits, we are sure that the range is valid from a changeset validity point of view. (build folder can be empty or invalid in another way, but that's another story).

So, I'm thinking that we could look for the first build in allowed changesets in a better way. I take the example from the explanation in bug 997388 comment 8:

In the current process we are checking builds in this way:
 [0, 1, 2, 3, 306, 307, 308, 309]
then:
 [0, 1, 2, 3, 298, 299, 300, 301]
 [0, 1, 2, 3, 290, 291, 292, 293]
 ...
 
Why don't try something like:
  [0, 4, 8, 12, 297, 301, 305, 309]

Typically, if we found that the 12 is not in the allowed changeset range, we can get rid of these 12 first builds, and we would have just downloaded 4.

Or something similar - the idea is to jump over some builds here until we find one that is in the range, then go back from there to find the first one.

Does that make sense ?

Comment 1

[Julien Pagès (:parkouss)]

Well, I'm closing this because Bug 1095756 will resolve the inbound speed problem in another way.