On 2015-04-22 8:02 AM, Julien Wajsberg wrote:
Inbound bustage should not happen. Try is not a waste of time. The time you wait for your build result... well you can do something else during that time, right? If you're really confident your work won't break anything then you'll likely only wait a few hours before landing, it's not a big deal. And if the try run catches an issue, you saved yourself and sheriffs and people bisecting and everybody else a lot of time. Just use try.
Note that it's not just the turn around time that can become an issue. For me personally the reasons I choose to not use the try server are:
1) If I have ~20 unlanded patches in my queue (which is normal for my workflow on an average day), I need to juggle 20 open tabs for 20 try pushes if I wanted to send each one of them to the try server, which means that I would need to spend the time to look at each result, go through the intermittents on them, retrigger the runs for the intermittents that have not been filed yet (I get them surprisingly often), etc.
2) The wall clock latency of try server runs will be specifically more painful if I push to try, wait for a review (which depending on the reviewer can take days), then make the changes asked by them, and push to try *again*, which will typically mean that I will get to land the patch the next day when the try results are finally in. This hurts me personally because my productivity is decreased heavily when my local patch queue gets long, since my brain would carry the cognitive load of which fixes have landed, whether the fact that I haven't seen a regression report of bug X yet an indication that I haven't landed the patch yet or that the patch was correct, and so on. This may not seem like a problem if you think about just one patch, but if you think about doing this every day for 20 patches, then it turns into an issue.
3) The try server actually doesn't prevent me from making mistakes in the end. Just yesterday, I broke inbound on a patch that I _had_ sent to the try server before, but I forgot that one of its dependencies has not landed yet (#2 above!). And too often I break inbound because I misinterpret an orange (because #1 above gets out of hands, and I end up looking at the wrong results, or don't wait long enough for that one last test result to come in, etc.)
Therefore, in practice, landing code for me is a guessing game, gauging my confidence over what my patch changes exactly and what kinds of test/builds examine that change, how risky I expect it to be, how long I expect the reviewer to take to get back to me, how likely it's going to be that they would ask for (substantial) changes in the patch, how soon I need the fix in, how many other things in my queue depend on it, etc.
The simplistic answer of "just push everything to try" doesn't really work for my needs at least.
_______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
