[Gluster-Maintainers] Lock down period merge process

[Pranith Kumar Karampuri]

On Thu, Sep 27, 2018 at 5:27 PM Atin Mukherjee <amukherj at redhat.com> 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 <nigelb at redhat.com> 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
>> maintainers at gluster.org
>> https://lists.gluster.org/mailman/listinfo/maintainers
>>
> --
> - Atin (atinm)
>


-- 
Pranith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/maintainers/attachments/20180927/2c7b4ed8/attachment.html>