On Tue, Nov 3, 2009 at 1:53 PM, Nicolas Sylvain <[email protected]>wrote:
> This is really important to keep the tree green and open. The old saying > is "Revert now, think later"... If a change broke the build and the fix > would > take more than 1 or 2 minutes to be committed, or if the committer is not > answering pings, then the change needs to be reverted asap. > We waver on this policy. Firstly, when does a fix ever take <2 minutes to commit? Maybe 1% of the time. More than that, this has happened a number of times already. A small subset of people who are responsible for keeping the tree healthy institute a revert-early policy. Then a small subset of people who get reverted get vocal and upset. Then we end up in the middle again where some reverts happen quickly and others take >30 minutes. Can we agree on this as a formal policy that we add to documentation somewhere? To be clear, here's the proposed policy: Any change that would close the tree can be reverted if it can't be fixed in <2 minutes. The first part is important. We shouldn't be rolling back changes that wouldn't close the tree (e.g. a change that causes a single test to fail). Ojan --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
