> My strong preference is immediate reaction. It doesn't always have to be a
> rollout, sometimes an issue can be fixed, or some tests can even be
> temporarily skipped - just make the tree green and stable for everyone else,
> as quickly as possible. But if the author is not available, and the bot
> watcher doesn't have a better fix (or is simply overwhelmed with multiple
> regressions being under investigation at once), I think that immediate
> rollout should be considered normal.
I agree.
I used to think that it was rude to roll out a patch right away, and it
bothered me when people did it to me. It is inconvenient to rebase and re-land
a patch, re-close a bug, have roll-ins and roll-outs in svn history, and so on.
However, over time I’ve become convinced that the value of a green bot and
viable archived builds is just so high that it’s worth the inconvenience.
These issues are often a judgement call. But if I had to articulate a firm
rule, I would say something like this: “A bot watcher should take immediate
action to resolve a failure. Before rolling out a patch, a bot watcher should
attempt to contact the patch author and/or reviewer. The burden is on the patch
author and/or reviewer to prove that the failure will be resolved in short
order.”
In other words, I don’t think the burden should be on the bot watcher to prove
that he or she has waited long enough. It’s too easy for politeness to red the
tree, and it’s too hard — especially for new bot watchers — to overcome good
manners in order to do what is necesary.
If you land a patch, and you don’t want it rolled out, be sure to monitor IRC,
email, and/or the bots, and you’ll have a good time. Otherwise, accept a roll
out. This seems like a reasonable tradeoff to me, which each engineer can
negotiate depending on his or her needs at a given time.
Geoff
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev
