<div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_quote"><div></div><div>We know maintainers of the components which are leading to repeated failures in that component and we just need to do the same thing we did to remove commit access for the maintainer of the component instead of all of the people. So in that sense it is not good faith and can be enforced.<br></div><div></div></div></div></blockquote><div><br></div><div>Pranith, I believe the difference of opinion is because you&#39;re looking at this problem in terms of &quot;who&quot; rather than &quot;what&quot;. We do not care about *who* broke master. Removing commit access from a component owner doesn&#39;t stop someone else from landing a patch will create a failure in the same component or even a different component. We cannot stop patches from landing because it touches a specific component. And even if we could, our components are not entirely independent of each other. There could still be failures. This is a common scenario and it happened the last time we had to close master. Let me further re-emphasize our goals:</div><div><br></div><div>* When master is broken, every team member&#39;s energy needs to be focused on getting master to green. Who broke the build isn&#39;t a concern as much as *the build is broken*. This is not a situation to punish specific people.</div><div>* If we allow other commits to land, we run the risk of someone else breaking master with a different patch. Now we have two failures to debug and fix.</div></div></div>