On 13-04-23 03:57 , Axel Hecht wrote:
Do we know how many of these have been pushed to try, and
passed/compiled what they'd fail later?
I haven't looked at this. It would be useful to know but short of
pulling patches and using some similarity heuristic or manually
examining patches I can't think of a way to get this data.
I expect some cost of regressions to come from merging/rebasing, and
it'd be interesting to know how much of that you can see in the data
window you looked at.
This is something I did try to determine, by looking at the number of
conflicts between patches in my data window. My algorithm was basically
this:
1) Sync a tree to the last cset in the range
2) Iterate through each push backwards, skipping merges, backouts, and
changes that are later backed out
3) For each of these pushes, try to qpush a backout of it.
4) If the attempted qpush fails, that means there is another change that
landed since that one that there is a merge conflict with.
The problem here is that the farther back you go the more likely it is
that you will run into conflicting changes, because an increasing
portion of the data window is checked for conflicts when really you
probably only want to test some small number of changes (~30?). Using
this approach I got 129 conflicts, and as expected, the rate at which I
encountered conflicts went up as I went farther back. I didn't get
around to trying the sliding window approach which I believe will give a
more representative (and much lower) count. My code for doing this is in
the bottom half of [1] if you (or anybody else) wants to give that a shot.
kats
[1]
https://github.com/staktrace/mozilla-tree-analyzer/blob/master/inbound-csets.sh
- WARNING don't *run* anything in this repo because it may do
destructive things. Ask me if you're not sure.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
