On Thu, Sep 27, 2018 at 5:27 PM Atin Mukherjee <[email protected]> wrote:
> tests/bugs/<component Y>/xxx.t failing can’t always mean there’s a bug in > component Y. > I agree. > It could be anywhere till we root cause the problem. > 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? > Now does this mean we block commit rights for component Y till we have the > root cause? > 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 :-). > 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). > 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. > On Thu, 27 Sep 2018 at 14:04, Nigel Babu <[email protected]> wrote: > >> 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. >>> >> >> 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: >> >> * 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. >> * 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. >> _______________________________________________ >> maintainers mailing list >> [email protected] >> https://lists.gluster.org/mailman/listinfo/maintainers >> > -- > - Atin (atinm) > -- Pranith
_______________________________________________ maintainers mailing list [email protected] https://lists.gluster.org/mailman/listinfo/maintainers
