On Jul 28, 2011 6:01 PM, "MZMcBride" <z(a)mzmcbride.com> wrote: than area If you made the commit and received feedback about it in CR, continuing discussion there before making an amended commit -- especially when fixing something that was reverted -- seems a good fit. That can save committers and reviewers alike from the pain of a second or third breakage+revert/rushed fix cycle. In many cases these are patches for a bug, in which case bugzilla is a good place to stash an updated patch version to be looked over. (In a DVCS workflow this might be a branch on a fork rather than a flat patch, but the principle is the same and we *ought* to be able to do ok with patches -- 20+ years of free/open source devs have reviewed, iterated, and landed or clearly rejected changes this way, including us!) I find that reverting and yelling at people for broken commits is *not* a sustainable practice, even if it's old. We need to show that we can hold up our end of the bargain: give timely feedback, keep up with both commits already done and with patches coming in through other channels. It's a process, and we're all still feeling our way along. Part of that is improving reviewer responsiveness to commits after they come in. Part is improving responsiveness to uncommitted patches. And part of it is making sure that we send people and code through the review paths that will best fit them. -- brion