<div><br></div><div><br><div class="gmail_quote"><div dir="ltr">On Thu, 27 Sep 2018 at 18:27, Pranith Kumar Karampuri <<a href="mailto:pkarampu@redhat.com">pkarampu@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"><br><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 27, 2018 at 5:27 PM Atin Mukherjee <<a href="mailto:amukherj@redhat.com" target="_blank">amukherj@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><div dir="auto">tests/bugs/<component Y>/xxx.t failing can’t always mean there’s a bug in component Y. </div></div></blockquote><div><br></div><div>I agree.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="auto">It could be anywhere till we root cause the problem. </div></div></blockquote><div><br></div><div>Some one needs to step in to find out what the root cause is. I agree that for a component like glusterd bugs in other components can easily lead to failures. How do we make sure that someone takes a look at it?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="auto">Now does this mean we block commit rights for component Y till we have the root cause? </div></div></blockquote><div><br></div><div>It was a way of making it someone's priority. If you have another way to make it someone's priority that is better than this, please suggest and we can have a discussion around it and agree on it :-).</div></div></div></blockquote><div dir="auto"><br></div><div dir="auto">This is what I can think of:</div><div dir="auto"><br></div><div dir="auto">1. Component peers/maintainers take a first triage of the test failure. Do the initial debugging and (a) point to the component which needs further debugging or (b) seek for help at gluster-devel ML for additional insight for identifying the problem and narrowing down to a component. </div><div dir="auto">2. If it’s (1 a) then we already know the component and the owner. If it’s (2 b) at this juncture, it’s all maintainers responsibility to ensure the email is well understood and based on the available details the ownership is picked up by respective maintainers. It might be also needed that multiple maintainers might have to be involved and this is why I focus on this as a group effort than individual one.</div><div dir="auto"><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"><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div dir="auto">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></blockquote><div><br></div><div>Let us dig deeper into what happens when we work as a group, in general it will be one person who will take the lead and get help. Is there a way to find that person without locking down whole master? If there is, we may never have to get to a place where we lock down master completely. We may not even have to lock down components. Suggestions are welcome.<br></div></div></div><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank">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="m_-2909149708016567514m_-833658822386442056gmail_signature" data-smartmail="gmail_signature">- Atin (atinm)</div>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="m_-2909149708016567514gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Pranith<br></div></div></div>
</blockquote></div></div>-- <br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">- Atin (atinm)</div>