On Thu, Sep 27, 2018 at 7:35 PM Atin Mukherjee <[email protected]> wrote:
> > > On Thu, 27 Sep 2018 at 18:27, Pranith Kumar Karampuri <[email protected]> > wrote: > >> >> >> 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 :-). >> > > This is what I can think of: > > 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. > 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. > I like this approach. One question here regarding (1a), do you guys think 'recheck centos' workflow is preventing folks from posting it on gluster-devel? I understand there is fstat for people to get the data about what are the tests that are failing a lot. But considering it didn't lead to the behavior where the failures are addressed on timely basis should we change it? I generally see more activity on gluster-devel/users and github in general from community when issues are posted. What do you guys think? > > >> >> >>> 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 >> > -- > - Atin (atinm) > -- Pranith
_______________________________________________ maintainers mailing list [email protected] https://lists.gluster.org/mailman/listinfo/maintainers
