Nicolas B. Pierron wrote:
On 07/10/2016 06:48 PM, allassopraise . wrote:
For example, I believe the orange and red links indicate an error, but
how do I know if they pertain to my push or not?
I have the same issue, and in many cases I feel clueless about the
oranges & reds. At the end I end-up pushing to inbound, even if I feel
that I had a higher number of oranges / reds on try than I would expect
to see on inbound.
I see that we already have a classifier which automatically mark some of
the intermittent, and if this tool were able to classify the remaining
issue, this would be quite helpful.
I guess, what I am missing with Try pushes, is a clear Yes/No answer.
Re the last sentence, I wish if it were that easy.
I think all one has to do (and must do) is a due diligence to verify
that one's patch does not seem to generate extra errors not seen in the
pristine tree.
It took me a couple of months to figure out why my patch caused errors
in windows build and test while there were no issues on linux and Mac
OSX. I thought the error(s) I saw under windows were a fluke.
But as it turned out, it persists and so I sprinkled fprintf to figure
out what is going on (I don't have windows development environment
handy), and eventually figure out the particular pattern when something
went wrong: a file was still open when a code tried to rename it.
Renaming a file that is still open works under linux/Mac OSX (and posix
in general, I think), but it is no-no and causes an error. So I changed
the logic of my patch a little bit to avoid that situation, and the
error(s) went away from treeherder result.
So I think one must be very wary of ANY NEW ERROR(S) that one's patch
may introduce in the result.
If no such errors are seen in a few test runs, I take it easy and think
my patch is good enough.
Just my two cents worth.
CI
_______________________________________________
dev-builds mailing list
dev-builds@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-builds
