<div><div dir="auto">tests/bugs/<component Y>/xxx.t failing can’t always mean there’s a bug in component Y. It could be anywhere till we root cause the problem. Now does this mean we block commit rights for component Y till we have the root cause? That doesn’t make much sense right? This is one of the reasons in such case we need to work as a group, figure out the problem and fix it, till then locking down the entire repo for further commits look a better option (IMHO).</div></div><div><br><div class="gmail_quote"><div dir="ltr">On Thu, 27 Sep 2018 at 14:04, Nigel Babu <<a href="mailto:nigelb@redhat.com">nigelb@redhat.com</a>> wrote:<br></div><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"><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're looking at this problem in terms of "who" rather than "what". We do not care about *who* broke master. Removing commit access from a component owner doesn'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's energy needs to be focused on getting master to green. Who broke the build isn'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>
_______________________________________________<br>
maintainers mailing list<br>
<a href="mailto:maintainers@gluster.org" target="_blank">maintainers@gluster.org</a><br>
<a href="https://lists.gluster.org/mailman/listinfo/maintainers" rel="noreferrer" target="_blank">https://lists.gluster.org/mailman/listinfo/maintainers</a><br>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">- Atin (atinm)</div>