05.04.2010, в 21:58, Adam Barth написал(а): > Leaving failures in the tree make it difficult to track > down subsequent failures. Rolling out a change means more work for > you, but less costs imposed on the rest of the project.
While I agree with your analysis for the most part, there are costs associated with rolling out patches that you didn't mention. Some of these are: 1) Confusion about what is going on with the project. It becomes harder to know what's going on by reading webkit-changes - because you can't unsee a patch you saw landed, and because people often roll out patches with cryptic messages (roll out rXXXXX, because it breaks Tiger - how are you supposed to know that an important change you saw landed a few hours ago isn't there any more?) 2) Confusion also happens in Bugzilla - there are several styles for dealing with such issues (make a new bug for rollout, or just roll out and reopen). People often forget to document what they were doing to fix the build, so you end up with a resolved bug for something that has been rolled out, or a reopened bug without adequate explanations. Even when the original bug is correctly reopened, it can be hard to figure out its history, because commit queue clears out flags on patches. 3) Likelihood of more world rebuilds for developers and bots. A troublesome patch is more likely to touch common headers than a targeted build fix, so you get three world rebuilds instead of one. 4) It's harder to isolate regressions if these appear and disappear several times (aforementioned confusion doesn't help either). Screening bugs about regressions also becomes more error-prone. This arguments goes both ways though - it's even harder to isolate regressions if the platform in question had broken build at the time. - WBR, Alexey Proskuryakov _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
